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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статья от 12/2011