В 2022 году мы приняли решение объединить множество показателей, связанных с разработкой, в интегральную метрику Contribution. Данной метрикой мы диагностируем Code review и считаем вклад разработчика в продукт.
Формула расчета метрики выглядит как сумма произведений весов на выполнение показателей:
∑ {вес} показателя ✕ {выполнение} показателя
где:
вес - значимость показателя (0-1)
выполнение - отклонение текущего показателя от референса
Формула такая ввиду множества показателей, а также их распределенности по процессу (часть активности, связанные с авторством, а часть с рецензией). В ходе работы с метрикой веса несколько раз переопределялись, чтобы добиться более точного попадания в ожидаемые результаты, полученные по результатам обработки обратной связи от потребителей.
Референсы вычисляются для каждого показателя отдельно, как 30 percentile и 70 percentile, в зависимости от мотивации роста или падения значения. Выполнение считается 100% при достижении или превышение (30 percentile) / не превышение (70 percentile) референсного значения, при этом неполное достижение вычисляется, как отклонение от рефернса. Выполнение 0% возникает только в случае, когда конкретное событие отсутствует.
В результате на выходе из модели мы получаем значение от 0 до 100%.
В виду динамического вычисления референсных значений, нет цели держать показатель метрики в 100% — зона нормальности 30-100%.
Как вы наверное уже догадались, Contribution является индикатором (светофором), подсвечивающим экстремально низкие значения показателей, включенные в модель. Сигналы помогают нам фокусироваться на потенциальных проблемах в производственном процессе или в работе команды.
Сейчас расскажу, зачем это нужно и как мы пришли к этой метрике.
Зачем нам это нужно?
Давайте представим, что мы работаем над важной (других и не делаем) задачей со сжатыми сроками, но по непредвиденному стечению обстоятельств приняли решение покинуть команду (причины оставим за скобками). Ситуация и так неприятная, но немного усугубим. Все наработки в рамках задачи ушли вместе с собой (просто у меня всё в голове и больше нигде).
Для организации это означает потерю инвестиций, а также возможные финансовые и репутационные риски.
Чтобы нивелировать в будущем подобные ситуации, необходимо управлять регулярностью вносимых изменений в продукт. С уходом сотрудника команда столкнулась с рисками срыва сроков, но, если его наработки остались бы у команды, вновь пришедший стартанул бы с базы, а не с чистого листа.
Так мы пришли к Contribution
Началось всё с кодовой базы. Код самый понятный нематериальный актив организации с точки зрения конечной ценности: он собирается в приложение и исполняется в автоматизации бизнес-задач.
При этом сколько существует код, его анализируют по куче параметров и критериев. Можно достаточно быстро найти в интернете метрики, показывающие либо различные действия с кодом (commit, pull request, comment, approve и т.д.), либо его характеристики (объем изменений, кол-во строк, зависимость и т.д.).
Изучив опыт коллег и проведя внутренний анализ в рабочих группах технических лидеров компетенций, было принято решение за основу модели мониторинга вносимого изменения в продукт взять процесс code review. Данный процесс предусматривает рецензирование вносимых изменения, а, следовательно, можно говорить о конечной ценности каждого изменения.
Выбор показателей
Не хочу сказать, что слишком долго выбирали. За пару встреч мы пришли к следующим умозаключениям — мы не взяли в качестве метрики количество строк кода или объем изменения (kB). Изначально объем действительно выглядел, как самый прямой и понятный показатель, но в итоге мы отказались от него. И вот почему:
Сложность вносимого изменения не всегда соответствует объему.
Copy-Paste кода из файла в файл приводил к сильным аномалиям показателя.
Вызывает негативную мотивацию разработчика не использовать лаконичные конструкции в угоду более тяжеловесным и объемным.
Также сразу же отказались от кол-ва commit-ов, ибо это событие не всегда означает, что изменение функциональности готово. По сути commit может нести только часть функционала — нет завершенности.
Наш выбор остановился на merge PR.
Pull Request (PR) инициирует процесс review code, является ключевым событием, но не каждый завершается слиянием. При верно настроенном gitflow merge предполагает успешно пройденные проверки изменения, что должно подтверждать его качество, с точки зрения дальнейшего развития (соответствует code style, стандартам, закомментирован и тд).
Approve — согласование изменения проверяющими. Показатель принятия изменения в продукт, что способствует повышению качества кодовой базы. Это ключевой инструмент review code, так как без необходимого кол-ва согласований PR не будет слит в целевую ветку кода.
Needs work (NW) — PR отправлен на доработку. В отличие от Approve явно указывает автору, что изменение не будет принято, даже, если еще не все согласующие его проверили. Данный инструмент помогает экономить время проверяющих, т.к. видя статус «на доработке», они просто не берут PR на review.
Comment — комментарии изменения в процессе code review. Это могут быть как вопросы, так и предложения/замечания к предложенной реализации. Конечно, в ходе review это просто способ фиксирования обратной связи и коммуникации, но при ретроспективе ранее внесенных изменений позволяет провести более предметный анализ, а иногда ответить на вопрос, почему принято именно такое решение.
Время жизни PR — длительность исполнения процесса code review. Длительные PR порождают две проблемы:
Большой объем изменений затрудняет его проверку.
Сильное отставание версии кода приводит к большому количеству конфликтов при слиянии, которые требуют дополнительных усилий.
Частота выставления PR — время между ближайшими PR. Регулярность внесения изменений позволяет получать все бенефиты практики Continuous Integration (CI) (раннее обнаружение ошибок, снижение рисков проектов, повышение качества, ускорение разработки, прозрачность для команды)
На базе шести показателей было принято решение построить модель.
Работает ли метрика?
Мы базово анализируем помесячную динамику интегрального показателя. Если динамика не устраивает или продолжительное время показатель низкий, разбор происходит на уровне каждого события в Git.
Поделюсь несколькими популярными обнаруженными кейсами:
нашли backlog команды, в котором нет задач на разработку (предпроект, исследования, оценка и т.д.);
обнаружили, что большие изменения долго «томятся» в бранчах фичей, а после выставления PR он долго проходит review;
нашли лоббирование в команде старшего разработчика, когда младший, по сути, выступает в роли падавана и не решает задачи самостоятельно.
Как думаете, стоило ли внедрять нашу метрику, чтобы обнаружить такие случаи?
Основные потребители метрики Contribution — функциональные руководители и технические лидеры в ежемесячном ритме и Директора при анализе на более длительных периодах. Метрика позволила руководителям оперативно проверять субъективную обратную связь по работе команды разработки, всегда иметь под рукой верхнеуровневую картину по своему направлению.
Метрика показательна для оценки активности с артефактами (документация, кодовая база, тест-кейсы). Мы понимаем, что сотрудники могут определенное время решать задачи, не связанные с ведением артефактов, показатель закономерно снижается — это ожидаемо (управляемо).
Результаты пилотов показали, что в 70–80% случаев метрика корректно подсвечивает проблемную область. При этом нужно понимать, что достижение 100% точности сигналов в принципе невозможно ввиду наличия исключительных кейсов на производстве (узкая специализация, редко исполняемый процесс и т. д.).
Также, в ходе исследований показателей, выявили неоднородность в настройках gitflow, что подсветило, потенциальные, проблемы в процессах и культуре работы с артефактами в организации.
А вы задумывались об оценке изменений в ваши продукты? Напишите в комментариях свой опыт в измерениях.
Подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.
Читайте также:
