Блог Scrum Украина

Agile-метрики команд. Часть 2. Хорошие метрики

Опубликовано 31.01.2019
Автор Евгений Лабунский & Дарья Алымова

Burn-up Chart

Что это: показывает как вы съедаете скоуп (объем) к дате или же, наоборот, к какой дате будет сделан этот объем скоупа.

Alt Text
Картинка с https://spin.atomicobject.com/2016/03/31/burn-up-charts/

Что мы тут имеем:

  • Ось Х —  спринты, ось Y —  объем. Объем меряем в Story Points или в штуках (количестве) задач.
  • Зеленый тренд  —  фактически поспринтовая Velocity команды.
  • Синий тренд  —  текущий объем задач и его изменение от спринта к спринту (то есть объем беклога).
  • Зеленый тренд  —  как команда спринт за спринтом “потребляет” беклог.

Что нам это дает? Мы можем прогнозировать. Например, когда будет сделан весь вот этот объем задач?

Alt Text

Или что будет сделано к Рождеству?

Alt Text

В Agile мире мы отдаем преимущество прогнозированию “к дате”, ибо объем задач, обычно, растет. Поэтому при планировании “от объема” вы можете попасть в ситуацию, когда “давайте еще доделаем эту задачу, потому что без нее никак”.

End-to-end time to market (Lead time)

Что это: эта метрика показывает, сколько времени проходит с момента появления идеи до момента ее фактической реализации и появления на стороне пользователя.

Часто в разработке команды измеряют то, как быстро они делают саму Feature, то есть сколько времени проходит с момента начала работы до продакшина.

Alt Text

Однако намного интереснее то, сколько времени прошло в целом от идеи до реализации. И вот почему:

Вы узнаете, сколько реально времени бизнес в среднем ждет одну фичу

А еще вы узнаете, сколько времени болтаются задачи в беклоге абсолютно без дела. Но это уже другая метрика :)

Эффективность потока (Flow Efficiency)

Любая работа – это совокупность активных стадий, когда работа выполняется, и стадий ожидания, когда задача ожидает выполнения или следующей стадии.

Alt Text

Alt Text
Source https://leankanban.com/flow-efficiency-a-great-metric-you-probably-arent-using/

Например, возьмем упрощенный процесс разработки с точки зрения задачи:

Проработка деталей — Разработка — Тестирование — Выпуск

В такой цепи “задача” будет находиться в активном состоянии тогда, когда над ней будет проводиться работа. Например, когда программист пишет код. Как только он закончил, то с точки зрения задачи активная фаза закончилась, то есть перешла в стадию “ожидание тестирования”. Тестировщик приступит к работе тогда, когда освободится от других задач.

Если вы считаете время, которое тратится на “работу” над задачей, то: есть активное время, а так же время, которое задача проводит в ожидании. И вы можете посчитать Эффективность потока — соотношение ожидания и активной работы.

Alt Text

Если работали над задачей 1 день (затрекали время), а фактически между активной работой она провела 2 дня (время ожидания), то эффективность такого потока = 1/(1+2) * 100 = 30%

Это значит, что 70% времени работа не ведется, то есть задача “простаивает”.

Количество элементов в беклоге

Что меряет: меряет количество элементов в бэклоге :)

Зачем мерять? Чтобы понимать, сколько мусора на вашем “складе”. С точки зрения Lean бэклог  —  это склад. Излишние складские запасы  —  один из видов потерь.

Alt Text

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

Чем больше ваш бэклог – тем меньше вы понимаете, что в нем хранится и тем меньше его фактическая актуальность

Более того, чем больше всех элементов, тем больше времени тратится на уход за ним, а также меньше прозрачность работы в нем.

Нет цифры, которая бы идентифицировала предел :) Это все очень специфично для команды/продукта/компании. Просто помните, что вряд ли стоит хранить задачи, которым несколько лет, что бы “не забыть” :)

Срок жизни элемента беклога

Предыдущая метрика тесно связана с этой метрикой : чем старее задачи в беклоге, тем меньше смысла они имеют.

Старость беклога обычно гворит о следующих проблемах:

  1. Накопительство : задачи создаются, чтобы “не забыть”.
  2. Отсутствие “владельца” беклога. То есть отношение команды к нему как к арендованной машине: вы ее не моете. Всем все равно, что там у них делается. То есть с беклогом не работают, не “грумят”.
  3. Владелец продукта не умеет говорить НЕТ, потому посто добавляет все, что его просят.

Чем меньше срок жизни – тем понятнее контент беклога, проще с ним работать и повышается его актуальность.

Эволюция Definition of Done

Как измерить работу Scrum Master? Очень просто . Нужно понять то, насколько растет Definition of Done его команды. Этим же можно измерить “взросление команды”.

Alt Text

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

Если команда год сидит с критериями “код написан и протестирован”, то за прошлые 12 месяцев вы не стали больше Agile в вашей компании. Вы остались на прошлом уровне. Не развились технически, управленчески и продуктово.

Coaching Advanced Scrum (часть 1)

Продвинутые Scrum команды - какие они? Что они делают по-другому? Их процесс проще или сложнее? Как они стали такими, какими они есть? И что ещё более важно - как нам двигаться в правильную сторону?

Недавно на Scrum Ukraine вышло моё 1.5-часовое интервью – подкаст, где мы с Женей Лабунским пытались разобраться в том, что же такое “advanced scrum” и что значит быть продвинутой Scrum командой и компанией. Эта статья – попытка подытожить и упорядочить эту важную тему.

Читать статью

Мы активны в социальных сетях и хотим общаться. Добавляйтесь на нашу страничку в facebook и присоединяйтесь к нашим сообществам.

По вопросам коучинга и корпоративных программ:
+380 63 810-72-25 Евгений
hello@scrum.ua

По вопросам публичных классов, регистраций, счетов:
+380 68 239-1778 Ирина
backoffice@scrum.ua

По вопросам рекламы и сотрудничества:
+380 068 24-57-452 Даниэлла
pr@scrum.com.ua

По всем номерам телефонов - голос, sms, viber.

©2017 - 2019 Scrum Ukraine. Все права защищены.