Pull to refresh

Comments 6

Интересно как изменились:
1. Качество кода, ради улучшения метрики Cycle Time
2. Процент текучки кадров после ввода метрик

  • Cycle Time улучшилась за счет более четкого мониторинга и анализа метрик. Качество кода в некоторых командах повысилось, но в других осталось на прежнем уровне.

  • Процент текучки кадров снизился в командах, где метрики стали основой для оптимизации процессов. В остальных случаях изменений не заметно.

Хм, интересно. Спасибо за ответ. Я предполагал, что после ввода метрик будет скачек количества увольнений, с последующей стабилизацией за счет прихода новых сотрудников.

На схеме отражены Bitbucket и Jira. А отслеживаете ли вы какие-то CI/CD метрики? Например, количество провалившихся билдов, результаты тестирования на тестовом стенде/виртуальной машине, может, время сборки проекта?

В 0.1 версии подобного рода метрики собирались. Данные по ним до сих пор агрегируются и присутствуют в системе. Ключевой вопрос: какие должны быть граничные значения по этим показателям для каждой команды и что делать, если фактические значения выходят за них?

Довольно интересный опыт. Начал читать со скепсисом - обычно наблюдается закон Гудхарда: "Как только какая-либо метрика становится целью, она перестает быть полезной как метрика". И даже больше - становится инструментом манипуляции. Но вторая часть статьи внесла позитив.

Sign up to leave a comment.