В этом модуле вы узнаете, как наполнять спринт и оценивать задачи с помощью Planning Poker, а также следить за прогрессом спринта и релизов с помощью диаграмм.
Оценка времени разработки
Чаще всего эти инструменты используются при работе по Scrum.
Оценка времени разработки — довольно сложное и неблагодарное занятие. Зато вполне реально понять, какая работа займет больше времени, а какая — намного меньше.
Для такой оценки придумали систему относительных величин. У нее есть ряд преимуществ:
- Планирование при такой системе занимает меньше времени, потому что об относительных величинах договориться проще, чем о конкретном времени.
- Оценивается не только работа в чистом виде, но и временные активности, которые нужны для разбора почты, обсуждения, проведение встреч, общение с клиентами и т.п.
- Система относительных величин позволяет сфокусировать команду на ценности, а не времени разработки продукта.
Существует несколько вариантов оценки в относительных величинах.
- По эталону. Вы берете одну небольшую пользовательскую историю и принимаете ее за эталон — то есть за единицу. Все остальные пользовательские истории вы сравниваете с ней, смотрите, во сколько раз они больше, и присваиваете им соответствующие оценки.
- Размерная сетка футболок. Есть общемировая практика использования буквенных обозначений: S, M, L. При этом при такой системе оценивания количество вариантов сильно ограничено.
- Числовая последовательность Фибоначчи. Это числовой ряд, в котором каждое следующее число является суммой двух предыдущих. Вариативность оценок очень большая.
Planning Poker
Чтобы процесс планирования с использованием последовательности Фибоначчи проходил быстрее, разработали инструмент Planning Poker. Каждому участнику команды выдают колоду карт с числами Фибоначчи. Scrum-мастер берет первую по приоритету пользовательскую историю из бэклога, а Product Owner отвечают на вопросы команды по истории. После этого каждый участник выбирает число из своей колоды, которое, как он полагает, эта пользовательская история займет. Выбор числе происходит в закрытую — то есть участники не видят оценки других членов команды.
Когда все участники команды разработки сделали выбор, карты вскрываются. Если оценки совпали, Scrum-мастер записывает их в карточке пользовательской истории и переходит к следующей. Но если оценки не совпали, разброс получился большой, то у участников, которые дали самую маленькую и самую большую оценку, спрашивают, почему они сделали такой выбор.
Возможно, у них есть какая-то дополнительная информация, которая повлияет на оценку других участников команды, и ее просто нужно озвучить. После этого цикл повторяется до тех пор, пока не будут оценены все пользовательские истории. При этом важно договориться, что делать, если, например, выпадают смежные оценки — 5 и 8 и т.д. Какую из них выбирать — максимальную, среднюю или самую маленькую? Обычно берется максимальное значение. Но все равно лучше проговорить это в команде заранее.
Product Owner и Scrum-мастер не участвуют в оценивании задач, чтобы не оказывать влияния. Также не стоит привлекать к оценке задач людей, которые находятся вне контекста и не понимают, что происходит. Они могут размыть корректное значение.
Чтобы обсуждение причин маленькой или высокой оценки не занимало слишком много времени, ставьте таймер — например, на минуту.
Простое объяснение карт разного номинала
- 0 — Задача уже выполнена.
- 1/2 — Задача крошечная.
- 1, 2, 3 — Задача небольшая.
- 5, 8, 13 — Задачи среднего размера.
- 20, 40 — Большие задачи.
- 100 — Очень большие задачи.
- Бесконечность — Задача огромная.
- ? — Не знаю, сколько времени нужно на выполнение задачи.
Диаграмма сгорания
Итак, команда оценила весь объем работ на спринт, и теперь надо отслеживать выполнение задач по ходу спринта. Это делается с помощью диаграммы сгорания. На горизонтальной оси — временная шкала, количество дней в текущей итерации (спринте).
На вертикальной оси откладывается количество стори поинтов, то есть объема работы, который команда взяла в спринт. График состоит из двух линий. Первая – идеальная линия. Она соединяет первоначальный объем работ, запланированный на итерацию, с последним днем. Это идеальный темп сжигания конкретной работы за текущий спринт.
На деле все может получиться не так хорошо. Поэтому Scrum-мастер каждый день откладывает фактическое значение — рисует вторую линию. Он отслеживает негативные тренды и успехи команды. Когда появляется негативный тренд, нужно вовремя в нем разобраться: у нас просто появились новые вводные, нужно что-то скорректировать или пользовательские истории были недостаточно хорошо проработаны?
Диаграмма сгорания релиза
Еще можно отслеживать прогресс приближения продукта к релизу. Для этого существует диаграмма сгорания релиза. Строится она аналогично. Единственное, на оси X откладывается количество итераций в текущем релизе, а по оси Y — весь объем стори поинтов тех пользовательских историй из бэклога, которые вошли в текущий релиз. Понять, какой объем итераций нужен для того или иного релиза, все довольно просто: когда менеджер продуктов понимает, какой объем нужно реализовать, он получает общую сумму стори поинтов по текущему объему пользовательских историй. После этого он берет среднюю скорость работы команды — лучше минимум за три последних спринта, чтобы нивелировать отклонения.
Общую сумму он делит на скорость команды в стори поинтах. Н выходе — количество итераций, за которое команда в среднем сможет реализовать эту функциональность. Округлять значение лучше в большую сторону.
Бывает, что фактическая линия идет резко вверх. Например, когда какая-то пользовательская история приобретает больший приоритет и ее включают в текущий релиз.
В этом случае есть два варианта действий: либо Product Owner принимает решение об исключении из релиза какой-то другой пользовательской истории сопоставимого размера, либо смещает даты релиза, либо какая-то пользовательская история по этой информации становится низко приоритетной и ее можно исключить. Для того чтобы строить фактическую линию, Scrum-мастер откладывает на графике оставшийся объем работы. Он делает это не ежедневно, а в конце каждого спринта.