Комментарии 9
Спасибо за статью. Мы еще иногда делаем анализ по merge requests в gitlab. Строим графики, находим аномалии.
Спасибо за комментарий) А какую информацию снимаете с MR? Мне в голову приходит только авторство и объём изменений.
Авторство, объем, проект. Когда смотришь в разрезе недель, то иногда выскакивает, что разработчик за месяц сделал 20 MR на 3 строки каждый. Мы не платим за строки кода, но аномалии с переработками (такое бывает) и недоработками видно. Также интересно в прогрессии сравнивать.
Только что посмотрел: у нас за год 3300 MR, статистика хорошая получается
У вас везде недели и дни. А если команда пользуется сторипоинтами без временных интервалов, тогда будет работать ваш метод?
Спасибо за вопрос) Думаю, следовало выделить этот пункт в статье более явно.
Для расчётов используются данные о фактически затраченном времени (эта информация берётся из истории изменения задачи), а не о запланированном. Поэтому метрики считаются независимо от того, каким образом были оценены задачи - в стори-поинтах, человекочасах или размерах футболки.
Подскажите, а как вы получаете доступ к данным Jira? Напрямую в бд обращаетесь?
Через API, код вот тут - https://github.com/smirnoffmg/metrics/blob/main/metrics/repository/jira.py
Метрики команды разработки