Метрики в Scrum и Kanban

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

И тут в Scrum очень мало ответов. Кроме сугубо бизнес-метрик, которые можно применять практически в любом процессе (ROI, Earned Business Value, Running Tested Features и т.д.), в Scrum предлагается метрика Velocity. Но уже писано переписано, что использовать Velocity в качестве метрики не стоит. Это может привести к неожиданным неприятным последствиям.

Получается, что хороших метрик на первый взгляд нет. В конце статьи я упомяну некоторые неявные метрики в Scrum, но пока давайте поговорим о причине проблем. Самая главная причина – это время. Бизнес практически все измеряет временем (даже деньги – это время). А в Scrum это самое время фиксируется (быстренько все вспоминаем «железный треугольник») и разработка ведется итерациями. Но внутри итерации происходит много всего интересного: мы делаем задачи, пользовательские истории, тестрируем, собираем продукт, устанавливаем и т.д. И вся эта информация теряется на фоне итерации. Происходит так называемое «сглаживание шумов». Если мы затянули с одной активностью, то можем нагнать в другой. Ведь итерация целиком принадлежит команде и команда может «придумывать» внутри итерации что угодно, лишь бы в конце все было готово. Этот подход очень хорош для планирования, но отвратителен для метрик.

Во-первых, мы очень редко можем снимать показатели метрик – в конце итерации. А это в лучшем случае раз в неделю. В основном, все таки раз в две недели. Во-вторых, мы уже упоминали «сглаживание» и оно тоже вносит свои коррективы. Всю итерацию ситуация была из рук вон плохая, а в конце все сделали нечеловеческое усилие и вуаля – все готово и метрики в порядке. Хорошо это или нет? Нет! Мы теряем полезную информацию и не учимся на своих ошибках.

Совсем по-другому дела обстоят в Kanban. Тут внимание уделяется каждой задаче. Метрики снимаются со всего потока задач, который проходит через команду разработки. Вот краткий список метрик:

• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
• Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).

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

Я обещал упомянуть о неявных метриках в Scrum. Эти метрики можно собирать, используя Burndown Chart. Вы можете анализировать его с целью определения шаблонов работы команды, рассматривая ежедневный прогресс и гладкость графика. Вы можете усилить анализ. Для этого нужно ввести категоризацию задач и строить Burndown Chart по каждой категории. Некоторые команды ведут отслеживание метрик задач внутри итерации, но на мой взгляд это несколько противоречит принципам Scrum – внутри итерации команда может работать над задачами в произвольном порядке.

Подведу итог. В Kanban метрики гораздо сильнее, чем в Scrum, но это не делает Kanban более простым в реализации подходом. Наоборот, Kanban требует от команды гораздо больше ответственности, контроля и анализа с постоянным усовершенствованием. Зато с точки зрения бизнеса Kanban гораздо более прозрачный и контролируемый.

А какие метрики применяете вы? Какие метрики хорошо работали для вас в Scrum?