Быть или не быть...
Сегодня я хочу поговорить о метриках.Нужны они или нет?
Наш опыт показывает, что мало кто измеряет те или иные показатели в разработке. И на то есть причины:
Метрики - это инструмент позволяющий принимать решения по улучшению взвешено и объективно.
Нужно заметить, что при всей объективности метрик легко можно попасть в ловушку, где "Термометр измеряет температуру термометра". Данная метрика будет интересной и возможно очень точной, но пользы нести не будет.
В этом и последующих постах я буду рассказывать о "Полезных метриках" и рассказывать об опасных способах их использования
Наш опыт показывает, что мало кто измеряет те или иные показатели в разработке. И на то есть причины:
- Некоторые меряют, но не знают зачем и перестают это делать
- Другие хотят что нибудь померить и в этом случае сталкиваются с огромным количеством метрик. Что и чем мерить не всегда понятно.
- Третьи используют все метрики, о которых написано в книгах, что приносит больше вреда, чем пользы.
- Остальные просто не видят в этом смысла
Метрики - это инструмент позволяющий принимать решения по улучшению взвешено и объективно.
Нужно заметить, что при всей объективности метрик легко можно попасть в ловушку, где "Термометр измеряет температуру термометра". Данная метрика будет интересной и возможно очень точной, но пользы нести не будет.
В этом и последующих постах я буду рассказывать о "Полезных метриках" и рассказывать об опасных способах их использования
Ниже я буду описывать метрики которые мы считаем крайне полезными для отслеживания качества процесса разработки. Мы делим их на 4 основных направления:
Для оценки производительности, мы используем: Velocity, WIP, Story Cycle Time(Avg),
- Производительность
- Прогнозирование
- Качество
- Ценности
Для оценки производительности, мы используем: Velocity, WIP, Story Cycle Time(Avg),
Velocity
Цель: Определить производительность команды за итерацию
Что измеряем: количество фитч в итерацию.
К сожалению наши фитчи не равны между собой, поэтому мы используем "Относительную оценку сложности" названную StoryPoints.
Цель: Определить производительность команды за итерацию
Что измеряем: количество фитч в итерацию.
К сожалению наши фитчи не равны между собой, поэтому мы используем "Относительную оценку сложности" названную StoryPoints.
Рост Velocity положительная характеристика.
Расчет Velocity
Оценка
Чтобы измерять Velocity вам нужно оценить ваш список задач в StoryPoints.
Два наиболее популярных способа оценки:
- Размеры в стиле "Ваш размер одежды": XS(1), S(2), M(4), L(8), XL(16), XXL(128), Unknown
- Planning Poker
Подсчет Velocity
- Считаем сколько реально сделанных задач в StoryPoints сделано за несколько итераций
- Вычисляем среднеарифметическое
Velocity = (SP1 + SP2+SP3+SPn)/n
ФактыVelocity изменяется, на это может влиять несколько факторов:
- Состав команды изменился. Каждый раз, когда у вас новый член команды или наоборот кто-то уходит, происходит спад производительности. При уходе члена команды он естественно больше, чем когда вы принимаете новичка. С приходом новичка, появляется потребность в притирке и обучении, что снижает вашу производительность на некоторое время.
- Улучшения в процессе повлияли на производительность, вы делаете ретроспективы, улучшаете свою работу, безусловно это может повлиять на вашу скорость выпуска функциональности
- Обмен знаниями. Чем дольше люди работают в проекте, тем больше они знают о проекте, тем быстрее принимают правильные решения: где и что нужно внедрить, написать, чтобы получить новую функциональность.
Важно:
Velocity возрастает - хорошо или плохо?
- Рост Velocity может означать, что ваша команда гонится за количеством выполненных сторипойнтов, возможно они жертвую качеством.
- Рост Velocity может означать, что ваша команда желая "повысить" свою производительность, оценивать функциональность в более крупных значениях, что приводит к инфляции ваших оценок.
Work in Progress
Метрика Work in progress пришла к нам из Lean Software Development.
С точки зрения эффективного процесса разработки (и производства), чем меньше задач в процессе работы, тем выше пропускная способность "Рабочей ячейки" (Команды)
Цель WIP: Повысить пропускную способность, повысить Velocity. Безусловно, само по себе значение WIP нам ничего не даст. Наша цель - Limit Work in Progress.
(In Sprint) Story Cycle Time
Это еще одна метрика, которую стоит отслеживать при анализе производительности вашей команды.
Цель SCT: Оценить производительность на уровне каждой фичи. Индикатор для оценки объективности Velocity.
Что измерять: Время старта задачи, время окончания (либо выпуска ее на продакшн - зависит от целей вашего ).
Как правило мы используем Story Cycle Time, как среднее значение (Avg. Story Cycle time), так как не все задачи имеют одинаковой размер.
Возможно вы спросите, зачем измерять и Cycle Time и WIP и Velocity (Velocity достаточно)? Дело в том, что Velocity, как метрика может искажаться и вы будете получать ложную информацию и принимать не правильные решения.
Причины могут быть разные (например: команда начала оценивает задачи в более крупных оценках, что приводит к инфляция Storypoints), но самое главное - вы получаете сигнал для того, чтобы собраться и проанализировать сложившуюся ситуацию, получаете возможность выявить проблему как можно раньше:
Вывод: Метрика Work in progress пришла к нам из Lean Software Development.
С точки зрения эффективного процесса разработки (и производства), чем меньше задач в процессе работы, тем выше пропускная способность "Рабочей ячейки" (Команды)
Цель WIP: Повысить пропускную способность, повысить Velocity. Безусловно, само по себе значение WIP нам ничего не даст. Наша цель - Limit Work in Progress.
- Ограничение способствует снижению риска не сделать за итерацию ничего
- Заставляет команду работать вместе над наиболее приоритетным функционалом вместе, что приводит к развитию кроссфункциональности.
- На фазе Development WIP = 5
- Testing WIP = 3
- Deploy WIP = 1.
Этот подход отлично решает проблемы сбалансированности работ в итерации: "Много кода, но мало протестированно". Теперь, чтобы взять еще одну задачу, нужно чтобы задачи "протолкнулись" на уровне тестирования.
- Высокий WIP является негативным показателем
- Низкий WIP - положительная характеристика, как для производительности, так и для команды в целом - показатель уровня кроссфункциональности.
(In Sprint) Story Cycle Time
Это еще одна метрика, которую стоит отслеживать при анализе производительности вашей команды.
Цель SCT: Оценить производительность на уровне каждой фичи. Индикатор для оценки объективности Velocity.
Что измерять: Время старта задачи, время окончания (либо выпуска ее на продакшн - зависит от целей вашего ).
Как правило мы используем Story Cycle Time, как среднее значение (Avg. Story Cycle time), так как не все задачи имеют одинаковой размер.Возможно вы спросите, зачем измерять и Cycle Time и WIP и Velocity (Velocity достаточно)? Дело в том, что Velocity, как метрика может искажаться и вы будете получать ложную информацию и принимать не правильные решения.
Очень важно валидировать результаты на всех уровнях, несколькими способами (количество StoryPoints за итерацию "сверху", контроль производительности спомощью WIP и SCT "снизу")
Например:
Вы измеряете Velocity, WIP, SCT. Фиксированные данные нам ничего не дают, все метрики интересны, если мы измеряем отклонения и делаем выводы.
В первом случае скорее всего это нехороший симптом. Повод обсудить на ретроспективе.
Например:
Вы измеряете Velocity, WIP, SCT. Фиксированные данные нам ничего не дают, все метрики интересны, если мы измеряем отклонения и делаем выводы.
- Velocity вырос.
- Cycle Time увеличился.
или
- Cycle Time уменьшается
- Velocity стабилно
и т.д.
Причины могут быть разные (например: команда начала оценивает задачи в более крупных оценках, что приводит к инфляция Storypoints), но самое главное - вы получаете сигнал для того, чтобы собраться и проанализировать сложившуюся ситуацию, получаете возможность выявить проблему как можно раньше:
- Может быть, имеет смысл переоценить весь бэклог. Возможно, менеджер использовал Velocity для давления на команду, и она невольно начала завышать оценки. Это породило рост Velocity "на бумаге", но не на деле.
- Возможно есть проблемы, с качеством.(в погоне за количеством)
- и т.д.
Комплексный анализ анализ Velocity и Story Cycle Time и WIP дают объективную информацию о скорости разработки:
- В фичах за итерацию
- Среднее время выполнения фичи в итерации.
- WIP используется как инструмент выстраивания сбалансированной работы в итерации. Стремясь сокращать WIP, вы будете находить решения, позволяющие вам повышать производительность.
Вы получаете объективную информацию (mistake proof), так как контроль Velocity (как основной бизнес метрики) подкреплен анализом WIP и StoryCycle Time.
