Как планировать и оценивать проекты в Agile?

в 9:50, , рубрики: agile, scrum, Блог компании Luxoft, оценка, планирование, планирование проектов, Управление продуктом, управление проектами

Несколько лет назад Тренер Luxoft Agile Practice — Вячеслав Москаленко столкнулся с проблемой, что многие Скрам-команды не оценивают все истории в Бэклоге Продукта. А зря, ведь оценка дает нам прозрачную картину реального прогресса и возможность управлять ожиданиями наших заказчиков, не дожидаясь финишной прямой нашего проекта, когда уже поздно что-то менять.

Как планировать и оценивать проекты в Agile? - 1 «Вот так и родилась у меня мысль создать игру, через которую я смог бы заинтересовать команду начать оценивать все истории в относительных попугаях. И тогда мне пришла идея с закрашиванием пустых фигурок на флип-чарт бумаге.

Когда я в первый раз провел игру-раскраску на одном из мастер-классов местной ПМ-тусовки, даже не ожидал, что достаточно консервативные менеджеры проведут так весело время и получат объяснение „Что такое относительный стори поинт? В чем его ценность?“. С тех пор я провел эту игру на многих тренингах и нескольких конференциях, включая SECR-2015 и Agile Days Russia 2016».

Цель

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

Время

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

  • 15 минут – оценка
  • 35 минут – завершить закрашивание (длительность итерации = 1 минута)
  • 10 минут – обсуждение

Подготовка:

  • Разбить группу на команды из 3-5 человек
  • Команды должны сидеть за столом
  • Один чистый лист флип-чарт бумаги на команду
  • Один флип-чарт маркер на одного участника

Инструкции

Оценка

1. Для каждой группы подготовить одинаковые флип-чарты с пустыми фигурками. См. пример ниже

image

2. Ведущий игры подготавливает на флип-чарте таблицу, в которой он будет фиксировать метрики всех команд:

image

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

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

Выполнение

1. Длина одной итерации не больше минуты.

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

3. Запускаем первую итерацию:

image

4. Ведущий принимает работу. Засчитываем только идеально закрашенные фигуры, либо сегменты (только если была предварительная разбивка). Команда считает Velocity.

5. Частично сделанная работа переоценивается в стори-поинтах в сторону уменьшения, но разница не добавляется в суммарную скорость (т.е. скорость показывает только принятую работу). У меня часто спрашивают «почему»? Я понимаю, что обидно терять поинты, когда история в конце спринта закончена на 90% (поинты пройдут как-бы мимо команды). Вопрос только в том чего хочет команда, показать высокую скорость или завысить ожидания заказчика? Возможно в этой незаконченной истории действительно осталось 10% работ. Но вдруг, доделывая эти 10%, вы обнаруживаете дефект, на решение которого вы потратите еще +50% вашего времени. А заказчикам то уже показали высокую скорость? Именно поэтому сообщество скрам-практиков не рекомендует включать в скорость (Velocity) любые недоделанные истории.

6. Команда пересчитывает сумму оставшихся стори-поинтов на флип-чарте и прогнозирует срок выполнения проекта по формуле.

Время выполнения = Сумма стори-поинтовVelocity

Скорее всего срок выполнения будет отличаться от изначально запланированного

7. Повторяем шаги 1-6 до выполнения проекта по закраске:

image

8. Команда празднует завершение проекта.

image

Обсуждение

1. Если еще перед первой итерацией у команд получились разные оценки, обсудите как заказчик может понять кто прав? В итоге может оказаться (а это самый вероятный исход), что все неправы, потому что обещать точные сроки в комплексной системе дело неблагодарное. Обсудите как не попасть в ловушку своих же неверных оценок?

2. Если команды не заработали очков после первой итерации. Обсудите почему важно в конце итерации иметь готовый инкремент? Почему наполовину готовый инкремент не показывает прогресс? Почему наполовину готовый инкремент может дать большие погрешности в подсчете прогноза выполнения проекта?

3. Продемонстрируйте как нарисовать Release Burn-Down Chart, используя данные из таблицы.

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

5. Собрать и зафиксировать обратную связь от участников. Что они узнали нового? Чему научились? Что из упражнения можно пробовать в реальной жизни?

6. Ведущий убеждается что участники поняли как относительные попугаи помогли считать реальное время выполнения проекта.

7. Исследуйте ценность разделения больших задачисторий (фигур) и как команды улучшались между итерациями.

Спасибо за внимание!

P.S. 29-31 августа Вячеслав проводит сертифицированный тренинг Professional Scrum Master в Москве.

Автор: Luxoft

Источник

Поделиться новостью

* - обязательные к заполнению поля