Визуализация и анализ git log. Проводим аудит команды разработки.

Инструмент заточен на команды из 3..6 — программистов, которые работают на проекте полный рабочий день уже 3..5 месяцев. Демо тут, потрогать со своими данными тут, исходники тут.

Идея:

— взять лог системы контроля версий;

— выявить паттерны и связь разных событий;

— показать статистику и рекомендации;

Готовые аналоги:
— около 25 бесплатных скриптов на github, где нужно долбиться в консоль и быть программистом;
— 6 полноценных продуктов, но все через интеграцию (даже демо только под заказ). В два клика свои данные туда не закинуть.

Это может сделать таск-трекер?

Бывает так, что картина в коде не совпадает с картиной в таск-трекере. Да и таск-трекеры бывают так себе.

Выставлять KPI программистам за коммиты плохо!

Так никто и не выставляет. Главная задача системы: визуализация данных и поиск паттернов. Я даю велосипед, а вставлять палку в колесо или нет, вы решаете сами.

Итак представьте, вы пришли в новый проект. Вам дают команду из 8 программистов (фронт/бек). Проекту полтора-два года. У вас уже есть доступ к коду и возможность сохранить лог. Что можно узнать о команде?

График позволяет прикинуть темп, сезонность работы, а также стадию проекта. Пример:

Можно кликнуть на день и узнать кто конкретно пришел или уволился, а также список задач, над которыми работали в этот день.

Пример:

В некоторых конторах нужно списывать время на задачи. Обычно это +/- формальность, в виде размазывания 8ч на количество задач в день. Если разработчики нормально подписывают коммиты, то этот график строится автоматически:

Можно посмотреть кто что, примерно, делал и когда. А если нам нужна динамика по неделям, то есть и такой график:

Вот тут хорошо видно, что количество задач каждую неделю уменьшается. И тут же можно проверить гранулярность (она небольшая). Значит команда берет мелкие задачи и очень медленно делает их, растягивая время. Почему так вышло? Выглядит как недогруз. Может пора сократить состав?

Не всегда удается построить этот график, но если удалось, то можно прикинуть скорость поставки. Если задачи +/- однородны по объёму и срокам, а состав команды не меняется — можем получить прогноз времени на одну задачу от взятия в работу, до влития в релиз (или develop).

Но в плане аудита более интересен график долгоживущих PR. Работа была закончена, но код влили спустя длительный промежуток времени:

Как так вышло? Задача была не нужна? Тестирование не принимало код? Заказчик фичи пропал? Этот список (его содержание и длина) почти всегда является индикатором проблем.

Продолжая тему редких графиков, которые не всегда удается построить:

В моем отделе, например, этот график покажет, что лид. фронта втихую заливает код мимо тестирования. Фактический состав релиза отличается от того, что описан в документации к поставке.

Но с точки зрения внешнего аудита мы можем сразу обратить внимание на сбивку дат: релизы идут каждый день, а потом перерыв две недели. Что это было? Выкатили кучу багов? Уволились люди? Сломался CI/CD? Собственно, вот ещё один повод поговорить с командой о проблемах.

У нас в процессе работы произошло два события: мы переехали с одного таск-трекера на другой, и команда поделилась на две. Все это привело к потере части задач и путанице в нумерации. Хорошо, что разработчики подписывали свои коммиты номером задачи. Система составила список задач, по которым заливали код:

Это поможет вам пережить разные атаки в стиле «подготовьте отчет о работе за 1й квартал 2007 года»

А вот фичи в тексте коммита указывают крайне редко (почти никогда). Но если настроить такое правило в пре-коммите, то через полгода вы сможете собрать фактические данные по затратам на ту или иную фичу «с полей».

Дальше больше. Зная среднюю зп и, кто сколько работал над фичей, система автоматом прикинет стоимость фичи, а также покажет вклад разных разработчиков.

Аналогичная методика подсчитывает и файлы, над которыми работала команда. Это позволяет легко определить зоны компетенций, даже если вы ещё не успели познакомиться с самой командой программистов.

Так же в разделе «сотрудник» вы можете более подробно ознакомиться с паттерном поведения каждого члена команды. Например оценить персональный темп работы:

Или типичный распорядок дня:

Вообще предполагается, что команде не говорят о том, что кто-то анализирует лог git`а. Это изменит их поведение. Но если вся эта статистика будет использована как просто «забавные графики» раз в пол года, то есть целое направление «виральных фич». Например гора разного вида достижений:

Это только часть основного функционала. На основе собранной статистики система так же может сама задавать вопросы или давать рекомендации, чтобы вы обратили внимание на те или перекосы в данных:

Попробуйте на своей команде или чужом проекте. Сравните свои ощущения с тем, что скажет система. Все бесплатно и доступно онлайн. Так же есть отдельные модули для сбора инфы по микро-сервисам и просмотра отчетов вообще без снятия лога. Но за этим в личку ^_^