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

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

План должен отражать реальный ход проекта

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

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

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

Цели и задачи планирования

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

Права заказчика

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

Права разработчика

• Знать, что делать и каков приоритет задачи.
• Производить качественный программный продукт.
• Самостоятельно оценивать объем трудозатрат по задачам, а потом вносить изменения в оценки.
• Самостоятельно взять на себя ответственность за решение задачи.

Обязанности заказчика

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

Обязанности разработчиков

• Определять трудозатраты по задачам
• Предупреждать о технических рисках
• Вычислять объем проделанной работы для оценки общего бюджета проекта.

Функциональные требования к системе оформляются в виде пожеланий.

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

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

Суть XP - поставить клиентам тот продукт, который в каждой своей версии отвечал бы требованиям и пожеланиям клиента. Им не нужна система, в которой реализованы неправильно истолкованные в начале проекта требования.

Планирование итерации

• Выбрать и детализировать пожелания заказчика на итерацию. 
• Разбить каждое пожелание на конкретные задачи.
• Добавить необходимые технические задачи.
• Оценка разработчиками времени выполнения задач согласно своей скорости работы.  Каждая задача не должна занимать более одного-трех дней работы.

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

Оценка хода работ

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

• Сколько идеальных дней ты уже потратил на эту задачу?
• Сколько идеальных дней тебе понадобится, чтобы ее закончить?

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

Никогда не сдвигайте сроки! 

Пропуск сроков поставки - потеря контроля над проектом. 

Работа в каждой итерации при этом протекает с некоторой долей неуверенности в конечном результате. Нельзя терять возможность ясно понять, на какой стадии находится проект.

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

Сроки выпуска версии системы всегда устанавливаются исходя из коммерческих интересов.

Подробнее в книге Экстремальное программирование: планирование (Planning Extreme Programming) Кента Бека и Мартина Фаулера.