Планирование итерации
Встреча по планированию итерации организуется в начале каждой итерации для определения набора задач для разработчиков.
Каждая итерация длится от одной до трёх недель. На этот период из графика релизов выбираются User Stories, имеющие наивысший приоритет с точки зрения заказчика. Также необходимо запланировать исправления для неудачных приёмочных тестов. Заказчик выбирает истории, сумма оценок которых соответствует Project Velocity (скорость разработки), замеренному на предыдущей итерации.
Принцип планирования
User Stories и сломанные тесты декомпозируются на задачи для разработчиков. Аналогично пользовательским историям задачи записываются на карточках, но, в отличие от User Stories, написаны на языке технических специалистов, а не на языке заказчика. Дубли задач могут быть удалены. Карточки задач являются детальным планом отдельной итерации.
Разработчики берут задачи в работу и оценивают, сколько времени займет каждая из них. Важно, чтобы оценку давал тот же человек, который будет работать над задачей.
Каждая задача оценивается в один, два или три дня «идеальной» разработки. При необходимости можно добавить меру в половину дня. Под «идеальной» разработкой подразумевается написание кода для решения задачи, не отвлекаясь ни на что другое.
Задачи, которые занимают больше трёх дней, должны быть разбиты на более мелкие.
Оценка загруженности
После того как декомпозированные задачи оценены, Project Velocity используется для оценки загрузки итерации.
Общее количество дней, необходимых для реализации всех задач, не должно превышать скорость разработки предыдущей итерации.
Если в итерации слишком мало задач, можно включить дополнительные User Stories.
Если итерация переполнена, заказчик должен выбрать истории, которые будут отложены.
Откладывание пользовательских историй может казаться неправильным, но это не так. Не стоит забывать о важности unit-тестов и рефакторинга — техдолг в одном из этих направлений замедлит работу в будущем.
Не нужно делать функционал до того, как он запланирован. Важно делать только необходимое на данный момент. Реализация дополнительного функционала замедлит работу.
Также не нужно поддаваться соблазну уменьшать оценки задач и историй. Процесс планирования строится на неизменных оценках, и даже незначительное их занижение может создать много проблем позже.
Необходимо следить за Project Velocity и отложенными историями. Каждые три–пять итераций может потребоваться переоценка историй и составлении нового графика релизов — это нормально. Пока самые важные User Stories реализуются в первую очередь, команда работает в правильном направлении.