Обзор на разные метрики для оценки продуктивности команды разработки.

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

Зачем нам нужно замерять команды разработки:

1. Метрики позволяют понимать производительность
2. Замеряя метрики, команды могут видеть свое развитие
3. Метрики могут быть использованы для принятия решений
4. Метрики позволяют убедиться, что разработчики следуют целям бизнеса
5. Устанавливать цели
6. Позволяют обсуждать прогресс проекта со стейкхолдерами
7. Улучшение метрик положительно влияет на мораль команды
8. Метрики позволяют увидеть, что ресурсы используют неээфективно
9. Метрики позволяют убедиться в достаточном качестве продукта

Но как правильно померить команду разработки? Это нетривиальная задача и подходы к решению этой задачи менялись с течением времени

Когда то давно, достаточно было замерять строчки кода (например, в книжке "мифический человекомесяц" часто встречаются кейсы, где проекты замеряются по строчкам кода).

Затем перешли на измерение velocity и cycle time. Velocity замеряет объем поставляемых в итерацию задач. Cycle time - время от "взяли задачу в проработкуработу" до "поставили ценность клиенту". Эти метрики уже намного ближе к бизнесу, чем строчки кода. Они проверяют, насколько команда гибкая (насколько быстро она проверяет гипотезы)

Позже, DevOps движение принесло DORA (DevOps Research and Assessment) - 4 ключевых метрики, по которым можно понять эффективность команды:

1. Lead Time: сколько времени проходит от появления идеи до получения её клиентами
2. Deployment Frequency: как часто команда поставляет изменения (деплоит в прод)
3. Change Failure Rate: как часто изменениям нужны правки или переделки
4. Mean Time To Recovery: как быстро мы можем исправить проблему, если она появилась

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

Следующий набор метрик - SPACE.

1. Satisfaction
2. Performance
3. Activity
4. Communication and collaboration
5. Efficiency and flow

Тут уже делается акцент на уровне счастья разработчика и на эффективности процессов. Но при этом, в статье (я не понял это прям в SPACE предлагается или в статье так интерпретировали этот набор метрик) предлагается замерять скорость и эффективность Code Review, что, на мой взгляд, не очень хорошо

В этом году появился DevEx, который предлагает замерять циклы обратной связи, когнитивную нагрузку и возможность для потоковой работы в разрезе персональной работы, системы и KPI

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