January 31, 2019

ХОРОШИЕ AGILE МЕТРИКИ

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

BURN-UP CHART

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

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

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

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

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

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

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

END-TO-END TIME TO MARKET (LEAD TIME)

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

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

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

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

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

ЭФФЕКТИВНОСТЬ ПОТОКА (FLOW EFFICIENCY)

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

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

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

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

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

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

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

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

КОЛИЧЕСТВО ЭЛЕМЕНТОВ В БЕКЛОГЕ

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

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

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

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

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

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

СРОК ЖИЗНИ ЭЛЕМЕНТА БЕКЛОГА

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

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

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

ЭВОЛЮЦИЯ DEFINITION OF DONE

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

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

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

Источник.