Планирование спринтов

Автор: Алексей Кривицкий

"Скажите, как вы планируете спринты,
и я скажу, на сколько успешен ваш проект."

(древнее высказывание)

Шутка, конечно. Но на самом деле планирование спринта - это сердце Скрама.

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

Хорошая новость - есть ряд проверенных практик, которые минимизируют ошибки планирования спринтов. Об этом мы сейчас и поговорим.

Давайте начнём с цели спринт планирования:

Определиться со списком историй (от англ. "user stories"), которые команда верит, что может реализовать (в полном объёме и ожидаемом качестве), которые временно удовлетворят жажду заказчика по новой функциональности.

Другими словами мы пытаемся найти компромисс между желаниями заказчика и возможностями команды (при чём компромисс, который бы не компрометировал наш профессионализм!).

Существуют следующие основные варианты проведения спринт планирования:

• Планирование на основании велосити.
  
  В ходе такого планирования команда набирает истории на новый спринт в соответствии со своим ожидаемым велосити (velocity - скорость работы команды, измеряемая в единицах функционала, которые команда реализовывает за спринт).
  
  То есть, если за прошлый спринт команда выполнила историй на сумму 20 единиц, то можно смело предположить, что и в этот раз команда выполнит столько же (при условии равной длины спринтов и той же доступности членов команды).
  
  В eXtreme Programming этот подход называется "вчерашняя погода" (yesterday's weather).
  
  
• Планирование, базируемое на обещаниях.
  
  Другой (более скрупулёзный) вариант планирования - пройтись детально по историям беклога (начиная с наиболее приоритетных и идя вниз).
  
  Обговорить и разбить историю на подзадачи. Оценить подзадачи в часах. Оговорить зависимости между задачами. Если команда единогласно верит, что историю можно уложить в спринт, история считается спланированной, и команда переходит к рассмотрению следующей истории.
  
  Этот процесс останавливается, когда команда больше не имеет ресурсов для очередной истории. Отобранные истории переносятся в спринт беклог и считаются планом на спринт.
  
  
• Комбинированный подход.
  
  Перечисленные способы хорошо комбинируются: вы набираете истории, используя подход, основанный на обещаниях, а затем проверяете при помощи велосити не пере(недо)набрали ли вы случайно историй.

Какой же подход выбрать?

Молодым командам я бы однозначно посоветовал комбинированных подход.

Со временем, когда у вас выработается "командное шестое чувство" можно будет идти по укороченному варианту с велосити. Но это приходит не сразу. Так что не торопитесь. Чем детальнее вы выполните ваше "домашнее задание" по планированию спринта - тем проще вам потом будет в спринте. Не все углы стоит срезать.

Будьте бдительны!

При любом из этих подходов заказчик может не удовлетвориться количеством набранных историй (заказчики всегда жадны и голодны, будьте бдительны!).

В этом случае варианты у вас следующие:

• переговорить размер историй - упростить что-то;
• заменить одну историю другой - заменить что-то на что-то;
• разбить историю на более простые - оставить что-то на потом.

В любом случае ответ у вас должен быть один: уменьшить объём работы за счёт чего сделать большее количество более простых историй.

Мы уже пережили эпоху, когда нам назначала задачи, не слушая нас. И нам стыдно за качество кода, который нам приходилось тогда писать. Давайте же не будем повторять ошибок прошлого.

В Скраме только команда решает какой объём работы она готова взять. Наполнение же этого объёма остаётся на усмотрение заказчиков.

Удач!