Comments 50
Статистика по коммитам такое себе
Если в компании построен процесс на пул-реквестах то отталкиватся надо от этого, потому как вася таску закрывает за один коммит, а петя за пять. Продуктивность у обоих одинаковая, но при этом в статистике петя будет лидировать.
Не понятно по какому показателю. Ведь и тот и тот сделал по одной задаче за одной и то же время.
В глобальном плане Вася получит негативную ачивку, т.к. редко сохраняется и если уронит ноутбук то потеряет весь код за день или неделю
Не понятно по какому показателю. Ведь и тот и тот сделал по одной задаче за одной и то же время.
Нет, Вася сделал одну задачу, но чётко по требованиям, а Петя, кроме этого, еще и закрыл 5 багов (фиксил свои же баги по замечаниям).
Что касается коммитов - и правда, очень спорная метрика. Был у нас в команде один товарищ, с ролью билд-мастера. Как сделает новый бранч, поправит номер версии, соберет билд и закоммитит артефакты (все через скрипты) - сразу в истории ВЗРЫВ на 200+ файлов и десяток коммитов. Раз пять в день. Это было лет 10 назад, не помню чем считали это, но тем не менее.
Считать по LOC и тп - тоже не очень вариант. Сейчас автогенерируемый код (миграции, патчи, CMakeLists, etc) довольно часто встречается.
Если билд-мастер работает через скрипты, то скорее всего используется отдельный чистый клон репозитория для этой активности. Можно в конфиге прописать коммитера как "Build Master" чтобы в коммитах это имя светилось и у него будет отдельная статистика.
Другой вопрос что скорее всего в связи с этой ролью у основного аккаунта коммитов будет негусто.
А оно считает с основного бранча только статистику или вообще по всем веткам сразу? Можно ли в последнем случае ставить ветки в игнор? Форс пуши как-то афектят сбор статистики или оно парсит только git log, но не reflog?
Оно считает с той ветки, где стоишь. Парсит только git log, т.к. сам отчет это просто HTML а входные данные для него формирует этот самый git log. Не влитые ветки учтены не будут.
Поэтому ежедневный мониторинг KPI не про этот отчёт. Нужна какая-то стабильная ветка с множеством влитий и большой период времени (например, ветка релиза, или мастер) на которой можно смотреть глобальную стату прошлого.
В Bitbucket есть специальные плагины для этого, вот например
https://marketplace.atlassian.com/apps/1210934/awesome-graphs-for-bitbucket
Подсчет коммитов это бред, разные люди - разные паттерны. Кто-то коммитит каждый раз перед уходом с работы делая бекап кода (не надо так), вместо того чтобы коммитить рабочий код или разделять функциональные изменения для возможности независимого отката. Кому-то хочется красивой и чистой истории, и в команде принято делать squash чтобы схлопнуть все коммиты в один, перед тем как создать pull request.
Можно считать LOC (без комментов и пустых строк), можно считать hit line (только по актуальным строкам кода), можно считать удаленные и добавленные строки. Можно вычислять владельцев кода по процентному соотношению в модуле/репозитории, можно смотреть кто больше всех делает review и оставляет комментарии. Можно делать частный change rate, можно общий, можно по дням недели, можно по времени.
Но как только это перерастает в попытку оценить реальную производительность или вовлеченность, значит пора сваливать с такого проекта.
Если принята практика после аппрува MR все коммиты его составляющие сжимать в один и только потом мержить, то статистика в таком случае будет одинаковая.
О, вы за КПИ для программистов в измеряемых величинах?
Мерить эффективность сотрудников в коммитах это прям победа, поиск "коммитят фрилансеры вместо него" — путь к "нам нельзя врать, вы должны каждую секунду лично работать, что работать неважно, важно что обязаны быть заняты" (с)
Я это к чему, помню недавно была пара месяцев когда ковырялся в нутрях огромного монолита… и по итогам четырех двухнедельных спринтов сгенерил 3 (три!!) коммита, причем два из них из 2-3х строчек, при этом я копался в коде весь рабочий день с утра до вечера 5 дней в неделю.
Видимо с вашей точки зрения я просто кошмарный программист и по статистике гита меня надо уволить
можно сказать что это проект плохой и документации нет, но мне то какое дело? у меня есть задача я её сделал, монолит писал не я, его корни растут из начала нулевых годов
большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
да, но в гите коммитов то нет, только "а на дейликах ссал в уши ездил по ушам."
В данном случае чувак может сказать "исследую", а не "код написал, отправил на тест". Тот который "ссал в уши" он именно говорил что код готов, а вопросы возникли в момент интеграции, когда оказалось, что кода не было.
Тот который "ссал в уши" он именно говорил что код готов
код готов — это есть MR(PR) тоесть есть коммит, если MR-а нет то это тупо болтология
Я своих ребят всегда прошу пушить рабочие ветки и делать WIP MR-ы чтобы следить за прогрессом и перехватывать моменты когда они не туда уходить начинают
он именно говорил что код готов, а вопросы возникли в момент интеграции,
Все вопросы - к менеджерам, правда же? Если новый человек на испытательном сроке, то надо контролировать минимум раз в день. Если проработал месяца три и понятно что он умеет - все равно раз в неделю какой-то результат должен быть, хотя бы в своей ветке. Если у него задача на 2 месяца одиночной разработки - ну вы же понимаете что это тоже просчет менеджера в постановке такой задачи.
Нет.
Про КПИ уже выше писал, что это бред. Даже заголовок сделал "дефективный менеджер"
Про пару коммитов в монолите — тут на длинных отрезках нужно смотреть. Думаю если взять отрезок пол-года..год то там будет некое "среднее", которое не будет меняться и будет больше 3 комитов в спринт. Во вторых, как и писал выше, в разных конторах разные ситуации. Возможно для данной конторы и проекта это норма. Как и написал выше "невозможно сделать вывод не зная проекта"
Про пару коммитов в монолите — тут на длинных отрезках нужно смотреть.
правильно, а в вашем примере
Спустя четыре месяца (испытательный закончился) у многих закрались подозрения
подозрения должны быть не в измерениях количества коммитов, а в сути закрываемых задач
я из своей команды увольнял миддла, потому что он коммитил знатно, но такой бред что уши в трубочку заворачивались… причем успел задолбать всю команду тупыми вопросами… когда через пару месяцев я прикинул что грубо говоря из 10 его тасок, лично я за него сделал 8… мы с ним расстались… это было и без построения графиков и расследований ясно что человек не может работать
Тут не спорю и согласен. Это было вступление о том как менеджеры у нас вообще в паралельном мире. Я сам не его лид, а первый раз взаимодействовал с ним уже в районе интеграции.
Отчет в этом случае так же не особо имел бы пользу, т.к. проблема в адовой бюрократии
Ну то есть вам понятно что менеджеры косые, однако вы пишете инструмент для учета KPI программистов?
Я пишу инструмент для визуализации вывода git log. Проблема менеджеров им не решается. Странные KPI - это следствие работы косых менеджеров, а не инструмента визуализации.
Например, отчёт выводит "самые популярные слова" или ачивку за самое длинное / короткое имя на проекте, или можно посмотреть кто больше коммитит до обеда, а кто после.
Поддерживаю. Сергей Немчинский тоже подобную историю на стримах рассказывал, когда работал на галере и ему надо было исправить хитрый баг в индусском коде. Он искал одну строчку (или даже один символ) почти месяц. Нашел и исправил.
Все так, работу программиста бесполезно измерять - кроме шума ничего не намеряется. Кто-то берет самые простенькие задачки для новичков и строчит их как из пулемета, это явно ценный специалист, а другой берет самые тяжелые и критичные для бизнеса проблемы, вкладывает много сил в исследования и расследования, докапывается до фундаментальных причин, поэтому у него всего пару коммитов в неделю - явно это самый бесполезный человек. И так в любой статистике, потому что работа во многом творческая, для нее даже метрик адекватных не изобрели. А когда на человека какая-либо статистика повесит маркеры - все, конторе кирдык, эффективный менеджер проник в управление, начинается отрицательный отбор: по маркерам удобно увольнять самых "неэффективных", согласно именно такой вот смешной статистике.
В Embedded ещё хуже, чтобы пару строчек написать нужно разобраться в железе и SDK как правило без документации ) И потом компилировать ядро Linux, которое не очень быстро собирается.
помню недавно была пара месяцев когда ковырялся в нутрях огромного монолита… и по итогам четырех двухнедельных спринтов сгенерил 3 (три!!) коммита, причем два из них из 2-3х строчек
Мне это напомнило, как в 1998 году я в течение 2-х недель без перерыва искал причины одного хитрого бага в системе планирования полетов авиакомпании KLM. Сидел за компьютером не вставая с утра до вечера.
И потом по итогам расследования написал 3 строчки кода, решив проблему.
P.S. Как вспомню, так вздрогну. На мейнфреймах не было отладчиков, и единственным способом отладки была расстановка операторов PRINT в коде программы. При этом вывод записывался в один из трех файлов (файл выбирался случайным образом). При этом параллельно в эти файлы писали еще десятки программ, так что найти результаты моей печати само по себе было проблемой.
Вот у меня есть два инженера (на самом деле больше, но рассмотрим два):
один фигачит, много коммитов, много тасков;
второй мало фигачит, но постоянно находит какие-то грабли, много времени на этих граблях сидит, пытается понять что не так и как так не так.
В целом, я доволен обоими, конечно, мой внутренний невротик бесится, но польза, очевидно, разная и по разному оказывает влияние на проект. Метрики по Commit, PR, циклах review - это отлично, но без компетентного человека, который понимает суть происходящего могут только навредить. В целом, проект автора полезный, но всегда есть желание механистически что-то применять и получить красиво - так не бывает.
Да, оценка трудозатрат по гиту это такое.. Один сделает пять коммитов, в которых выложит мегафичу, решающую огромную бизнесзадачу, другой зафигачит за то же время триста коммитов плана - "фикс моего факапа из предыдущего коммита".
Опять же как учитывать ситуации, вроде вот недавнего случая из моей практики - полторы недели искал причину кривой работы одного отчета, перерыл код, запросы, все вроде должно работать правильно, но не работает. В итоге проблему нашел - исправил ровно одну букву (не шучу, одну, мать ее, букву в коде) и баг был исправлен. По KPI количество коммитов - я все эти полторы недели просто нихрена не делал, получается, кто-либо за это же время десяток - другой коммитов нафигачил.
Да уж, тяжело вам без джиры приходится.
Оценка эффективности разработчиков по коммитам действительно довольно спорный подход. Автор в общем-то это подчеркнул неоднократно в самой статье. Поэтому комментарии про "KPI для разработчиков" не в тему. Любой инструмент (и даже технологию) можно использовать правильно и неправильно, продуктивно и не очень, во благо или назло))
С подобными инструментами я начал работать несколько лет назад. Я использовал https://github.com/tomgi/git_stats (кстати при установке возникала какая-то ошибка и нужно было залезать в исходники, чтобы исправить какую-то одну строку, но это мелочи))
Моя идея была в следующем: периодически (мы делали раз в год -- перед НГ) собирать статистику и на общей встрече разбирать её. В этом я кстати не согласен с автором, что мол лучше особенно не показывать, что есть такой инструмент для анализа. Так вот на общекомандной встрече мы смотрели как мы работаем с точки зрения гита -- кто во сколько коммитит (это очень прикольно, потому что у кого-то это чётко с 08:00 до 17:00 и перерывом на обед, а у кого-то наоборот с 12:00 и до поздней ночи), какой день и час недели самые насыщенные коммитами, кто какие комментарии к комитам пишет. В общем это весёлое и приятное мероприятие для команды, не рядовое ретро с "давайте выпишем n проблем на стикеры и приклеим их к доске"))
Если говорить шире, то у такого инструмента точно есть польза, я могу отметить следующие возможности:
Выявление тенденций. Например, если один и тот же человек раньше коммитил много, а потом стал мало, значит что‑то изменилось. Если у тимлида есть время разбираться, есть регулярные встречи 1:1, то такая информация может быть полезной для выявления проблем (выгорание, наличие второго места работы и т. д.).
Повышение качества коммитов. Я имею в виду не содержимое с точки зрения кода, а стиль создания коммитов (1000 изменений в одном коммите или разбиение на логические части) и комментариев к ним. Когда собирается статистика за большой промежуток времени, становится видно как в целом команда работает с VCS. О пользе дробных коммитов и красивых комментариев некоторые могут поспорить, но я думаю, что единый стиль и информативность точно не могут вредить. А единственная причина, по которой многие разработчики пишут комментарии в духе
fix bugs,add file— это довольно низкий уровень самодисциплины, лень. Так вот, инструмент, который наглядно использует эту информацию, может добавить мотивации работать с коммитами более осознанно.Мотивация. В дополнение к предыдущему пункту. Для новичков в команде полезно видеть, что более опытные разработчики много (и/или структурированно) коммитят, работают с кодом. Может и не для всех, но для многих это стимул тоже вкладывать больше усилий в работу над проектом.
В общем желаю автору положительной кармы, а инструменту развития! Точно буду использовать в будущем.
P.S. Видимо нужно красными большими буквами в начале написать "Это не инструмент для оценки KPI разработчиков"))
Как-то раз для развлечения делал визуализатор коммитов наподобие такого. Смотрится эпично. Пользы нет.
Классный пост, не, реально классный.
Но, я правил одну багу, и потрошил весь код, сидел, отлаживал, так продолжалось полтора месяца, покуда багу я локализовал. И спустя полтора месяца, я поправил два символа, два, Карл!
И тут я бы на статистике погорел бы. При этом я реально сидел в офисе, не занимался другой деятельностью, и реально исправлял одну багу.
Самое лучшее в смысле метрик, что я видел это DORA. Четыре метрики. Сколько фич выкатываем в прод за ед времени. Как долго в среднем фича идет от идеи до прода. Как часто вылазят баги. Как быстро баги фиксятся.
Когда решаешь не ту задачу, да еще и не теми инструментами. Я бы, кстати, послушал историю того парня, которого нанимали на непонятно какие задачи. Вангую, там бы выяснилось много интересных подробностей о том, кто прав, кто виноват.
Если один человек написал парсер логов для анализа продуктивности работы, то другой завсегда сможет написать эмулятор коммитов для демонстрации бурной деятельности.
Ну по всем признакам это антипаттерн "Разработка комитетом" и антипаттерн "Аналитики-паралитики". Лечится это с помощью проведения всего анализа строжайше в письменном виде на форумном движке. С указанием причин, следствий, прогнозов. И необходима непрерывная проверка скрытыми аудиторами.
У нас похожая контора с бардаком. Более того, ещё и не все гитом пользуются, это нечто. Ну и из-за бардака собственно программист бывает занимается и совсем не программированием.
Опишу свою деятельность за месяц:
Пишу руководство пользователя и другую документацию по своей программе для минцифр (а программ в конечном итоге три)
Пишу документацию на прогу для авторства и регистрации в фонде алгоритмов и программ
Параллельно тестирую, исправляю баги, дописываю функционал одной проги
Поддержка и выдача лицензий на другую прогу
Часто начальник обращается - найди мне эту инфу, другую, третью
Так что комитов может за день и вообще не быть таким образом? работаю ли я? Ышо как.
Базовый `git shortlog -sn` не справился?
Время ожидания влития — это время, когда PR просто висит без правок. Оно считается от времени последнего коммита. Мы можем видеть тут, что часть PR висит в таком состоянии неделю. Т.к. коммитов нет — это не ревью, иначе могли бы быть правки кода. Что же это?
Мне как-то привычнее вносить мелкие правки в последний (часто единственный) коммит. До ревью всё равно никто этого не увидит. Время коммита при этом не обновляется, что создаёт отсутствие видимости работы. И да, время коммита может не соответствовать времени открытия PR, я могу девелопить в локальной ветке долго и нудно, а потом открыть PR. В общем, довольно спорная метрика получилась, но при определённых условиях наверное даже рабочая.
Рабочая во всех описанных тобой случаях и не будет иметь ни одной описанной проблемы. А причина проста - стата только по логу гита и только учитывая влитые коммиты. Это взгляд в прошлое от текущей ветки. Все события уже произошли на момент снятия лога.
Делая локальные коммиты - ты все равно фиксируешь время. Делая последний коммит перед мержом - ты снова фиксируешь время.
Стата не покажет не влитые ветки и текущие PR, все остальное будет на месте.
Что-то файл не принимает вообще. Пробовал из 3х браузеров. Ни ошибки, ничего. Только "ловлю" при перетаскивании и возвращается назад сразу после.
А как считается "время ожидания влития" по коммитам, если у нас нет тут доступа к пул/мерж реквестам? ?
git сохраняет информацию о событие слияния веток. Если ветка подписана номером задачи, то можем посчитать разницу. Например:
2021-06-08>Ivan>ivanov@mail.com>JIRA-476 feat(Excel): add typograf for text on Approving page, refactor Approve list item
2021-06-11>Mikhail>mikhail@mail.kz>Merge pull request #189 in ACRQ/acrq-frontend from feature/JIRA-476-Add-typograf-for-text-on-Approving-page to master
Смотрим на вторую строку. Она имеет маркировку "Merge pull request...", а далее написано название ветки. Из этого названия "feature/JIRA-476-Add-typog..." мы можем узнать номер задачи (JIRA-476).
Теперь смотрим прошлые строки и находим ближайшую, которая подписана номером этой задачи. В нашем случае это строка 1, т.к. её текст "JIRA-476 feat(Excel): add..."
Т.к. в логе есть дата обоих событий, мы можем посчитать разницу между ними. Но, т.к. это "время ожидания влития" мы не знаем причину, по которой ветка не вливалась (т.к. не известно когда был создан PR и были ли к нему замечания). Причины могут быть такие:
PR висел и ждал апрувов. Их ставили очень медленно, но без замечаний.
PR можно влить, только если прошла сборка кода. Но скрипт сборки не работал.
О задаче просто забыли и PR никто не создал.
PR ожидал подтверждения тестировщика, но у него была большая очередь других задач.
Влитие кода отложили по бизнес причинам
и т.д.
Вся эта схема сработает только если в команде есть жесткие правила по именованию веток и коммитов.
Как я статистику git парсил