Когда команда растет, то появляются вопросы, на которые должен отвечать СТО:
1. А растет ли общая продуктивность команды в условных значениях?
1. Как меняется портрет компетенций команды?
**Динамика закрытия пулл-реквестов**
Растет команда разработчиков, а значит растет и количество пулл-реквестов. Если команда растет, но количество пулл-реквестов почему-то не следует тренду роста. Возможно, следует проверить источник загружаемых данных на предмет корректности. Ну или СТО должен поднять панику.
**Прирост кодовой базы**
Кодовая база в целом растет. Но сам по себе график ничего не даст: смотрим на динамику пулл-реквестов (они как раз не растут). Значит, надо разбираться.
**Активность разработчиков по часам и по дням недели**
На первый взгляд может показаться, что график бесполезный. Можно всего лишь увидеть, что количество коммитов максимальное в среду, а самые продуктивные дни — вторник и четверг. Но обратите внимание на активность в 22.00, которая не пропадает. Есть активность разработчиков и по субботам. Это не очень хорошо, надо разбираться, кто системно выходит на переработки, потому что разработчики должны отдыхать: есть такое явление, как «выгорание», ведущее к быстрой потере сотрудника.
**Безопасность вашей кодовой базы**
Всё построено вокруг метрики Bus factor (BF). Возьмем первую строчку на иллюстрации — сервис CLIC. У него BF = 1,07. Другими словами, только 1 разработчик обладает знаниями по этому сервису. И если он уйдет, то вам придется потратить много времени на погружение новичков в проект. Находим все такие сервисы и делим кодовую базу с другими разработчиками компании.
Если взять среднее значение метрики BF по всем сервисам и посмотреть за более длительный период, то виден тренд на рост (что хорошо). Раньше ноября 2020 года не смотрим, это явно проблемы с загрузкой данных из источников.
Теперь давайте разберем метрики, которые будут полезны тим-лиду. Чтобы он правильно работать с метриками, тим-лид должен быть прекрасно осведомлён, чем занимается каждый его человек, максимально погружен в стек и бизнес-смысл решаемых задач.
**Продуктивность разработчиков одной команды**
Синяя пунктирная линия — некая медиана количества кода, создаваемого этой командой разработки. По оси Y отложены асолютные значения по месяцам. Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики. Если так, то за ребятами надо наблюдать на дистанции полгода - год. Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.
**Churn**
Это доля строк кода, которые добавлены программистом при решении какой-нибудь задачи, но впоследствии удалены до релиза этой задачи. Метрика показывает долю работы (и времени), потраченную впустую. Она сигнализирует о том, что либо разработчик слишком мало времени тратит на обдумывание задачи и поэтому приходится переписывать, либо требования к задаче плохо формализованы.
**Bus factor разработчика**
Метрика показывает, в каких репозиториях этот человек является единственным контрибьютером. Потеря такого сотрудника будет для вас большой проблемой. На иллюстрации мы видим, что Иванов — единственный контрибьютер в 17 сервисах, Петров — в 11, Сидоров — в 10. Что будет после ухода Иванова, Петрова и Сидорова? Правильно, вникание новых инженеров в проект, которое может закончиться простым переписыванием и потерей времени.