Цитаты из книги «Управление продуктом в Scrum. Agile-методы для вашего бизнеса»

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

«Планы — ничто, планирование — все», — заметил как-то Дуайт Эйзенхауэр

Составление графика — процесс несложный. Сначала мы чертим систему координат и на оси х указываем количество спринтов. На оси у мы пишем очки за пользовательскую историю (или другую, более привычную вам единицу измерения усилий). Первая точка на графике — это примерный объем работ на весь бэклог продукта еще до разработки. Для следующей точки нужно определить оставшийся объем работ из бэклога продукта в конце первого спринта. После этого мы проводим линию между этими точками. Она называется сгоранием и показывает скорость, с которой разрабатывается функционал из бэк­лога продукта. Если мы продлим линию выполнения до оси х, то сможем предсказать, когда примерно проект будет закончен (при условии, что скорость работы и усилия останутся стабильными).

Человеку, который покупает дрель, нужна не сама дрель, а отверстия в стене».

График сгорания работ позволяет отслеживать и прогнозировать ход проекта (Schwaber and Beedle, 2002; 83–88). Он основан на скорости предыдущих спринтов и способен предсказывать будущее, так что scrum-команда может на основании этих прогнозов видоизменять продукт и проект нужным ей образом36. Он базируется на двух факторах: времени и оставшемся объеме работ из бэклога продукта.

Скорость — индикатор того, какой объем работы может выполнить команда в течение одного спринта.

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

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

Фиксирование функциональности — плохой вариант. Даже при наличии видения продукта его точные свойства, функциональность и особенности не известны сразу. Они открываются постепенно, на основе отзывов клиентов и пользователей. Появляются новые требования, бэклог продукта развивается по мере того, как scrum-команда больше узнает о потребностях клиентов и возможностях их удовлетворения. Попытка фиксировать функциональность вредит способностям команды адаптировать продукт к отзывам пользователей. В результате получится не тот продукт, который могут полюбить покупатели.

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