Как использовать метрики для оценки процессов разработки
Что проверяют
Умеете ли вы отличить метрику, которая помогает команде, от метрики для отчёта. Следом спрашивают, какую метрику вы сами вводили и что после этого поменялось.
Как отвечать
Стройте ответ от цели: проблема, показатель, решение, принятое по нему. Для мобильной команды набор обычно такой:
- поток поставки: частота релизов, время от мержа до пользователя, доля релизов с хотфиксом. Это метрики DORA с поправкой на мобильную специфику, где между мержем и пользователем стоят ревью стора и поэтапная раскатка;
- стабильность: доля пользователей без крэшей в Firebase Crashlytics, частота крэшей и ANR в Android vitals. У Google Play для них есть пороги «плохого поведения», за которыми приложение хуже показывается в магазине;
- скорость разработки: время сборки Gradle локально и на CI, время от открытия PR до мержа, доля нестабильных тестов. Медленная сборка съедает часы в день, и её легко перевести в деньги;
- качество кода: покрытие тестами критичных модулей, число предупреждений
lint, но как сигнал, а не цель.
Дальше пример из своего опыта: что измеряли, где собирали (Gradle build scans, дашборд CI, Crashlytics), какой был порог и что сделали. Скажем, PR ждали ревью по два дня, команда ввела правило первого ответа в течение рабочего дня и через месяц сравнила время до мержа. Цифры нужны ваши, выдуманные проценты разваливаются на первом уточнении.
Если метрики в команде никто не вёл, так и скажите и объясните, с каких двух-трёх показателей вы бы начали и почему.
Где спотыкаются
Предлагают мерить людей: строки кода, коммиты, закрытые задачи на человека. Как только метрика становится оценкой, её начинают накручивать.
Сравнивают velocity между командами. Story points у каждой команды свои, это инструмент планирования, а не мера производительности.
Называют десяток метрик и ни одного решения, принятого по ним. Метрика, на которую никто не смотрит, не нужна.