Парный Тайм-Менеджмент. Часть 2

И снова - здравствуйте!!!

Итак, мы с вами установили, что основными проблемами при внедрении TM являются недостаток дисциплины и мотивации и невозможность получить помощь и поддержку тогда, когда это необходимо. При поиске решения будем руководствоваться следующими критериями:

1. Я довольно ленивый человек, поэтому лучше найти одно универсальное решение, чем по одному на каждую проблему.

2. Решение должно быть простым и понятным. Желательно вообще не изобретать ничего нового, а стибрить из какой-нибудь "параллельной реальности".

3. Это должно быть весело! Ненавижу серьезные рожи.

"Умное лицо - это еще не признак ума господа. Все глупости на земле делаются именно с этим выражением лица. Улыбайтесь господа, улыбайтесь..."

Барон Мюнхгаузен

Какое же решение удовлетворяет всем этим трем критериям? Что знакомо и понятно нам с вами - айтишникам? Что достаточно весело и задорно? И что может решить все три проблемы разом?

IT Brunch - Конференция о Тайм-Менеджменте

Всем привет!

Сегодня мне посчастливилось поучаствовать в веб-конференции формата IT-Brunch о тайм-менеджменте. Действительно приятный и очень уютный формат даже несмотря на то, что меня угораздило оказаться в том месте, где вместо 10 утра у меня 12 часов ночи. Вот такая вот у меня ночная конфа оказалась.  :)

Огромнейший респект организаторам конференции - Тиму Евграшину и Коле Алименкову - организованно четко, надежно и качественно. Не меньший респект докладчикам - несмотря на ночной час их было действительно интересно слушать!

На этой конференции и вещал про концепцию парного тайм-менеджмента о котором все никак не соберусь написать здесь статью. Видимо теперь я уже просто обязан это сделать - так что в ближайшие дни торжественно обещаю написать здесь пост о Pair TM! А пока в комментариях этого поста можно обсудить вопросы по докладу...если вдруг сюда таки дойдут слушатели конференции :)

Удачи всем!

В чем сила XP-2

Итак, в предыдущем посте на эту тему мы разобрали какие ценности приносят в XP-процессы те или иные практики заявленные как must have для настоящего XP. В принципе, цель этого анализа - именно разбор этих самых практик, который, надеюсь, поможет сделать ваш особый уникальный процесс и назвать его как-нибудь красиво :)

Помимо того, что некоторые элементы процесса приносят в него дополнительную ценность, существует второй аспект, который может потребовать введения того или иного принципа или инструмента. Некоторые элементы не только приносят конкретную ценность в проект, но и поддерживают другие практики процесса. Давайте продолжим препарировать XP, раз уж начали, тем более, что все эти принципы и практики по отдельности - все из области Agile, что делает данную статью не столь сильно привязанной к XP.

• Onsite Customer
• Pair Programing
• Collective Code Ownership
• Planing Games
• Coding Standards & Conventions

Перечисленные элементы образуют коммуникационную среду проекта, реализуя принцип Agile "меньше документации - больше кода". Сказать, что это некая ценность я не берусь, так как Agile сам по себе не является таковой с точки зрения проекта. В то же время мы понимаем смысл и предназначение этого набора и можем отдавать себе отчет в том, какие функции выполняют эти элементы. Нельзя, конечно, сказать что это полный набор средств коммуникации (даже напротив - для нормального процесса, на мой взгляд, этого мало :)), однако, надо понимать, что если вы начинаете из этого набора что-то выкидывать, то скорее всего вам придется заплатить за это дополнительной писаниной (переписка по e-mail, wiki, etc).

• Рафакторинг

Рефакторинг с одной стороны поддерживает TDD (который без него просто не работает), с другой стороны(как уже было сказано в первой части этого поста) позволяет привести в порядок код, написанный в концепции KISS, YAGNY и прочий "simple design". То есть, не дай бог у вас в проекте по XP вы начинаете экономить на рефакторинге - иначе готовьтесь получить отсутствие TDD и абсолютно не сопровождаемый код.

• Pair Programing

Без него говорить о совместном владении кодом будет очень тяжело, ведь именно Pair Programing с ротацией пар позволяет знаниям о коде распространяться по команде без дополнительных затрат на документирование.

Эта статья (обе ее части) - это, по сути, обобщенное упражнение по анализу процесса. Здесь я постарался показать, как могут быть связаны элементы вашего процесса и о чем стоит помнить, добавляя или удаляя элементы из него.

Спасибо!