Экстремальное программирование

Еще одним отличием между игрой в планирование и игрой в планирование итерации состоит в том, что программист выбирает задачу перед тем, как сделать оценку. Команда в явной форме берет на себя ответственность за реализацию решений, поэтому оценки в этом случае должны делаться всей командой коллективно. Отдельные программисты берут на себя ответственность за реализацию задач, поэтому они должны оценивать эти задачи самостоятельно в индивидуальном порядке.

Еще одним отличием планирования итерации является то, что некоторые задачи не связаны напрямую с потребностями заказчика. Если кто-либо желает улучшить инструменты, используемые для интеграции системы, и связанный с этим объем работ достаточно значителен, тогда эта проблема становится отдельной задачей, которая включается в график работ и которой назначается приоритет наравне с другими задачами.

Давайте вернемся к ограничениям, связанным с процессом планирования итерации, и рассмотрим, как описанная ранее стратегия удовлетворяет этим ограничениям.

• Вы не желаете тратить слишком много времени на планирование, так как реальность никогда не соответствует плану с точностью 100%. Половина дня из пятнадцати – это не такая уж серьезная потеря. Конечно же, если вы можете сделать это время еще меньше, это будет лучше, однако половина дня – это действительно не так уж и много.

• Вы желаете обладать быстрой и надежной обратной связью относительно того, как идут дела, благодаря чему спустя треть от намеченного времени работы вы можете определиться, существуют ли у проекта проблемы. Ответы на вопросы, которые задает ревизор (tracker) позволяют вам получить неплохое представление о том, отстаете ли вы от графика или нет. Как правило, оставшегося времени хватает на то, чтобы должным образом прореагировать на проблемы локально, то есть не обращаясь к заказчику с просьбой об изменениях.

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

• Вы желаете ограничить объем разработки теми частями проекта, которые действительно нужны. Это всегда звучит странно, когда вы говорите, что на протяжении трех недель вы можете работать только в течение 7,5 дней (15 дней разделить на измеренный фактор нагрузки, равный 2). Однако по мере того, как вы будете учиться формировать точные оценки, вы обнаружите, что это – абсолютная правда. Ощущение, что вы не работаете с максимально возможной интенсивностью, стимулирует у вас желание взять на себя выполнение большего количества задач. Однако при этом вы знаете, что вам надо поддерживать существующие стандарты и приемлемый уровень качества (и у вас есть партнер, который смотрит на тот же самый экран и следит за тем, чтобы вы работали качественно). Таким образом, вы получаете тенденцию работать просто и все также с гордостью могли бы сказать, что вы завершили работу.

• Вы желаете получить процесс, который не генерировал бы столь большого давления на людей. Так как люди под давлением начинают совершать глупые поступки лишь для того, чтобы достигнуть краткосрочной поставленной перед ними цели. При этом о долгосрочных целях они просто не задумываются. И снова это восходит к разговору о 7,5 идеальных рабочих днях за три календарные недели работы. Вы просто не можете взять на себя слишком большое количество задач. В результате вы берете на себя столько задач, сколько вы сможете сделать, обеспечив при этом приемлемый уровень качества.

Для небольших проектов я не использую итерационного планирования. Очевидно, что планирование итераций необходимо для координации работы команды из десяти программистов. Итерационное планирование не требуется в случае, если в проекте задействовано всего два программиста. В зависимости от масштаба проекта вы поймете, что необходимость координации оправдывает дополнительные усилия, затрачиваемые на итерационное планирование.

Планирование за неделю

Как планировать проект, если у вас в запасе всего неделя? Подобная ситуация часто возникает в случае, если команда должна сделать предложение с фиксированной ценой. Вы получаете тендер, и у вас есть всего неделя, чтобы среагировать. У вас нет времени для того, чтобы написать полный набор историй, каждую из которых вы могли бы оценить и протестировать. У вас нет времени на написание прототипов, поэтому вы должны оценить истории исходя из личного опыта.

Решение в рамках ХР предусматривает принятие большего риска в плане при помощи более крупных историй. Напишите истории, которые можно оценить в терминах не недель, а месяцев идеального программирования. Вы можете предоставить заказчику возможность выбирать, для чего он может либо сузить, либо отложить некоторые из историй (как и в обычной игре в планирование).