Agile: оценка и планирование проектов

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

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

Из-за множества мнений и вопросов типа «что… если…» во время типичной сессии по планированию релиза неплохо было бы иметь удобный способ управления входными и выходными параметрами релиза и итерациями. Лучше всего, при условии что каждый знает свою задачу, работать с карточками размером 6×12 см или стикерами с пользовательскими историями или функциями. В отличие от программных средств карточки осязаемы, и их легко может прочитать каждый.

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

Обновление плана релиза

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

Пример

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

• Как тренер я могу определять расписание тренировок.

• Как тренер я могу определять по своему желанию поля для отслеживания по каждому пловцу.

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

• Как пловец я могу корректировать свою гендерно-возрастную информацию.

• Как тренер я могу рассылать электронные письма всем пловцам команды.

• Как системный администратор я могу конфигурировать права доступа и пользовательские группы.

• Как тренер я могу приобретать программу SwimStats и использовать ее вместе со своей командой.

• Как пловец я могу сравнивать свои результаты с национальными рекордами.

• Как тренер я могу вводить имена и гендерно-возрастную информацию по всем пловцам моей команды.

• Как пловец я могу видеть мое лучшее время в каждых соревнованиях.

• Как пользователь я должен зарегистрироваться в системе и могу видеть только данные, к которым мне разрешен доступ.

• Как пловец я могу видеть все мои результаты в конкретных соревнованиях.

Определение условий удовлетворенности