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

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

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

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

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

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

Где данные?

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

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

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

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

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

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

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

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

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

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

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

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

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

Следуй за деньгами

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

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