Про DORA-метрики (или как посчитать эффективность разработки)

Ранее я уже писал про фреймворк DevEx (Developer Experience), с помощью которого можно оценивать состояние IT-специалистов и его влияние на перфоманс отдельных команд и подразделений. Тогда я упоминал так называемые DORA-метрики, с помощью которых собственно и происходит оценка эффективности отдельных специалистов или команд. В этот раз речь пойдёт как раз про них.

DORA = DevOps Research and Assessment. Эти метрики были разработаны командой Google Cloud для оценки эффективности процессов разработки и доставки программного обеспечения. В итоге, чтобы оценить качество DevOps, используются 4 основные метрики:

а) Deployment Frequency (частота развёртываний) — метрика, показывающая, как часто код выпускается в продакшн. Показывает скорость реакции команды на запросы клиентов или изменения рынка.

б) Lead Time for Changes (время доставки изменений) — время, необходимое для того, чтобы изменения в коде попали в продакшн. Чем меньше, тем лучше.

в) Change Failure Rate (доля неудачных изменений) — доля развёртываний, которые приводят к сбоям в продакшене и требуют отката изменений или срочного исправления (hotfix'а).

г) Time to Restore Service (среднее время восстановления) — время, необходимое для устранения сбоя в продакшене. Также чем меньше, тем лучше.

Это классические метрики DORA. Затем к ним прибавилась пятая — Deployment Rework Rate (доля деплоев, которые случились внепланово из-за уже возникшего в продакшене инцидента). Разница с CFR в том, что CFR — про качество самого процесса доставки (насколько надёжно код попадает в прод), а Rework Rate — про объём реактивной работы (сколько ресурсов уходит на ликвидацию последствий, а не на развитие продукта). Кстати, посмотреть на бенчмарки по этим показателям можно здесь.

Сама концепция DORA-метрик впоследствии дополнилась оценкой состояния сотрудников (субъективная сторона разработки) и тем самым объединилась с фреймворками DevEx и SPACE (о последней расскажу в следующий раз).

Сегодня IT-компании пытаются создать целое дерево метрик — объективных (как DORA) и субъективных (как DevEx), способное отслеживать качество delivery-процессов в разработке (как это делает, например Т-банк, можно почитать в их статье). Когда мы проводим исследования DevEx для компаний, мы также стараемся сопоставить оценки сотрудников с объективными данными качества разработки, чтобы выявить узкие места и приоритетные зоны для улучшения IT-среды.

В итоге DORA-метрики позволяют оценить качество DevOps в компании, но, имея на руках только эти показатели, невозможно понять причины, почему каждый второй релиз сопровождается серьёзными багами. Для этого нужно провести исследование опыта разработчиков и выявить их отношение к IT-инфраструктуре и рабочим процессам, что позволит наметить дальнейшие шаги по совершенствованию среды разработки в компании.