Методология DORA: что стоит за метриками

Игорь представляется внешним экспертом и консультантом: он помогает большим компаниям развивать инженерную культуру, процессы и практики, а за DORA следит с момента появления команды — это уже десять лет, десять отчётов и, по цифре из отчёта 2024 года, больше 90 000 прошедших опрос представителей индустрии. Александр напоминает прошлогодний выпуск по Accelerate: книга 2017 года подвела итог первых пяти лет опроса и показала научно обоснованную модель того, как DevOps влияет на перформанс организации, — для индустрии это был переход от того, во что мы верим, к тому, что можно померить. Тогда фокус был на результатах, теперь — на устройстве под капотом. Кор-модель DORA, по словам Игоря, упрощённая и скорее маркетинговая, нужная для привлечения внимания; её текущая версия 2.0 связывает capabilities, performance и outcomes — инженерные практики, метрики скорости и надёжности и результаты для компании, команды или отдельного инженера.

Модель развивается силами сообщества: около года назад обсуждение открыли на GitHub, и Игорь пришёл туда с предложением наложить на неё три пути из книги DevOps Handbook — практики, которые ускоряют поставку, улучшают обратную связь и развивают инженерную культуру. Категории Fast Flow и Feedback Loops появились благодаря его комментарию; отдельно разбирали и термины — что считать maintainability, а что small change: в исследовательской работе договариваться о терминологии нужно на старте. Основали DORA Джин Ким и Джез Хамбл, авторы известных книг, а исследовательскую часть принесла Николь Форсгрен — учёный по специальности, знавшая методы, которых основателям не хватало. В 2018 году, после выхода книги, Google Cloud купил DORA, и сейчас это небольшая команда внутри Google Cloud; со следующего года, по памяти Александра, DORA попрощалась с партнёром из мира управления конфигурацией и стала выпускать отчёт отдельно; Игорь добавляет, что тот продолжил собственное исследование и сейчас сместил фокус на платформенную инженерию.

Разобраться в методологии Александра заставили формулировки из сводки результатов за 2024 год: фразы вида «увеличение adoption на 25 % ведёт к…» показались ему нестандартной статистической конструкцией. Он жалуется, что методологии и способу подсчёта уделяют мало внимания, а это открывает простор для манипуляций — как в работах, где шестнадцати разработчикам раздают задачи, а выводы делают широкомасштабные. Сама методология неплохо описывает преемственность с прошлыми годами, чтобы сравнивать тренды, вопросы про capabilities и outcomes и вопросы, отсеивающие третью переменную. Но Игорь видит пропущенный шаг: исследование начинается не с вопросов, а с цели, модели и гипотез. Вопросы и варианты ответов DORA публикует на сайте, а гипотез и большой модели нет — исследование выходит полуоткрытым, повторить его не получится. С 2023 года вместо одной большой модели делают маленькие: одна capability плюс интересующие ауткамы — для генеративного ИИ, платформ, рабочих процессов.

Отдельная тема — опыт прохождения. Чем длиннее опрос, тем хуже заполняемость; формулировки должны читаться однозначно, иначе ответ зависит от того, как человек понял вопрос; а когнитивная сложность технических конструктов мешает сделать вопросы простыми. Игорь напоминает, что от опросов все устали и респонденту нужна ценность — например, открытые данные, — а во внутренних опросах не стоит спрашивать то, что подгружается из других систем: стаж, роль, команду. В вариантах ответа всегда есть «не знаю», и, по его оценке, больше половины вопросов DORA используют шкалу Лайкерта. Термины приходится готовить заранее книгами и white paper, иначе частота релизов, change lead time и MTTR разъезжаются: релиз куда, MTTR для сервиса или для пайплайна. Александр добавляет, что DORA стала законодателем моды в терминологии, а шкалу Лайкерта до неё в IT-опросах видели редко: в Accelerate объясняли, почему степень согласия с утверждением давать проще, чем число или диапазон.

Выборка должна быть репрезентативна генеральной совокупности, и Александр вспоминает случай 1936 года: крупный журнал разослал опрос примерно десяти миллионам человек и предсказал уверенную победу республиканца, а победил демократ — читателями журнала были люди с высоким достатком. Институт Гэллапа взял тогда две тысячи человек и угадал. DORA набирает респондентов органически, через сообщества, и разрешает делиться ссылкой — тут легко словить эффект снежного кома и смещение от одного мощного комьюнити, — а вторым ходом точечно пишет недопредставленным участникам. Игорь соглашается и приводит пример из другого отчёта: State of Agile проводят на конференции по SAFe, и SAFe там ожидаемо в топе; он предлагает звать людей персонально и давать блок вопросов по их зоне. Александр возражает: так и рождается смещение — это как опросить архитекторов на архитектурной конференции и решить, что в индустрии у всех есть архитектурный репозиторий и фитнес-функции. Сама DORA разбила опрос на три ветки и распределяет респондентов случайно, сохраняя наследие — связь DORA-метрик с ауткамами.

Конструкты проверяют на внутреннюю и внешнюю валидность. Внутреннюю Александр объясняет через слона и мудрецов: если кто-то приписал слону крылья орла, конструкт не собирается. Внешняя — про связи с реальностью, и в отчёте 2024 года есть места, где она не подтвердилась: приходится придумывать объяснения вроде гипотезы вакуума про meaningful tasks или разбираться, почему платформа просаживает стабильность. Пример работающего конструкта — культура по Рону Веструму: директивная, где гонца с плохими новостями убивают и информация о проблемах не расходится; бюрократическая, живущая по букве правил; генеративная, где проблемы разбирают до корневых причин и где только и работают SRE-практики. Выборка невелика — в 2024 году опрос прошли около 3 000 человек, — поэтому точность выжимают leave-one-out кросс-валидацией и информационным критерием Ватанабэ—Акаике. Главная претензия к DORA, по словам Игоря, именно про причинность: Александр, чьё подразделение в Т-Банке отвечает за платформу A/B-экспериментов, соглашается на корреляции, но настоящий эксперимент в опросе не поставить — как астроному не зажечь новую звезду.