Прощай, ДОРА: недостатки отчетов о состоянии DevOps

Прощай, ДОРА: недостатки отчетов о состоянии DevOps

4 января 2024 г.

Два года назад я изучал влияние выгорания разработчиков на разработчиков программного обеспечения и обнаружил 83 % пострадали от выгорания. В последние месяцы я работал над дальнейшим исследованием восприятия разработки программного обеспечения в различных организациях, в том числе обнаружил, что 75% инженеров-программистов сталкивались с преследованием в последний раз, когда сообщали о правонарушениях, и что 89% бизнес-лидеров были обеспокоены своевременной доставкой программного обеспечения .

Команда Google DORA в течение нескольких лет проводила собственный опрос инженеров-программистов, а первоначальные авторы системы измерения теперь создали другие платформы, включая SPACE и DevEx. Хотя изначально я доверял исследованиям, проведенным этими командами, по мере дальнейшего исследования недостатки стали очевидны.

Во время каникул я читал книгу доктора Эндрю Дженкинсона «Почему мы едим (слишком много): новая наука об аппетите», в которой доктор Дженкинсон критикует исследование, известное как «Исследование семи стран», проведенное доктором Анселем Кизом. Доктор Дженкинсон описывает успех доктора Киза следующим образом: «Он выиграл спор у своего крупнейшего соперника, разгромив его неоспоримыми фактами и разоблачив его ошибочную логику. Лесть толпы наполнила его радостью и экстазом. Дело его жизни достигло своих целей. Финансирование его исследований будет поступать, а его репутация как ведущего ученого в своей области будет обеспечена на долгие годы. Слава — это хорошо, но теперь он получил два главных приза — власть и влияние».

Однако доктор Дженкинсон отмечает: «Он не был нечестен в своих исследованиях – это было бы неэтично и дискредитировало бы его. Технически то, что он представил, было правдой. Но он прекрасно знал, что это не вся правда».

По мере того, как я изучал результаты исследований DORA, а затем работал более детально, параллели между этим описанием и строгостью исследований в отчете DORA о состоянии DevOps и последующей структуре SPACE и DevEx стали очевидны.

The Accelerate book, produced by the research from Google's DORA team.

Где данные?

Во-первых, исследование DORA проводится путем выборки многих тысяч разработчиков посредством использования субъективных опросов. Это исследование проводится командой DORA. Обычно те, кто зарабатывает на жизнь проведением подобных исследований, присоединяются к таким организациям, как Общество рыночных исследований (MRS) и Британский совет по опросам (BPC), чтобы гарантировать, что общественность может доверять исследованиям, проводимым организациями, которые являются его членами. Например; Правила BPC устанавливают строгие правила раскрытия информации для своих членов, требуя, чтобы они раскрывали полные таблицы данных с вопросами, заданными в течение двух рабочих дней с момента публикации исследования.

Здесь заключается наша первая проблема; команда DORA не публикует необработанные данные, а только публикует отчет о состоянии DevOps.

Неверная методология

Исследование Google DORA, а также платформы SPACE и DevEx, используемые в группах, используют субъективные опросы для создания показателей. При использовании субъективных опросов важно принять меры, чтобы избежать предвзятости.

Тем не менее, DORA использует четыре ключевых показателя для измерения результатов: время выполнения изменения, частота развертывания, частота неудач изменений и время восстановления (ранее — среднее время восстановления). По сути, это показатели скорости развертывания новых функций и скорости решения проблем.

Представьте, что вы спросили некоторых людей: «Ваши коллеги едят много зелени?» и «Много ли тренируются ваши коллеги?». Те, кто чувствует себя лучше на своем рабочем месте, вероятно, с большей вероятностью ответят «да» на оба вопроса — это не означает, что употребление большего количества зелени всегда приведет к более высокому уровню посещаемости спортзала. Хотя корреляция может быть, мы не установили причинно-следственную связь.

Исследование DORA утверждает, что скорость и надежность идут рука об руку, однако они основаны на показателях результатов, которые полностью основаны на скорости. Более того, использование субъективных опросов может привести к тому, что получатели, которые лучше относятся к своей работе, ответят «да» на оба вопроса. И хотя более компетентные компании неизбежно могут быть более компетентными по обоим факторам, причинно-следственной связи это не создает.

Например; подумайте, насколько высоко ценится надежность авиационного программного обеспечения по сравнению с нечастым внедрением программного обеспечения на самолетах. Или вспомните, как компания Toyota, пионер гибких методологий, в деле о надежности программного обеспечения «Bookout v. Toyota» по поводу непреднамеренной ошибки ускорения, которая привела к смертельным случаям, признала во внутренней коммуникации, что «на самом деле такие технологии, как отказоустойчивость, не являются частью стратегии Toyota». ДНК инженерного подразделения». Или вспомните, как во время скандала с Horizon IT, обвиненного в многочисленных самоубийствах и в том, что было описано как «самая распространенная судебная ошибка в истории Великобритании», в результате которого несправедливо были заключены в тюрьму, включая беременную женщину, разработчик программного обеспечения Fujitsu впервые применил гибкая методология разработки программного обеспечения, а именно Быстрая разработка приложений.

Causation is not correlation - Sketchplanations

Неверные результаты измерений

Как уже говорилось, исследование DORA измерялось четырьмя ключевыми показателями, которые оценивают скорость развертывания новой работы и исправления ошибок для оценки производительности. Однако эти показатели имеют значение только в том случае, если их можно измерить.

Я провел исследование как инженеров-программистов, так и репрезентативную выборку широкой публики (с исследовательской фирмой Survation) и обнаружил, что оба согласны, что скорость является наименее важным фактором. Вместо этого общественность больше всего заботит безопасность данных, точность данных и предотвращение серьезных ошибок. Трудно найти гипотезу, которая бы связала четыре ключевых показателя с этими результатами, которые разработчики программного обеспечения и общественность считают наиболее важными, особенно с учетом того, что предотвращение серьезных ошибок явно имеет более низкий приоритет, чем быстрое исправление ошибок или быстрое выполнение работы. Даже если говорить о других факторах, например о безопасности данных, трудно понять, как они связаны с каким-либо из четырех ключевых показателей.

Даже среди лиц, принимающих бизнес-решения, кажется, что своевременная доставка важнее быстрой доставки. Согласно исследованию, которое я провел совместно с J.L. Partners, 98% лиц, принимающих бизнес-решения в Великобритании и 96% в США, согласны с утверждением «Цель команды разработчиков программного обеспечения — поставлять высококачественное программное обеспечение вовремя». С этим полностью согласны 65 % в Великобритании и 62 % в США.

Окончательно; Исследование, которое я провел вместе с Survation, показало, что доверие к разработчикам программного обеспечения и ожидания общественности в отношении надежности могут значительно различаться от отрасли к отрасли, а это означает, что следует отказаться от универсального подхода в пользу того, что предлагает Инженерный совет Великобритании в своих Руководство по рискам: «принять подход к принятию решений, пропорциональный риска и соответствует установленному в организации аппетиту к риску».

Следить за деньгами

Подобно тому, как доктор Киз получил финансирование от сахарной промышленности в своих исследованиях, во многих исследованиях важно следить за деньгами, чтобы понять, в чем заключаются стимулы. Команда DORA изначально начала составлять отчеты о состоянии DevOps для Puppet, компании, специализирующейся на автоматизации ИТ-инфраструктуры, а теперь они выполняют эту работу для Google Cloud. Оба заинтересованы в том, чтобы разработчики могли развернуть работу как можно быстрее. Однако это не означает, что это решение всех наших проблем.

DORA внесла вклад в мир разработки программного обеспечения, добавив в этот процесс определенную эмпирическую оценку. Однако мы должны избегать путаницы с маркетинговыми материалами и признавать недостатки таких исследований.


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE