Портал №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 измеримых показателей организационного здоровья и здоровья поставки. Все они важны для понимания сложных взаимодействий людей, процессов и продуктов, необходимых для непрерывного предоставления ценности конечному пользователю.

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

«Flow Metrics: управление потоковым производством на основе данных»
Учебный курс про метрики на реальных примерах

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT