Планирование продукта в Agile

Agile - это хаос, никакого планирования и т.п.

Это ложь и происки демонов!

Для более менее серъёзного проекта планирование, сбор требований и т.п. имеет место быть. А если клиент впервые делает продукт или клиентов много, то чтобы конечный заказчик был доволен нам нужно провести предварительный сбор требований.

Как выглядят требования? Их можно представить в виде треугольника. Вершина самые высокоуровневые требования. Основание… предпред-последний слой это многочисленные документы, детальные требования, SRD, BRD, TRD. Предпоследний слой большое количество документации инженерной и самый нижней слой - код проекта. Код проекта тоже документация  Такую схему можно использовать это не запрещается, но мы ищем эффективные пусти.

Сделаем два предположения:
1. Документация делится на документированную и недокументированную
2. Участники проекта участвуют достаточно продолжительное время, чтобы их можно было считать носителями знания и не страдают амнизией :)

Теперь вспомним, что является средней частью. Большая стопка мукалатуры. Вязкая документация, наводящая Такие предположения позволяют более эффективно построить пирамиду требований вырезав среднюю часть (детальные требования и тонны архитектурной документации). Правда приятно сэкономить тонны времени на написания этой муккалатуры? А сколько времени сэкономили на поддержания её? :)

Но такой подход вызывает изменение процесса разработки
1. Все участники должны быть в курсе высокоуровневых требований
2. Код программы должен быть качественным.

"Все участники должны быть в курсе высокоуровневых требований" это означает, каждый должен въехать в видение продукта, видение релиза, итерации и понимать все требования, которые отражаются в кратких заметках-маркерах (User Story Index Card). Почему маркеры? Да потому, что они нужны лишь для игры в покер и должны служить напоминанием о той или иной хотелке клиента. А когда дойдём до планирования хотелки - у него и спросим :)

Про качественный код здесь говорить нечего. Код программы является самым низкоуровневым, детальным требованием. Поэтому он должен быть таким, что квалифицированный разработчик его будет читать как документ. В общем эффект самодокументированного кода здесь имеет место быть. Каждый Agile-разработчик должен обладать навыками TDD, Refactoring, шаблонами и т.п. Ну и конечно моей любимой альтернативой "конвенции наименования" - Implementation Patterns.

Теперь какова анатомия верхней части пирамиды. Тут вариантов туча. Очень хорошая практика из RUP. Но по мне главное в этом деле, чтобы клиенты, менеджеры и т.п. вне-командные личности смогли договориться в самых крупных своих ожиданиях, выраженном в видении продукта и релизов. И другой важный момент – видение является критериями выбора приоритетов клиентом первоочередных функциональных требований (User Stories). Видение становится картой, используя которую мы движемся в нулевой итерации сбора и анализа требований при составлении Product Backlog’a. И эти видения помогают понять, что нужно в самое ближайшее время. Во время подготовки достаточно понять видение на 2-3 релиза и это будет достаточно.
После того как мы договоримся о целях (видении) релизов. Нам уже легче отсортировать требования пользователей. Самый важный конечно же, это ближайший для разработки релиз. Там нужно быть очень внимательным. К остальным тоже внимательность не помешает. Но нужно участь, что после первого релиза может все изменится. Второй и третий нам интересен лишь для тенденций. О четвертом не имеет смысла вообще говорить. И его можно называть «всё остальное» 

А затем набрав первый релиз. Применяем ту же практику с выделением видения, но относительно итераций релиза. На этом уровне видение каждой итерации называется цель итерации. И мы опять же применяем хитрость практики «видение», чтобы клиенты договорились  Ну и нам разработке стало понятно чего же хотят. Как происходит планирование на этом уровне расскажу в другой раз. Итак получилось выше крыши 

Соберём всю пирамидку требований от видения до ежедневных задач:
1. Видение продукта - управляем метафорами
2. Планирование релизов - управляем features
3. Планирование итераций - управляем user stories
4. Планирование дня - управляем задачами