Осторожно: Burndown Chart!

Автор: Александр Якима (www.enter-agile.com)

Burndown chart - всем известный и широко используемый способ, с помощью которого команда отслеживает тэмп выполнения спринта. Однако не много команд задумывается над тем, какими серьезными недостатками чревато излишне полагаться на Burndown chart. Интерестно то, что некоторые команды этого могут и не заметить, поскольку стиль их работы делает применение Burndown chart более эффективным (хотя таких команд очень мало). Другие же будут искать причину позднего обнаружения низкой производительности в чем-то другом...

Рассмотрим два примера, в каждом из которых команда не выполняет план согласно Burndown chart. В первом случае невыполнение минимально:



Как видим, тэмп выполнения только незначительно отстает от "идеального". Но в скоупе спринта три больших пользовательских истории и в итоге не выполняется ни одна из них, хотя "выжгли" около 75% запланированных усилий. Результат равен 0, показывать нечего.

Рассмотрим теперь сценарий №2:



В этом случае команда опаздывает даже немного больше. Но, о чудо, результат другой - 60% запланированного сделано.

Как такое случилось? Очень просто. Первое, что нужно всегда помнить:

burndown chart показывает прогресс "выжигания" всего лишь единиц измерения пользовательской ценности, а не самой этой ценности.

Итак, если пользовательская история "стоит" нам 8 пунктов, то только все 8 пунктов и обеспечат запланированную ценность (полный пакет: реализованный скоуп истории, тестирование, конфигурирование, и т. д.). Из этого правила могут быть исключения - о них позже. Поэтому, 6 пунктов из 8 для конечного пользователя пустой звук. Другое дело в случае 2, где истории значительно мельче и их, соответсвенно, больше. Тогда в процессе "сгорания" пунктов с болшей вероятностью "целиком сгорают" и истории, т. е. приносится ценность. Отсюда следствие:

Чем мельче пользовательские истории, тем адекватнее burndown chart.

Откуда вобще берутся компактные пользовательские истории? Очень просто: команда сама должна об этом позаботиться во время планирования/коммитмента. Пользовательские истории очень полезно просто разбивать. Существует много приемов того, как это делать и мы о них в последующих постах обязательно поговорим. Пока что приведу один из примеров: история А = история А1 ("основной, примитивный сценарий") + история А2 ("все остальное"). Умение дробить и желание дробить - это часть культуры хорошей гибкой команды, что, к сожалению, часто не встретишь...

Наконец задаимся вопросом: а можно ли было что-то лучше сделать в случае №1? Да, точно: не имплементировать истории в параллели. Многие скрам-команды забывают сам дух скрама, саму суть "ведения мяча всей командой". И это опять таки элемент командной культуры. Поэтому, можно говорить о том, что эффективность burndown chart является также и индикатором гибкости команды.

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

No comments:

Post a Comment

 
Powered by Blogger