Как знание игры в покер помогает в управлении проектами

Участники команды собираются в одном помещении, у каждого на руках колода карт. Так начинается один из этапов, который помогает оценить объем работы в течение спринта (итерации), если в компании используется такой подход к управлению проектами, как Scrum. Что происходит после того, как карты раздаются – подробности у нашего эксперта Максима Якубовича.

— Я уже рассказал про формирование команды в проектах, которые используют подход Scrum и про документы для управления проектом.

Настала очередь рассказать о процессах при работе по Scrum.

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

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

В этом материале расскажем о процессе планирования.

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

Как правило, команда проекта пробует работать со спринтами разной продолжительности, а затем выбирает ту продолжительность, которая ей удобна, и до конца проекта ее не меняет. Не менять длительность спринтов — очень важно, т.к. команда привыкает работать с одним и тем же темпом и выдавать результат по окончании каждой итерации.

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

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

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

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

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

Расскажу, как это происходило.

Оценка объема работы

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

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

В нашем случае в специальной покерной колоде не все значения карт соответствуют ряду Фибоначчи. Например:

• Число ½, так же как и числа начиная с цифры «20». Это сделано намеренно. Если работа занимает, по мнению эксперта, очень много времени, то 21 час она займет или 20 – уже не очень важно. Тем более это неважно для значений в 40 или 100 часов — трудозатраты слишком велики. Шаг после «20» намеренно выбран очень большим
• Карта «?» означает, что эксперт не понимает суть истории и не готов сделать оценку
• «Кофейная чашка» означает, что эксперт очень хочет сделать брейк и попить кофейку (или чая)
• «0» — означает, что эта история уже реализована или она настолько проста, что ее можно сделать за пару минут

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

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

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

Цель процедуры — сблизить мнение участников команды. Поэтому:

1. Сначала владелец продукта просит высказаться участника, у которого получилась самая низкая оценка. Он рассказывает в деталях, как планирует реализовать задачу за оцененное им же время.

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

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

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

Таким образом команда оценивает все истории, которые, по их мнению, они могут успеть реализовать за спринт.

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

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

Скорость команды и расчет времени на спринт

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

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

Затем при планировании спринта мы отбирали определенное количество задач — на количество часов, не превышающее расчетное значение capacity.

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

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

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

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами — с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Опыт преподавания — с 2005 года. Около 2300 студентов, прошедших обучение на его семинарах. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Ведущий блога по управлению проектами.

Хотите мгновенно получать уведомления о новых материалах и событиях «Про бизнес.»? Подписывайтесь на наш канал в Telegram!