Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.
Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на дейликах ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.
Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «а что так можно было?». А я понял, что нельзя так просто взять и посмотреть статистику коммитов.
Что есть на рынке
Пердолинг в консоль, что приемлемо, но хотелось бы «красивых обоев» и графиков:
Десктоп тулзы которые чутка устарели
https://apps.apple.com/us/app/gitstatx/id592679713?mt=12 (Mac)
https://gitstats.lostindetails.com/ (Windows)
Квесты по установке бесконечных зависимостей и пакетов в пакете (Python, Ruby и другие языки). Некоторые отчёты +/- норм, но утомляет ставить компиляторы и пакетные менеджеры языков, на которых ты не пишешь.
https://gitstats.sourceforge.net/ (python)
https://github.com/vifactor/repostat (python)
https://github.com/src-d/hercules (python)
https://github.com/morucci/monocle (python)
https://github.com/ejwa/gitinspector (python)
https://docs.mergestat.com/ (SQL! WHAT?!)
https://github.com/alexejsailer/git-analytics-docker (Docker)
Плагины к другим продуктам, как огрызки функционала.
Хорошие, но платные штуки.
Они всё сделают, нужен только простой советский ......... но регистрация на демо по паспорту и СМС каждый пятый четверг месяца с двух до трех. Я решил оставить данные и их менеджер обещал обязательно связаться со мной и обсудить план пошаговой интеграции на ближайшие полгода.
https://www.pluralsight.com/product/flow (
анальноогородились от IP из РФ)
Ты же не будешь писать свой велосипед?
Чувствуете, что задача кажется проще? Git уже есть. Статистику он выводит. Наверное, можно её как-то вытащить в отчёт без лишних телодвижений.
Я направил поток вывода git log в файл. Таким образом за одну консольную команду можно сформировать файл с данными. Ну а дальше уже распарсим строки в html и нарисуем графики. Никаких дополнительных пакетов и приседаний не нужно. Все очень просто.
А нужен ли нам html? Да на самом деле тоже нет. Его можно положить на любой хостинг, а данные своей репы добавлять просто перетаскиванием сразу в окно браузера. Получается, чтобы посмотреть красивый отчет по своей репе, мы в принципе можем вообще ничего себе не ставить.
Так я, собственно, и сделал.
Начало разработки
Дело было вечером, делать было нечего. Очень хотелось немного порисовать графики, и я откопал git-отчет. Решил построить графики на этой стате. Графики в целом получились.
Потом я решил вывести ещё немного доп. инфы, заплатить дизайнеру (чтобы было красиво), залить на github и поставив себе галочку «сделал вклад в open source».
Где в середине этого процесса, случайно была прочитана книга «Графики, которые убеждают всех» (Александр Богачев) и наступило осознание что ВСЕ ВООБЩЕ НЕ ТАК. Отчёт выводит графики, а людям интересны выводы.
Например: Петя коммитит чаще Оли, а Олег никогда не коммитит до обеда. В итоге наступил редизайн, и я залип ещё на пару месяцев.
Потом оказалось, что графиков очень много, а ещё нужны фильтры и в целом удобнее не отчетом, а в виде приложения с кнопочками и вкладками. Ну а раз выходит приложение, то и писать надо по-другому:
скопировать все фичи аналогов;
дать больше денег дизайнеру;
пригласить фокус группу;
добавить всякие смешные ачивки, чтобы заинтриговать пользователей;
А, ну и самое главное — выкинуть весь код, и начать писать с нуля. Весело же!
Дефективный менеджер
Вся эта гонка за КПД приводит только к выгоранию в попытках соответствовать синтетическим метрикам. Помню раньше вовлеченность в проект еще любили мерить путем анализа активности в чатах, тасках и на почте... @beduin01
Перед тем как продолжить, нужно написать о важной проблеме: «Как не сделать инструмент дефективного менеджера?»
Все рассуждения об анализе git статистики в итоге могут скатиться к «метрикам эффективности». И вместо абстрактных и трудных шагов по управлению проектом, дефективный менеджер может просто считать «активность в чатах и движение мышки». Ответить на этот вопрос я не смог.
Повлияет ли это на конторы, где бардак? Наверное, нет. Вспомните, у меня же коллега буквально каждый день на статусах отчитывался о работе 4 месяца подряд ничего не делая. В следующий раз ещё авто-коммит пару раз в день по скрипту поставит и год точно просидит.
Повлияет ли это на нормальные конторы? Наверное, то же нет. Планы, ревью, 1-1, обзоры 360 и т.д. и так подсветят все проблемы.
Будет ли от этого хоть какая-то польза? Тоже не ясно. Но я попробую, а там видно будет.
Анализ статистики
А теперь давайте вслед за Сашей Кирилловым угорим по логике и паттернам поведения. Весь текст ниже про фулл-тайм разработку в стабильной команде на зарплате.
Сколько стоит разработка проекта?
если человек коммитит, то он, наверное, работает;
если работает, то скорее всего за зарплату;
среднюю зарплату в IT мы видим прямо в баннерах на хабре;
Выводы:
если мы знаем среднюю зарплату, количество человек и временной промежуток работы, то можем прикинуть минимальную стоимость проекта;
если коммиты подписаны номерами задач, то можно прикинуть среднюю стоимость задачи;
если в коммите упоминается фича, то можно примерно оценить стоимость фичей;
Да, тут появляется много «если». Но вот такой приблизительный расчет эту уже хоть какие-то цифры, от которых можно начинать считать. Давайте потренируемся на котиках open-source либах:
средняя зарплата судя по рекламе хабра 180 тыс. ₽ в месяц за синьора. Есть больше, есть меньше, можно считать с налогами, а можно с северными коэффициентами. Бывают недооцененные синьоры из Новосибирска, а бывают переоцененные мидлы из Москвы. Но для примеры мы остановимся тут.
22 рабочих дня в месяц в среднем (работа с пн. по пт., допустим с 09:00 до 18:00)
8200₽ в день на программиста
Человеко-день — день в который программист сделал хоть один коммит. Если два программиста делают по коммиту, то считаем как два человеко-дня, ведь они работали параллельно. Иногда они могут изменить всего одну строку, а бывают переписывают 50 файлов.
Продукт |
Человеко-дни |
Примерная оценка |
JQuery |
2808 дня |
23 млн. ₽ |
Telegram Desktop |
3103 дня |
25.5 млн. ₽ |
React |
4943 дня |
40.5 млн. ₽ |
И это только разработка! А ведь ещё есть куча накладных расходов (налоги, отпуска, покупка оборудования, аренда офиса, зп тестировщика, дизайнера, аналитики и т.п.) и банальное завышение цены конечному заказчику. И это если у нас было супер идеальное ТЗ и мы «не клали код в стол»
Я «отжимался» на рабочих проектах, где народ работает пятидневку, работа стабильная, выходные и больничные оплачиваются в полном объеме, а переработки с коэффициентом х2. Как видите, это довольно сильно отличается от типичного open-source с github, где народ коммитит по вечерам раз в месяц. Поэтому строить какой-то прогноз или аналитику по open-source, мы можем только очеееееень широкими мазками.
Вообще зная среднюю зарплату можно делать множество логических предположений. Появляются уже интересные выводы для бизнеса:
сколько проект может съедать оборотных средств в месяц;
сколько суммарно стоила разработка за все время;
сколько человеко-дней потратили;
какая была текучка кадров;
как часто работали на выходных, и какая переплата вышла;
и т.д.
Но мы как бизнес итак их видим, зачем нам в git смотреть? Как бизнес — да, видим, но как работник можем не замечать. Кроме того, это может быть и не наш бизнес, а просто чужая репа, слитый код конкурентов, внутренний аудит и т.п.
А если я заказчик?
Ну вот я заказчик. Нанимаю какую-нибудь галеру пилить проект моей мечты. Мне продают 4х синьоров на полный рабочий день. А что может показать мне git? А может он показать, что на деле коммитит толпа фрилансеров. Видно, что рабочий день не день, а вечер. Да и вечер не каждый вечер, а вечер-через-вечер. Залетные аккаунты с чужими тасками, мержи сразу пачки задач из патчей и прочие отклонения «от нормы».
Понятно, что опытная галера будет заставлять сидеть двух человек с одного аккаунта, но шанс поймать их есть.
Есть ли польза для программиста?
Git ведь хранит всю стату. Значит мы можем смотреть по времени «не только лишь в завтрашний день», но и отматывать время назад. Вот был человек, коммитил регулярно, а потом перестал. Куда он делся? Наверное, уволился.
Такой вот перемоткой, придя в новую контору, можно быстро вскрыть несколько историй:
говорят «переработок нет», а сами стабильно работали на выходных;
говорят «проект развивается», а по статистике видно, как половина команды уволилась. Ну если и развивается, то возможно куда-то не туда.
говорят «менеджмент адекватный», а PR-ы в среднем висят по два месяца. Ну, наверное, адекватный не в управлении разработкой.
Среднестатистическому программисту, наверное, стоит запустить этот отчет два раза:
когда только приходишь на проект, чтобы быстро понять какой в целом был roadmap, кто ящер-тащер, где и у кого по модулям зоны компетенций;
когда поработал пару месяцев, чтобы прикинуть вписался ты в команду или твои показатели сильно отличаются от окружения;
Давайте, для примера, посмотрим на один из проектов
Вопрос, к знатокам: «Проект развивается или находится в стадии стагнации? Будет на такой работе больше новых фич и развития, или костылей в легаси?»
Среднестатистическому тимлиду
Среднестатистическому тимлиду отчёт помогает «сравнить свои ощущения от проекта и команды с фактическим состоянием дел» (с) Главное тут не свалиться в безумные KPI высосанные из пальца, а скорее искать отклонения от типичной картины.
Давайте найдем такое отклонение. Как вы думаете, кто недогружен в этой команде?
Видите, как один программист сильно выбивается из общей картины? Давайте сделаем разбивку по дням:
А теперь сравним с другим сотрудником за ту же неделю
Странно, да? Могут быть разные причины для такой картины, но если это ваш отдел, думаю вы будете в курсе о всех этих причинах и точно поймете нормально это или тревожный звонок. Но картина со стороны вызывает очень много вопросов к распределению задач и работе.
Увидев такую стату, вы можете сделать для себя другой вывод. Вывод о том что контора «потогонка». Задачи тут штампуют на сумасшедшем конвейере, где нет места личной жизни и перерыву на обед. Возможно, стоит бежать ещё на испытательном сроке.
Главное правило
Анализируя статистику никому не рассказывай, что анализируешь статистику. Тут появляется эффект наблюдателя. Если люди знают, что статистику проверят, то и вести себя будут по другому. Например я:
заполнял ежемесячный отчёт о проделанной работе и планах;
списывал каждый день потраченное время с разбивкой по задачам;
писал планы работ на две недели или на три месяца (на себя и на других);
отчитывался на совещаниях;
следил за статистикой в git;
Сделало это мою работу более эффективной? Не знаю. Но 100% научило всегда показывать полную занятость, наличие планов, высокий KPI и скорость. Даже если я смотрел весь день котиков на ютубе.
Мне нужна «помощь зала»
Как уже писал выше, одна и та же статистика может быть следствием абсолютно разных вещей. Чтобы отчёт мог выдать какую-либо рекомендацию, нужно хорошо понимать глубинные причины показателей. Давайте посмотрим на график мержа PR:
Время ожидания влития — это время, когда PR просто висит без правок. Оно считается от времени последнего коммита. Мы можем видеть тут, что часть PR висит в таком состоянии неделю. Т.к. коммитов нет — это не ревью, иначе могли бы быть правки кода. Что же это?
Конкретно в данном случае у нас проблема с тестированием. Оно очееень сильно отстает от разработки, а без тестирования мы не имеем права вливать ветки. Можем ли мы сделать это общим выводом для всех отчётов? Нет, т.к. у других команд это может быть «отмашка менеджера» или «ревью без правок кода».
Поэтому мне интересны ваши случаи, когда есть проблема и вы можете, косвенно, увидеть её на каком-либо графике. Собрав такие пары можно будет вносить в общий анализ новый паттерн «поиска проблемы и рекомендации». Но на одном проекте этого тупо не сделать, т.к. не собрать все ошибки управления (а может даже и не осознать, что проблема есть).
Что получилось
И так прошел год, потом второй. Переписывая отчёт третий раз я выдохся. Он получился вроде лучше аналогов, но наступил момент поддержки:
правка и перевод текстов;
подсчёт коэффициентов;
добавление мелких фичей;
покрытие тестами;
написание мануалов и т.п.
Это уже не весело, это уже «разница между написанием программы, превращением ее в продукт» (с) @apevzner
Глобально дальше вижу четыре пути развития функционала:
добавление свистелок-перделок, достижений и викторин;
анализ паттернов поведения и советы тимлидам;
локализация и интернетизация;
продолжу играть в CS по ночам, а проект дропну;
Если у вас есть ещё какие-либо идеи или замечания — отпишитесь пожалуйста, постараюсь добавить. Если нет — можете посмотреть какие ачивки вы выбили по стате текущего места работы.
Почему домен Японский? Почему не работают языки? Почему картинки не все? Почему вёрстка поехала?
Потому что это не 100% готовый результат, а некий промежуточный итог, который я время от времени продолжаю дописывать по вечерам, когда есть настроение.
Комментарии (41)
DMGarikk
04.10.2023 07:36+60О, вы за КПИ для программистов в измеряемых величинах?
Мерить эффективность сотрудников в коммитах это прям победа, поиск "коммитят фрилансеры вместо него" — путь к "нам нельзя врать, вы должны каждую секунду лично работать, что работать неважно, важно что обязаны быть заняты" (с)
Я это к чему, помню недавно была пара месяцев когда ковырялся в нутрях огромного монолита… и по итогам четырех двухнедельных спринтов сгенерил 3 (три!!) коммита, причем два из них из 2-3х строчек, при этом я копался в коде весь рабочий день с утра до вечера 5 дней в неделю.
Видимо с вашей точки зрения я просто кошмарный программист и по статистике гита меня надо уволитьможно сказать что это проект плохой и документации нет, но мне то какое дело? у меня есть задача я её сделал, монолит писал не я, его корни растут из начала нулевых годов
Roman_S
04.10.2023 07:36-6большие и даже исследовательские, а не кодерские, задачи можно декомпозировать и оценить в стори-поинтах, по которым потом отчитываться, хоть каждую неделю.
DMGarikk
04.10.2023 07:36+23да, но в гите коммитов то нет, только "а на дейликах ссал в уши ездил по ушам."
bakhirev Автор
04.10.2023 07:36-3В данном случае чувак может сказать "исследую", а не "код написал, отправил на тест". Тот который "ссал в уши" он именно говорил что код готов, а вопросы возникли в момент интеграции, когда оказалось, что кода не было.
DMGarikk
04.10.2023 07:36+4Тот который "ссал в уши" он именно говорил что код готов
код готов — это есть MR(PR) тоесть есть коммит, если MR-а нет то это тупо болтология
Я своих ребят всегда прошу пушить рабочие ветки и делать WIP MR-ы чтобы следить за прогрессом и перехватывать моменты когда они не туда уходить начинают
baldr
04.10.2023 07:36+9он именно говорил что код готов, а вопросы возникли в момент интеграции,
Все вопросы - к менеджерам, правда же? Если новый человек на испытательном сроке, то надо контролировать минимум раз в день. Если проработал месяца три и понятно что он умеет - все равно раз в неделю какой-то результат должен быть, хотя бы в своей ветке. Если у него задача на 2 месяца одиночной разработки - ну вы же понимаете что это тоже просчет менеджера в постановке такой задачи.
bakhirev Автор
04.10.2023 07:36+3Нет.
Про КПИ уже выше писал, что это бред. Даже заголовок сделал "дефективный менеджер"
Про пару коммитов в монолите — тут на длинных отрезках нужно смотреть. Думаю если взять отрезок пол-года..год то там будет некое "среднее", которое не будет меняться и будет больше 3 комитов в спринт. Во вторых, как и писал выше, в разных конторах разные ситуации. Возможно для данной конторы и проекта это норма. Как и написал выше "невозможно сделать вывод не зная проекта"DMGarikk
04.10.2023 07:36+2Про пару коммитов в монолите — тут на длинных отрезках нужно смотреть.
правильно, а в вашем примере
Спустя четыре месяца (испытательный закончился) у многих закрались подозрения
подозрения должны быть не в измерениях количества коммитов, а в сути закрываемых задач
я из своей команды увольнял миддла, потому что он коммитил знатно, но такой бред что уши в трубочку заворачивались… причем успел задолбать всю команду тупыми вопросами… когда через пару месяцев я прикинул что грубо говоря из 10 его тасок, лично я за него сделал 8… мы с ним расстались… это было и без построения графиков и расследований ясно что человек не может работать
bakhirev Автор
04.10.2023 07:36Тут не спорю и согласен. Это было вступление о том как менеджеры у нас вообще в паралельном мире. Я сам не его лид, а первый раз взаимодействовал с ним уже в районе интеграции.
Отчет в этом случае так же не особо имел бы пользу, т.к. проблема в адовой бюрократииbaldr
04.10.2023 07:36+5Ну то есть вам понятно что менеджеры косые, однако вы пишете инструмент для учета KPI программистов?
bakhirev Автор
04.10.2023 07:36Я пишу инструмент для визуализации вывода git log. Проблема менеджеров им не решается. Странные KPI - это следствие работы косых менеджеров, а не инструмента визуализации.
Например, отчёт выводит "самые популярные слова" или ачивку за самое длинное / короткое имя на проекте, или можно посмотреть кто больше коммитит до обеда, а кто после.
iig
04.10.2023 07:36+2отчёт выводит "самые популярные слова" или ачивку за самое длинное / короткое имя на проекте, или можно посмотреть кто больше коммитит до обеда, а кто после
Но зачем, Холмс??
boldMahoney
04.10.2023 07:36+1Поддерживаю. Сергей Немчинский тоже подобную историю на стримах рассказывал, когда работал на галере и ему надо было исправить хитрый баг в индусском коде. Он искал одну строчку (или даже один символ) почти месяц. Нашел и исправил.
0x131315
04.10.2023 07:36Все так, работу программиста бесполезно измерять - кроме шума ничего не намеряется. Кто-то берет самые простенькие задачки для новичков и строчит их как из пулемета, это явно ценный специалист, а другой берет самые тяжелые и критичные для бизнеса проблемы, вкладывает много сил в исследования и расследования, докапывается до фундаментальных причин, поэтому у него всего пару коммитов в неделю - явно это самый бесполезный человек. И так в любой статистике, потому что работа во многом творческая, для нее даже метрик адекватных не изобрели. А когда на человека какая-либо статистика повесит маркеры - все, конторе кирдык, эффективный менеджер проник в управление, начинается отрицательный отбор: по маркерам удобно увольнять самых "неэффективных", согласно именно такой вот смешной статистике.
Tomahawk_nsk
04.10.2023 07:36В Embedded ещё хуже, чтобы пару строчек написать нужно разобраться в железе и SDK как правило без документации ) И потом компилировать ядро Linux, которое не очень быстро собирается.
dlinyj
04.10.2023 07:36И потом компилировать ядро Linux, которое не очень быстро собирается.
На современном железе, в кучу потоков несколько минут.
ivankudryavtsev
04.10.2023 07:36+17Вот у меня есть два инженера (на самом деле больше, но рассмотрим два):
один фигачит, много коммитов, много тасков;
второй мало фигачит, но постоянно находит какие-то грабли, много времени на этих граблях сидит, пытается понять что не так и как так не так.
В целом, я доволен обоими, конечно, мой внутренний невротик бесится, но польза, очевидно, разная и по разному оказывает влияние на проект. Метрики по Commit, PR, циклах review - это отлично, но без компетентного человека, который понимает суть происходящего могут только навредить. В целом, проект автора полезный, но всегда есть желание механистически что-то применять и получить красиво - так не бывает.
vvbob
04.10.2023 07:36+4Да, оценка трудозатрат по гиту это такое.. Один сделает пять коммитов, в которых выложит мегафичу, решающую огромную бизнесзадачу, другой зафигачит за то же время триста коммитов плана - "фикс моего факапа из предыдущего коммита".
Опять же как учитывать ситуации, вроде вот недавнего случая из моей практики - полторы недели искал причину кривой работы одного отчета, перерыл код, запросы, все вроде должно работать правильно, но не работает. В итоге проблему нашел - исправил ровно одну букву (не шучу, одну, мать ее, букву в коде) и баг был исправлен. По KPI количество коммитов - я все эти полторы недели просто нихрена не делал, получается, кто-либо за это же время десяток - другой коммитов нафигачил.
LEON4ik
04.10.2023 07:36+3Оценка эффективности разработчиков по коммитам действительно довольно спорный подход. Автор в общем-то это подчеркнул неоднократно в самой статье. Поэтому комментарии про "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 разработчиков"))
dlinyj
04.10.2023 07:36+6Классный пост, не, реально классный.
Но, я правил одну багу, и потрошил весь код, сидел, отлаживал, так продолжалось полтора месяца, покуда багу я локализовал. И спустя полтора месяца, я поправил два символа, два, Карл!
И тут я бы на статистике погорел бы. При этом я реально сидел в офисе, не занимался другой деятельностью, и реально исправлял одну багу.
NNikolay
04.10.2023 07:36+2Самое лучшее в смысле метрик, что я видел это DORA. Четыре метрики. Сколько фич выкатываем в прод за ед времени. Как долго в среднем фича идет от идеи до прода. Как часто вылазят баги. Как быстро баги фиксятся.
TimurTukaev
04.10.2023 07:36+2Когда решаешь не ту задачу, да еще и не теми инструментами. Я бы, кстати, послушал историю того парня, которого нанимали на непонятно какие задачи. Вангую, там бы выяснилось много интересных подробностей о том, кто прав, кто виноват.
shasoftX
04.10.2023 07:36+3Если один человек написал парсер логов для анализа продуктивности работы, то другой завсегда сможет написать эмулятор коммитов для демонстрации бурной деятельности.
Algrinn
04.10.2023 07:36+1Ну по всем признакам это антипаттерн "Разработка комитетом" и антипаттерн "Аналитики-паралитики". Лечится это с помощью проведения всего анализа строжайше в письменном виде на форумном движке. С указанием причин, следствий, прогнозов. И необходима непрерывная проверка скрытыми аудиторами.
NikRik
04.10.2023 07:36У нас похожая контора с бардаком. Более того, ещё и не все гитом пользуются, это нечто. Ну и из-за бардака собственно программист бывает занимается и совсем не программированием.
Опишу свою деятельность за месяц:
Пишу руководство пользователя и другую документацию по своей программе для минцифр (а программ в конечном итоге три)
Пишу документацию на прогу для авторства и регистрации в фонде алгоритмов и программ
Параллельно тестирую, исправляю баги, дописываю функционал одной проги
Поддержка и выдача лицензий на другую прогу
-
Часто начальник обращается - найди мне эту инфу, другую, третью
Так что комитов может за день и вообще не быть таким образом???? работаю ли я? Ышо как.
SUNsung
Статистика по коммитам такое себе
Если в компании построен процесс на пул-реквестах то отталкиватся надо от этого, потому как вася таску закрывает за один коммит, а петя за пять. Продуктивность у обоих одинаковая, но при этом в статистике петя будет лидировать.
bakhirev Автор
Не понятно по какому показателю. Ведь и тот и тот сделал по одной задаче за одной и то же время.
В глобальном плане Вася получит негативную ачивку, т.к. редко сохраняется и если уронит ноутбук то потеряет весь код за день или неделю
baldr
Нет, Вася сделал одну задачу, но чётко по требованиям, а Петя, кроме этого, еще и закрыл 5 багов (фиксил свои же баги по замечаниям).
Что касается коммитов - и правда, очень спорная метрика. Был у нас в команде один товарищ, с ролью билд-мастера. Как сделает новый бранч, поправит номер версии, соберет билд и закоммитит артефакты (все через скрипты) - сразу в истории ВЗРЫВ на 200+ файлов и десяток коммитов. Раз пять в день. Это было лет 10 назад, не помню чем считали это, но тем не менее.
Считать по LOC и тп - тоже не очень вариант. Сейчас автогенерируемый код (миграции, патчи, CMakeLists, etc) довольно часто встречается.
janson
Если билд-мастер работает через скрипты, то скорее всего используется отдельный чистый клон репозитория для этой активности. Можно в конфиге прописать коммитера как "Build Master" чтобы в коммитах это имя светилось и у него будет отдельная статистика.
Другой вопрос что скорее всего в связи с этой ролью у основного аккаунта коммитов будет негусто.
domix32
А оно считает с основного бранча только статистику или вообще по всем веткам сразу? Можно ли в последнем случае ставить ветки в игнор? Форс пуши как-то афектят сбор статистики или оно парсит только git log, но не reflog?
bakhirev Автор
Оно считает с той ветки, где стоишь. Парсит только git log, т.к. сам отчет это просто HTML а входные данные для него формирует этот самый git log. Не влитые ветки учтены не будут.
Поэтому ежедневный мониторинг KPI не про этот отчёт. Нужна какая-то стабильная ветка с множеством влитий и большой период времени (например, ветка релиза, или мастер) на которой можно смотреть глобальную стату прошлого.
novoselov
В Bitbucket есть специальные плагины для этого, вот например
https://marketplace.atlassian.com/apps/1210934/awesome-graphs-for-bitbucket
Подсчет коммитов это бред, разные люди - разные паттерны. Кто-то коммитит каждый раз перед уходом с работы делая бекап кода (не надо так), вместо того чтобы коммитить рабочий код или разделять функциональные изменения для возможности независимого отката. Кому-то хочется красивой и чистой истории, и в команде принято делать squash чтобы схлопнуть все коммиты в один, перед тем как создать pull request.
Можно считать LOC (без комментов и пустых строк), можно считать hit line (только по актуальным строкам кода), можно считать удаленные и добавленные строки. Можно вычислять владельцев кода по процентному соотношению в модуле/репозитории, можно смотреть кто больше всех делает review и оставляет комментарии. Можно делать частный change rate, можно общий, можно по дням недели, можно по времени.
Но как только это перерастает в попытку оценить реальную производительность или вовлеченность, значит пора сваливать с такого проекта.
boldMahoney
Если принята практика после аппрува MR все коммиты его составляющие сжимать в один и только потом мержить, то статистика в таком случае будет одинаковая.
farrow
Этот KPI тоже обходится легко. Опытные ребята с порога просят разбить даже маленькую задачу на пачку микрозадач. В результате будет и много закрытых задач, и много пулл-реквестов, и много коммитов. По графикам — незаменимый человек.