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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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