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

Стратегия

планирования

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

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

•собрать команду вместе;

•определить объем работ и приоритеты;

•оценить затраты и график работ;

•добиться появления у каждого заинтересованного лица ощущения того, что система действительно может быть реализована;

•определить исходные данные для обратной связи.

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

вглаве 8. Другие относятся конкретно к планированию.

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

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

• Принимаемая ответственность — ответственность может быть только принята, но не может быть назначена. Это означает, что в рамках ХР не может быть такой вещи, как планирование сверху вниз. Менеджер не может прийти к команде и сказать: «Вот то, что мы должны сделать и это должно быть сделано за такое-то и такое-то время». Менеджер проекта должен предложить команде взять ответственность за выполнение работы. После этого он должен внимательно выслушать ответ.

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

•Игнорируйте взаимосвязи между частями проекта — планируйте так, как если бы части разработки можно было бы менять между собой по вашему собственному желанию. Это простое правило избавит вас от проблем при условии, что вы будете в первую очередь реализовывать наиболее высокоприоритетные бизнес-требования. «Сколько стоит кофе?» «25 центов за чашку, но вторая чашка бесплатно».

«Тогда дайте мне вторую чашку». Подобные ситуации не должны происходить.

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

Игра в планирование

Планирование в ХР намеренно абстрагирует процесс планирования для двух участников — бизнес (Business) и разработчики (Development). Это способствует устранению некоторого эмоционального напряжения, которое часто возникает в процессе обсуждения планов. Вместо «Джо, ты придурок! Ты же обещал мне сделать это еще к минувшей пятнице!» игра в планирование (Planning Game) сообщает: «Разработчики обнаружили

116 Глава 15 • Стратегия планирования

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

Зачастую бизнес не любит разработчиков. Отношения между людьми, которые нуждаются в системах, и людьми, которые эти системы разрабатывают, зачастую напоминают отношения между многовековыми врагами. Недоверие, взаимные обвинения, хитрое и скрытое маневрирование — все это вполне характерные вещи. Вы не можете разрабатывать хорошее программное обеспечение в подобных условиях.

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

Подобные взаимоотношения нельзя установить при помощи законов и инструкций. Вы не можете просто сказать: «Мы понимаем, что мы ведем себя несправедливо по отношению друг к другу. Нам ужасно жаль. Это больше не повторится. Давайте сразу же после обеда начнем сотрудничать совершенно по-другому». Весь мир и все люди не могут работать таким образом. В состоянии стресса люди начинают вести себя по-старо- му, как бы плохо это ни было.

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

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

118 Глава 15 • Стратегия планирования

Игроки

В игру в планирование играют два игрока — бизнес (Business) и разработчики (Development). Разработчики — это люди, которые отвечают за реализацию системы. Бизнес — это люди, которые принимают решения о том, что должна делать система.

Иногда сразу ясно, кто именно должен играть на стороне бизнеса. Если компания — биржевой брокер платит деньги за разработку специализированного программного обеспечения, значит, эти люди играют на стороне бизнеса. Именно они должны определить, что необходимо сделать в первую очередь. Но если вы занимаетесь разработкой программного продукта, который предназначен для массового рынка? Кто тогда играет роль бизнеса? Бизнес должен принимать решения относительно объема работ, приоритетов и содержимого версий продукта. Все эти решения, как правило, делаются сотрудниками отдела маркетинга. Если это достаточно умные люди, они будут принимать решения исходя из мнения:

•реальных пользователей продукта;

•заинтересованных в продукте групп;

•людей, занимающихся продажами.

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

Ходы

Игра состоит из трех фаз:

•исследование (exploration) — в этой фазе необходимо определить, что нового должна делать система;

•подтверждение (commitment) — в этой фазе необходимо решить, какое подмножество всех возможных требований необходимо удовлетворить в следующую очередь;

•управление (steer) — в этой фазе необходимо управлять разработкой по мере того, как реальность вносит свои коррективы в план.

оценить оставшиеся истории и заново определить скорость разработки.

Итерационное планирование

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

Игра в итерационное планирование (Iteration Planning Game) очень напоминает игру в планирование (Planning Game), в которой карты используются в качестве кусков (pieces). На этот раз в качестве кусков используются не карты историй (story cards), а карты задач (task cards). Игроками являются отдельные программисты. Шкала времени короче — вся игра укладывается в одну итерацию (от одной до четырех недель). Фазы и ходы схожи с фазами и ходами игры в планирование.

Рис. 7. Карточка задачи (task card)

Фаза исследования

• Написание задачи — выбор историй для итерации и преобразование их в задачи. Как правило, задача — это нечто меньшее по масштабу, чем история, так как нельзя реализовать одну историю целиком все-