30 метрик успешности для Scrum-команд

30 метрик успешности для Scrum-команд

30 metrics

Скорость – одна из самых часто используемых и, одновременно, обманчивых метрик в Скраме. Многие Скрам-команды и стейкхолдеры вновь и вновь попадаются в ловушку собственных стереотипов, основывающихся на ложном убеждении: «со скоростью растет и производительность». На практике оказывается, что производительность - локальная метрика, которая часто слабо коррелирует с общей эффективностью бизнес-системы.

Почему скорость – «запоздавшая» метрика?

На практике же погоня за скоростью исполнения работ может стать той самой тесной петлей на шее команды, которая «убьет» все ранее положительные показатели работы. Это может выглядеть таким образом…

Команда Разработки, сфокусированная на исполнении максимального количества Пользовательских Историй, напрочь забывает о качестве своей работы и ее бизнес-ценности. Пытаясь поднять скорость своей работы любой ценой, команда может пропустить тестирование или же сделать менее качественный код. Вследствие этого, страдает Продукт, качественная разработка которого перестала быть целью, став лишь промежуточным звеном в погоне за количеством Пользовательских Историй…

Помните, что скорость – в некотором смысле, как и уровень безработицы, запоздавшая метрика. Согласитесь, Вам вряд ли удастся устранить проблему безработицы, фокусируясь только на ее показателях. В первую очередь, следует «лечить» экономику; по аналогии обстоят дела и со скоростью работы.

30+ метрик: как правильно измерить прогресс команды

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

    Метрики состояния процесса отображают ежедневную активность команды и процессные изменения:
  • кумулятивные диаграммы
  • диаграммы контроля
  • эффективность потока
  • процент завершенных задач
  • показатель потери времени из-за блокеров на задачу
  • кластеризация блокеров
    Метрики релизов отображают наличие в процессе блокеров, мешающих постоянному прогрессу команды:
  • устраненные дефекты
  • время, потраченное на устранение дефектов
  • показатель успешных релизов
  • время, требуемое для релиза
  • время, потраченное с момента последнего релиза
  • стоимость каждого релиза
  • адаптация выпущенной версии Продукта на рынке
    Метрики разработки Продукта отображают соответствие разрабатываемого Продукта потребностям пользователя:
  • ценность данного Продукта для бизнеса/конечного пользователя
  • минимизация рисков
  • рush / рull
  • рыночный прогноз по Продукту
  • анализ обратной связи от рынка
    Технические метрики отображают качество выполнения работы:
  • покрытие тестами
  • время построения
  • плотность дефектов
  • принадлежность кода
  • сложность кода
  • соответствие стандартам
  • краш-показатель
    Метрики командного взаимодействия отражают степень вовлеченности и сплоченности командной работы:
  • показатель счастья
  • возможности для развития
  • продолжительность совместной работы
  • открытость
  • прозрачность

ТОП-5 советов, как пользоваться метриками правильно:

  1. Молодой команде следует начать анализ своих процессов с применения 2-х метрик, добавляя через время одну или две метрики. Более зрелые команды могут одновременно использовать до 7 метрик. Как показывает практика, если количество метрик превышает семь, то команда впадает в «аналитический паралич».
  2. «Жизненный цикл» каждой метрики не должен быть менее 3-х итераций, порой для достоверных данных достигая 3 – 4 месяца.
  3. Метрики добровольно выбирают члены Скрам-команды для инспекции своих процессов. А значит, метрики не могут быть определены или назначены топ-менеджерами.
  4. В больших компаниях, где задействованы многочисленные команды, метрики не могут служить поводом для конкуренции или соревнований между командами. Метрики служат для инспекции командной работы и оптимизации процесса.
    При выборе метрик для инспекции своих рабочих процессов члены команды должны уметь ответить на такие вопросы:
  1. Почему именно эта метрика?
  2. Почему она значима?
  3. Какие ожидаемые изменения?
  4. Данная метрика измеряет командные показатели, а не индивидуальные?
  5. Как долго будет проводиться сбор данных по каждой метрике?
  6. Индикатором чего служит данная метрика?
  7. Как будет визуализироваться результат измерений и анализа: эффективный обмен знаниями, улучшенное взаимодействие в команде…?

ВЫВОДЫ:

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

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

Эти метрики не зря перекликаются с потерями в Lean. Ведь Scrum был основан на принципах и динамике бережливого производства.
Оставайтесь с нами, Scrum must go on!

Agile-эксперт и практик, Scrum-тренер и бизнес-наставник, имеющий опыт оптимизации процессов как в сфере IT, так и в смежных областях.

Может быть интерестно: