Наблюдаемость качества разработки: от субъективных суждений к объективным данным

[serjeant]

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

[trueman_d]

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

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

[serjeant]

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

[missing_id]

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

[trueman_d]

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

[azZy28]

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