Метрики и сантиметрики. Или в поисках agile метрик

Обычно я начинаю зевать на втором абзаце статей о метриках, но тема полезная.

 

«Метрики — это зло!», — так всегда открывает тему метрик Серёжа Дмитриев, когда на тренингах всплывает вопрос метрик в Скраме.

 

Почему же сразу зло? Да потому что люди будут подсознательно вести себя так, чтобы повысить метрики, которыми вы их будете измерять. “Show me how you’ll measure me, I’ll tell you how I’ll perform” — гласит народная мудрость. В результате, метрики улучшатся, а ситуация — нет.

Что же делать?

 

Нужно держать метрики в секрете и никому не показывать!

Но как же прозрачность, самоорганизация и отсутствие единой точки менеджмента в Agile?

Хм… Что-то здесь не так.

 

Может быть мы просто не то измеряем?

 


Идеи метрик

Когда-то на заседании Скрам-мастер клуба мы обсуждали тему метрик и смогли накидать несколько идей:

  • процент работы в парах;
  • длина тест цикла;
  • количество замечаний от заказчика;
  • процент покрытия тестами кода;
  • соотношение найденных багов на спринт;
  • время от нахождения до починки дефекта;
  • время от возникновения до реализации фичи (в lean — «время цикла»);
  • функция от количества новых и ушедших заказчиков;
  • рейтинг приложения и т.п.

Многие из этих идей кажутся подходящими, но какую выбрать?

Как найти полезную метрику?

Нам удалось задать несколько вопросов PO продукта для банковской сферы. Мы пытались найти наименьшее количество высокоуровневых метрик:

 

— Если бы через год ваш процесс разработки стал намного эффективнее, что бы для тебя изменилось? — спросили мы.


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

сказал нам PO, чуть подумав.

 

— А как при этом ты убедишься, что не упало качество?


— Количество циклов на доработку и количество дефектов фазы бета-тестирования не стали бы выше! — таков был ответ о качестве.

 

Хорошие высокоуровневые метрики. Но что бы нам, интересно, сказали члены его команды, тестировщики, архитекторы, аналитики и бизнес-заказчики? Мне кажется, что ответы были бы другими и, к тому же, разными.

Когда-то я коучил со-владельца одной украинской продуктовой компании.  

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

 

Всё, к чему нам удалось прийти:

  • время выхода работающих версий;
  • интуитивное качество продукта;
  • количество переработок персонала.

Почему же такие разные метрики? Похоже, что всё зависит от того, какие цели ставит тот, у кого мы спрашиваем о метриках и каков его взгляд на процесс.

«Мерить или не мерить?» — вот в чем вопрос.

Увеличение дефектов — это проблема?

 

Скрамовский burndown график показывает зависание прогресса — это проблема?

 

Упали графики увеличения покрытия тестами кода — это проблема?

 

Часть команды сидит без дела — это проблема?

 

Одним из 14 принципов Toyota  является следующий: «Хочешь разобраться в ситуации — посмотри на всё своими глазами», или просто 現地現物 (Genchi Genbutsu), что буквально значит «иди и посмотри».

 

Значит, независимо от того, насколько хороши ваши метрики и что они вам говорят, не делайте никаких выводов. Идите и поговорите с вашей командой. Меряйте. Но не делайте выводов.

Коллективная выработка метрик

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

 

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

Хорошие дискуссии о метриках

Вот примеры вопросов, которые помогут вам обсудить метрики с командой:

  •  Как мы узнаем, что улучшаем процесс/продукт/качество?
  •  Как мы узнаем, что не стало хуже?
  •  Если мы повысим эффективность нашего процесса за полгода, что изменится?
  •  Что нам замерять периодически, чтобы понимать, что мы на правильном пути?
  •  Как бы наши заказчики могли увидеть повышение нашей эффективности?

Удачных замеров и измерений!

Статья от 12/2011


Write a comment

Comments: 0