Планирование Итерации
Iteration Planning Meeting созывается перед началом каждой
итерации для планирования задач которые будут сделаны
в этой итерации. Для итерации выбираются User Stories,
которые выбрал заказчик в плане релиза начиная с самых
важных для заказчика и самых плохих (сопряженных с риском)
для разработчиков. Также в итерацию включаются неработающие
Функциональные тесты.
User Stories и невыполненные Функциональные тесты разбиваются
на задачи. Задачи записываются на карточках. Эти карточки
и есть детальный план на итерацию. Каждая задача должна
быть продолжительностью от 1 до 3 идеальных дней.
Разработчики разбирают задачи и оценивают продолжительность
времени, необходимого для их выполнения. Таким образом,
каждый разработчик оценивает сколько времени задача
займет именно у него. Это важно, чтобы конечную оценку
обьема работ делал сам разработчик.
Скорость проекта определяет помещаются ли ваши задачи
в итерацию или нет. Общая продолжительность задач запланированных
на итерацию не должна превышать скорости, достигнутой
в предыдущей итерации. Если вы набрали слишком много,
то заказчик должен решить какие User Stories, отложить
на следующую итерацию. Если набрали слишком мало, то
надо добавить следующую User Story. В некоторых случаях
можно попросить заказчика разделить одну из User Story,
на две, чтобы включить часть в текущую итерацию.
Откладывание User Story на следующую итерацию может
выглядеть страшно, но не позволяйте себе жертвовать
рефакторингом и Unit Test-ами чтобы сделать больше.
Задолженность по этим категориям быстро замедлит вашу
скорость. Не делайте того, что по-вашему понадобится
в следующих итерациях - делайте только то что необходимо
для выполнения текущих User Stories.
Следите за скоростью проекта и отложенными User Stories.
Вполне возможно, что план релиза придется переделывать
каждые три-пять итераций. Это нормально. Ведь план релиза
- это взгляд в будущее и естественно ожидать что ваши
предсказания придется корректировать.
Наш опыт.
Вы будете смеятсья, но похоже, что мы не можем адекватно
оценить задачу в идеальных днях. То есть оценить-то
мы можем, но это оказывается неправдой. Поэтому, в последнее
время мы стараемся планировать задачи в идеальных часах
и разбивать User Stories на более мелкие задачи (4-8
идеальных часов).
При оценке обьема работы стоит принимать во внимание
с кем в паре вы собираетесь работать. Ваш партнер может
заметно повлиять на скорость работы.
|