Как планировать и оценивать проекты в Agile?
«Вот так и родилась у меня мысль создать игру, через которую я смог бы заинтересовать команду начать оценивать все истории в относительных попугаях. И тогда мне пришла идея с закрашиванием пустых фигурок на флип-чарт бумаге.
Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение «Что такое относительный стори поинт? В чем его ценность?». С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».
Цель
Показать как использование итерационно-инкрементального подхода в совокупности с относительной оценкой дает больше прозрачности в прогнозировании сроков выполнения проекта.
Время
Обычно игра занимает около одного часа, включая обсуждения.
- 15 минут — оценка
- 35 минут — завершить закрашивание (длительность итерации = 1 минута)
- 10 минут — обсуждение
Подготовка:
- Разбить группу на команды из 3–5 человек
- Команды должны сидеть за столом
- Один чистый лист флип-чарт бумаги на команду
- Один флип-чарт маркер на одного участника
Инструкции
Оценка
1. Для каждой группы подготовить одинаковые флип-чарты с пустыми фигурками. См. пример ниже
2. Ведущий игры подготавливает на флип-чарте таблицу, в которой он будет фиксировать метрики всех команд:
3. Команды оценивают все фигурки в относительных стори-поинтах, используя числа фибоначчи и считают сумму всех стори-поинтов. Ведущий заносит это значение в таблицу. См. выше
4. Команды также оценивают срок выполнения задачи (закрасить все фигурки) в минутах (абсолютная оценка), учитывая то, что принимается только исключительно качественная закраска, т.е. не содержит белых пробелов и не вылазит за контуры фигур.
Выполнение
1. Длина одной итерации не больше минуты.
2. Перед первой итерацией ведущий может дать минуту на обсуждение командной стратегии по закрашиванию. Приоритеты — начинаем с самых маленьких, заканчиваем большими. Когда команды дойдут до закраски наибольших, ведущий может увеличить планирование, так чтобы команды разбили фигуры на сегменты о оценили отдельно сегменты.
3. Запускаем первую итерацию:
4. Ведущий принимает работу. Засчитываем только идеально закрашенные фигуры, либо сегменты (только если была предварительная разбивка). Команда считает Velocity.
5. Частично сделанная работа переоценивается в стори-поинтах в сторону уменьшения, но разница не добавляется в суммарную скорость (т.е. скорость показывает только принятую работу). У меня часто спрашивают «почему»? Я понимаю, что обидно терять поинты, когда история в конце спринта закончена на 90% (поинты пройдут как-бы мимо команды). Вопрос только в том чего хочет команда, показать высокую скорость или завысить ожидания заказчика? Возможно в этой незаконченной истории действительно осталось 10% работ. Но вдруг, доделывая эти 10%, вы обнаруживаете дефект, на решение которого вы потратите еще +50% вашего времени. А заказчикам то уже показали высокую скорость? Именно поэтому сообщество скрам-практиков не рекомендует включать в скорость (Velocity) любые недоделанные истории.
6. Команда пересчитывает сумму оставшихся стори-поинтов на флип-чарте и прогнозирует срок выполнения проекта по формуле.
Время выполнения = Сумма стори-поинтов\VelocityСкорее всего срок выполнения будет отличаться от изначально запланированного
7. Повторяем шаги 1–6 до выполнения проекта по закраске:
8. Команда празднует завершение проекта.
Обсуждение
1. Если еще перед первой итерацией у команд получились разные оценки, обсудите как заказчик может понять кто прав? В итоге может оказаться (а это самый вероятный исход), что все неправы, потому что обещать точные сроки в комплексной системе дело неблагодарное. Обсудите как не попасть в ловушку своих же неверных оценок?
2. Если команды не заработали очков после первой итерации. Обсудите почему важно в конце итерации иметь готовый инкремент? Почему наполовину готовый инкремент не показывает прогресс? Почему наполовину готовый инкремент может дать большие погрешности в подсчете прогноза выполнения проекта?
3. Продемонстрируйте как нарисовать Release Burn-Down Chart, используя данные из таблицы.
4. Обсудите почему важно приучать заказчика к тому, что скорость команды может постоянно изменяться под воздействием непредвиденных обстоятельств?
5. Собрать и зафиксировать обратную связь от участников. Что они узнали нового? Чему научились? Что из упражнения можно пробовать в реальной жизни?
6. Ведущий убеждается что участники поняли как относительные попугаи помогли считать реальное время выполнения проекта.
7. Исследуйте ценность разделения больших задач\историй (фигур) и как команды улучшались между итерациями.
Спасибо за внимание!
P.S. 29–31 августа Вячеслав проводит сертифицированный тренинг Professional Scrum Master в Москве.
