В шапке
Основные процессы при работе по Scrum. Планирование спринта

Основные процессы при работе по Scrum. Планирование спринта

В двух предыдущих статьях я рассказал про команду в Scrum и про документы, которые использует команда проекта для управления проектом. Настала очередь рассказать о процессах, которые использует команда при работе по Scrum. 

Всего в Scrum используется 4 базовых процесса:

  • Планирование спринта
  • Ежедневный скрам-митинг
  • Демо спринта
  • Ретроспектива

Начнем с процесса планирования спринта, а в других статьях рассмотрим остальные процессы.

Что такое спринт? В легкой атлетике спринт – это короткая дистанция. В Scrum используется итерационная модель жизненного цикла проекта, а итерации называются спринтами, т.к. они достаточно короткие во времени - от одной до четырех недель. Конкретную продолжительность  спринта выбирает команда проекта. Как правило, команда пробует работать со спринтами разной продолжительности, а затем выбирает ту продолжительность, которая ей удобна,  и до конца проекта ее не меняет. Не менять длительность спринтов – очень важно, т.к. команда привыкает работать с одним и тем же темпом и выдавать результат по окончании каждого спринта.

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

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

При планировании спринта команда должна на себя взять столько обязательств по выполнению историй из журнала продукта, сколько она может реально реализовать за один спринт.

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

  1. Объем работ по каждой истории, которую команда собирается реализовать в спринте
  2. Скорость команды
  3. Количество часов, которое есть у команды на спринт

Итак, как определить объем работ по историям из журнала продукта? Существует масса способов для прогнозирования объема работ. Но в Scrum, судя по статьям, чаще всего используется покерное планирование. В нескольких проектах мы с командой также использовали этот подход и результат меня очень порадовал.

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

В специальной покерной  колоде, как вы уже заметили, не все значения карт соответствуют ряду Фибоначчи: например, число ½ не соответствует ряду, также как и числа, начиная с «20» (напомню, в ряде Фибоначчи сумма двух предыдущих чисел должна давать следующее число). Это сделано намеренно, т.к. если работа занимает, по мнению эксперта, очень много времени, то будет это 21 час или 20 уже не очень важно. Тем более это неважно для значений в 40 или 100 часов – трудозатраты слишком велики, и шаг после «20» намеренно выбран очень большим. В колоде есть несколько интересных карт. Например, карта  «?» означает, что эксперт не понимает суть истории и не готов сделать оценку, а «кофейная чашка» означает, что эксперт очень хочет сделать брейк и попить кофейку (или чая), «0» - означает, что эта история уже реализована или она настолько проста, что ее можно сделать за пару минут.

Итак, владелец продукта зачитывает историю с самым высоким приоритетом из журнала продукта и отвечает на вопросы участников покерного планирования. Участники планирования делят историю на задачи, после чего владелец продукта просит оценить трудозатраты на первую задачу истории. При этом участники заранее договариваются о том, в каких единицах будут делать оценки трудоемкости задач: в идеальных часах или в story points. Каждый участник, делая оценку, думает о том, сколько лично у него ушло бы времени на реализацию задачи. Сделав оценку, эксперт должен вытянуть карту с цифрой, соответствующей этой оценке, но при этом положить ее рубашкой вверх, чтобы никто не видел цифру. К примеру, я оцениваю выполнение задачи в 8 человеко-часов. В этом случае я вытягиваю из колоды карту с цифрой 8.

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

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

На одном из проектов, где мы использовали покерное планирование, мы добились того, что команда, делавшая оценки работ на спринт, примерно через 8 спринтов вышла на значение Focus factor  равного 100%. Это означает, что все взятые обязательства на спринт выполнялись, а фактические трудозатраты по задачам были практически равны прогнозным.

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

И третья важная вещь при планировании спринта – это понимание того, сколько часов есть у команды на спринт. На практике при расчете этого значения наша команда рассчитывала, сколько часов каждый участник команды может работать в следующем спринте, а затем мы суммировали эти часы и умножали на значение усредненного Focus factor предыдущих спринтов. Как вы думаете, для чего это делалось? Мы планировали объем работ в идеальных часах, а наш мир не идеален. И для учета не идеальности  нашей рабочей среды мы умножали все имеющиеся у команды на следующий спринт время на среднее значение Focus factor. Этот показатель называется capacity спринта. При планировании спринта мы отбирали задач на количество часов, не превышающее расчетное значение capacity.

Итак, результатом планирования спринта становится журнал спринта.

Можно, конечно, усовершенствовать подход к планированию спринта, но уверен, что даже если Вы внедрите то, что описано выше, вы уже получите ощутимый результат!

Успехов Вам во внедрении Scrum!

Комментарии (0)
Войти как