[2/2] Как собираются отчеты DORA (DevOps Research and Assessment)?

Продолжая рассказ про методологию DORA, хотелось сказать, что в 2024 году авторы нашли пятую метрику rework rate, для которой прокси метирикой является change failure rate. Для проверки они добавили вопрос про количество незапланированных deployment, которые были нужны для фикса багов. В итоге, гипотеза подтвердилась и исследователи сгуппировали четыре предыдущих фактора и новый пятый по двум группам software delivery: throughput и stability

• Throughput: change lead time, deployment frequency, failed deployment recovery time
• Stability: change failure rate, rework rate Но дальше авторы решили сохранять свою прошлю структуру с кластеризацией и группировкой уровней по четырем категориям:)

Если говорить про методологию 2024 года, то ребята выделили 3 отдельных пути для прохождения опроса (куда рандомно определяли участников)

• AI (для определения влияния gen AI)
• Platform engineering Влияние платформенной инженерии
• Workplace (для опрпеделения влияния трансформационного лидерства

Дальше провели опрос и проверили внутреннюю и внешнюю валидность измерений:

• Внутренняя валидность показывала, что ответы на разные вопросы про один концепт дают консистентные результаты. Для этого авторы использовали confirmatory factor analysis (CFA) с применением lavaan R package.
• Внешняя валидность показывала, что конструкт, собранный исследователями, связан с реальным миром через взаимосвязи. Например, у авторов были ожидания по связи конструктов между собой и некоторой корелляции, которую можно было проверить на практике (и если находились противоречия, то они требовали новых гипотез для объяснений).

Для causal inference авторы использовали Directed acyclic graphs (DAGs) и инструмент DAGitty, который позволяет построить модель взаимосвязей разных факторов, а также попробовать устранить влияние третьих переменных и смимикрировать a/b эксперименты. А дальнейший анализ эффектов авторы делали с использованием баейсовских подходов

We use Bayesian statistics to calculate a posterior, which tries to capture “the expected frequency that different parameter values will appear.” The “simulation” part is drawing from this posterior more than 1,000 times to explore the values that are most credible for a parameter (mean, beta weight, sigma, intercept, etc.) given our data. Отдельно надо отметить, что авторы отказались от одной большой модели и сдеелали много маленьких моделей, где связывали capabilities (условно инжнерные практики) с результатами (outcomes). Дальше они при помощи ответов на вопросы проверяли связь между capabilities и outcomes, пытаясь отделить влияние третьих переменных. Проделав это, они делали не просто выводы о корелляциях, а постулировали наличие причинно-следственных связей.

В общем, методология получилась определенно интересная, а следующий выпуск подкаста Code of Leadership будет посвящен ее детальному разбору.

#AI #DevOps #DevEx #Metrics #Processes #Management