Портал №1 по управлению цифровыми
и информационными технологиями

Как DevOps-командам следует использовать метрики DORA

С момента выхода в 2018 году книги “Accelerate: Наука о бережливом программном обеспечении и DevOps”, показатели DORA, которые она представила, стали популярным способом измерения качества разработки программного обеспечения.

Но не всегда их используют правильно, что приводит к плохим результатам. Ниже мы рассмотрим, почему это происходит, и что вы можете с этим сделать.

Показатели DORA могут быть обоюдоострым мечом

DORA расшифровывается как DevOps Research and Assessment. Это компания, работающая в области информационных технологий и услуг, основанная Джином Кимом (Gene Kim) и Николь Форсгрен (Nicole Forsgren). В Accelerate Николь, Джин и Джез Хамбл (Jez Humble) собрали и обобщили результаты, которых позволяет достигать переход к непрерывному созданию ценности. Они также обсудили модели поведения и культуру, которые используют успешные организации, и дали рекомендации о том, что измерять и почему. Включены четыре ключевых результата, в достижении которых преуспевают высокопроизводительные организации:

  • Частота развертывания (Deploy frequency)
  • Время выполнения (Lead time)
  • Процент неудачных изменений (Change fail percentage)
  • Среднее время восстановления (Mean time to repair)

В последующие годы, по мере того как всё больше организаций стало работать над модернизацией своих подходов к доставке программного обеспечения, показатели DORA стали индикатором успешности этих усилий. Однако это обоюдоострый меч. Показатели кажутся очень простыми, поэтому отношение таково: “Давайте измерим это, построим отчёты, и мы будем знать всё”. Но применительно ко всему, что связано с людьми, показатели DORA сложны и требуют постоянной бдительности и корректировки для предотвращения неблагоприятных побочных эффектов. Параллельно распространению этих показателей мы также наблюдаем распространение анти-паттернов.

Когда назначение приведённых показателей понято неправильно, могут возникнуть серьёзные проблемы. Мы всё чаще видим, что показатели DORA используются в качестве целей в комплекте с OKR (цели и ключевые результаты), причём цель формулируется, как “улучшение показателей DORA”. Но улучшение показателей никогда не должно быть вашей целью! Как гласит закон Гудхарта, “Когда метрика становится целью, она перестает быть хорошей метрикой”. Высокоэффективные организации стали таковыми не потому, что они сосредоточились на метрических целях. Они стали высокоэффективными, сосредоточившись на клиенте и на том, как более эффективно, результативно и устойчиво создавать ценность. Показатели – это результат (outcome).

С этим связана идея использования показателей DORA для сравнения производительности доставки между командами. У каждой команды есть свой собственный контекст. Продукт отличается различными средами доставки и различными проблемными областями. Вы можете отслеживать улучшения команд и демонстрировать им динамику их улучшений по сравнению друг с другом, но если вы будете ранжировать команды по данным показателям, это окажет негативное влияние на создание ценности для заказчиков. Если использовать эти показатели для управления производительностью, а не для отслеживания работоспособности всей системы доставки, они подталкивают нас к тому, чтобы стать “фабриками функций”.

Другой распространенной проблемой является распространение панелей мониторинга показателей, которые отображают цифры, но не дают очевидного представления о том, какие действия следует предпринять. “Мы развернулись 436 раз!” Хорошо, но насколько велика организация? Было ли это 436 раз за неделю, день или год? Улучшается или ухудшается это число? Какие действия мы должны предпринять в следующий раз, чтобы улучшить? Что еще более важно, как быстро мы получаем обратную связь о ценности, которую мы на самом деле предоставляем?

Вот проблема, которую вам действительно нужно решить

Разве в мире существуют только эти четыре показателя? Вовсе нет. В книге Accelerate определены четыре ключевых показателя для измерения результатов ваших экспериментов по улучшению, но эти показатели имеют смысл только при применении их в комплексе с прочими рекомендациями из книги:

“Непрерывная поставка улучшает как производительность, так и качество, а также помогает улучшить культуру, снизить выгорание и уменьшить число проблем при развёртывании”.

Итак, вам нужно решить проблему “какие улучшения вам нужны, чтобы ваше программное обеспечение всегда находилось в готовом к выпуску состоянии при постоянном его изменении?” Для этого начните с непрерывной интеграции (continuous integration). CI – это деятельность по интеграции проверенного, готового к выпуску кода в основную ветку разработки очень часто (не реже одного раза в день). Это ключевой шаг, который помогает выявить ограничения, существующие в организации. Это также самое простой вид деятельности, которой помогает начать отслеживать достижение целей улучшения. Как долго существуют ветки разработки? Как часто вносятся изменения в основную? Как быстро вы можете выявить дефекты?

Затем вам нужно улучшить поток доставки, чтобы вы могли повысить свою способность соответствовать ожиданиям заказчиков. Сколько задач у вас в работе? Как вы можете уменьшить это число, чтобы “перестать начинать” и “начать заканчивать”? Каково общее время выполнения задачи от запроса до поставки? Поток создания ценности – составьте карту процесса, чтобы найти и устранить ограничения.

Вам нужно сосредоточиться на результатах (outcomes) работы с заказчиками, иначе все ваши усилия не будут иметь значения. Довольны ли ваши пользователи? Есть ли у вас стабильный, доступный и безопасный продукт, на который они могут положиться? Используются ли новые функции или их следует удалить?

Все начинается с создания правильной культуры

Успех зависит от наличия правильной культуры и устойчивой работы. Наличие культуры доверия и постоянного совершенствования является основополагающим. Вам также необходимо найти способы измерения стресса в команде. Будут ли люди рекомендовать другим присоединиться к их команде или вашей организации? Сколько часов они тратят вне обычного рабочего времени на такие задачи, как поддержка или выпуск новых изменений? Помните, что такая работа приводит к выгоранию и текучести кадров. Какие признаки надо отслеживать, чтобы улучшить ситуацию?

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

Оригинал статьи доступен по ссылке.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM