Как использовать Dora Metrics, чтобы стать элитной командой
9 ноября 2022 г.Разработка программного обеспечения — это гораздо больше, чем навыки кодирования. Элитные команды разработчиков лучше не только благодаря своим техническим навыкам. Их дисциплина и способность сочетать скорость и качество также являются ключевыми факторами их успеха. Совокупный опыт тысяч разработчиков показал, что представление о том, что скорость и качество являются компромиссом, не применимо к разработке программного обеспечения — вы не можете жертвовать одним ради другого.
Стать элитной командой с Dora Metrics
Организации десятилетиями пытались измерить продуктивность разработки программного обеспечения. Слишком часто внимание концентрировалось на легко поддающихся количественной оценке показателях, таких как человеко-часы, выделенные строки кода, функциональные точки или функции, добавленные за спринт. К сожалению, ни один из них не оказался адекватным для прогнозирования производительности команды. Это настолько сложная проблема, что некоторые заявляют, что ее невозможно решить.
Несмотря на эти неудачные попытки, DORA решила установить показатели производительности разработки.
Что такое ДОРА?
DORA (DevOps Research and Assessment) – исследовательская группа, основанная в 2015 году Николь Форсгрен, Джез Хамбл и Джин Ким. Цель группы — найти способы улучшить разработку программного обеспечения. В течение семи лет они опросили тысячи специалистов по программному обеспечению в сотнях организаций различных отраслей.
Выводы команды были впервые опубликованы в Accelerate: The Science of Lean Software and DevOps (2018 г.). В книге представлены четыре контрольных показателя, которые соотносятся с высокоэффективными организациями: показатели DORA.
В том же году, когда была опубликована вышеупомянутая книга, Google приобрел группу и учредил исследовательскую программу DORA, которая отвечает за публикацию ежегодного отчета о состоянии DevOps.
Что такое показатели DORA?
Новаторское открытие, полученное в результате исследования DORA, заключалось в том, что при достаточно длительной перспективе не существует компромисса между скоростью и качеством. Другими словами, снижение качества в долгосрочной перспективе не ускорит цикл разработки.
И скорость, и стабильность важны. Сосредоточение внимания на добавлении функций в ущерб качеству приводит к некачественному коду, нестабильным выпускам и техническим долгам, что в конечном итоге тормозит прогресс.
DORA определила два ключевых аспекта разработки программного обеспечения:
* Пропускная способность измеряет время, необходимое новому коду для достижения рабочей среды. * Стабильность: измеряет частоту сбоев при развертывании и среднее время устранения неполадок.
DORA измеряет стабильность двумя показателями:
- Время восстановления обслуживания (MTTR): сколько времени требуется организации (в среднем) для восстановления после сбоя в работе.
- Коэффициент сбоев изменений (CFR): процент выпусков или развертываний, вызвавших сбой в рабочей среде.
Что касается пропускной способности, DORA добавляет еще два показателя:
- Частота развертывания (DF): как часто организация успешно выпускает продукт для пользователей или развертывает его в рабочей среде.
Время до внесения изменений (LT): количество времени, которое требуется для того, чтобы фиксация достигла рабочей или выпущенной версии
Показатели DORA измеряются с использованием следующих 4 уровней: элитный, высокий, средний и низкий.
| Метрика | Низкий | Средний | Высокий | элита | |----|----|----|----|----| | Частота развертывания | менее 1 раза в 6 месяцев | 1 в месяц до 1 в 6 месяцев | 1 в неделю до 1 в месяц | По запросу (несколько развертываний в день) | | Время выполнения изменений | более 6 месяцев | от 1 месяца до 6 месяцев | от 1 дня до 1 недели | Менее 1 часа | | Время восстановить сервис | более 6 месяцев | от 1 дня до 1 недели | Менее суток | Менее 1 часа | | Изменить процент неудач | от 16 до 30% | от 16 до 30% | от 16 до 30% | от 0 до 15% |
Согласно Отчету о состоянии DevOps за 2021 г. (PDF) , производительность на разных уровнях впечатляет.
💡 В 2021 году команда DORA ввела пятый показатель: надежность, который измеряет операционную эффективность, оценивая, насколько организации достигают или превышают свои цели в области надежности.
Достижение элитного уровня с помощью показателей DORA
Позвольте мне предварить этот раздел несколькими предупреждениями:
- Метрики DORA применимы только для отслеживания прогресса команды в пути DevOps. Их нельзя использовать для сравнения команд или отдельных лиц.
- Не следует путать цели и показатели. Поскольку все показатели можно обмануть, приравнивание показателей к целям приводит к порочным стимулам. Если, например, руководство решит оптимизировать частоту развертывания независимо от затрат, в интересах команды внедрить любое крошечное изменение, которое они могут придумать, независимо от того, приносит оно пользу пользователю или нет.
- Организационная культура оказывает огромное влияние на эффективность команды. Мы вернемся к этому позже в этом посте.
Хорошо, теперь, когда это не так, давайте продолжим.
В последние несколько лет число элитных команд росло. В 2018 году только 7% команд или организаций считались элитными. В 2021 году это число выросло до 26%. Поэтому мы знаем, что рост достижим.
Созревание DevOps в индустрии программного обеспечения измеряется показателями DORA. Источник: отчет о состоянии DevOps за 2021 г.
Вопрос в том, как использовать показатели DORA, чтобы улучшить игру команды или организации. Плохое значение в метрике является симптомом. Это указывает на наличие организационных, культурных проблем или проблем с навыками, которые необходимо решить. После того, как они будут решены, базовая метрика должна естественным образом улучшиться.
Повышение пропускной способности
Организации с медленными производственными циклами имеют низкую частоту развертывания и большое время подготовки к изменениям. Часто мы можем повысить пропускную способность, оптимизировав непрерывную интеграцию и непрерывную доставку (CI/CD), выявив организационные проблемы, ускорив наборы тестов и сократив трения при развертывании.
Спросите себя: «Что мешает мне освободиться прямо сейчас?» Ответ выявит узкие места в организации. Например, вы можете тратить слишком много времени на проверку кода, ожидая одобрения изменений отделом контроля качества или откладывая выпуск до тех пор, пока другие команды не закончат свои функции.
Вы можете повысить пропускную способность несколькими способами:
* Уменьшите размер ваших релизов. Часто отправляйте небольшие безопасные изменения. Если функция не готова к использованию в прайм-тайм, выпустите ее, скрытую флагом функции, или с темным запуском. * Убедитесь, что весь процесс развертывания автоматизирован и может выполняться нажатием кнопки. Это означает отсутствие контрольных списков и ручного вмешательства во время развертывания. * Используйте разработку на базе Trunk. Это уменьшит вероятность конфликтов слияния и поощрит сотрудничество. * Оптимизируйте скорость непрерывной интеграции, управляя медленными тестами и удаляя ненадежные тесты. * Отслеживайте, сколько времени вы тратите на каждый шаг в процессе доставки программного обеспечения. Изучите время цикла и выясните, где вы можете сэкономить время.
Повышение стабильности проекта
Скорость без стабильности в конечном итоге приводит к накоплению технического долга и трате времени на исправление ошибок, а не на разработку функций. Когда показатели стабильности выглядят неудовлетворительно, у пользователей возникают проблемы, а разработчики тратят большую часть своего времени на тушение пожаров, а не на программирование.
Вот несколько идей, которым вы можете следовать, чтобы улучшить стабильность:
* Внедрение проверок качества кода в конвейере непрерывной интеграции. Отказ от доставки кода, который не соответствует номиналу. * Усильте процесс рецензирования кода или поэкспериментируйте с парным программированием. * Когда происходит бедствие, сосредоточьтесь на восстановлении, а не на всех других задачах. * Убедитесь, что в вашей системе достаточно средств мониторинга и наблюдения, чтобы быстро определить причину сбоя. * Проводите собрание по извлечению уроков каждый раз, когда происходит серьезное отключение. * Используйте дымовое тестирование в конвейерах развертывания, чтобы избежать развертывания в неисправной среде. * Реализуйте автоматический откат к вашему развертыванию. Поэкспериментируйте с canary или сине-зеленый развертывания.
Генеративная культура
Возможно, неудивительно, что в отчете о состоянии DevOps за 2021 г. была обнаружена тесная связь между элитными командами и генеративной культурой внутри организации. Термин "генеративная культура" был введен Роном Вестрамом для описания культуры, инклюзивность, готовность к сотрудничеству и обеспечение психологической безопасности, необходимой для того, чтобы идти на риск, не опасаясь последствий.
Культура организации выходит за рамки одной команды. Он должен поддерживаться руководством, разделяться командой инженеров и поддерживаться во всей компании. Генеративная культура устраняет разрозненность, поощряя сотрудничество за пределами инженерных групп.
| Патологический(Ориентированный на власть) | Бюрократический (ориентированный на правила) | Генеративный (ориентированный на производительность) | |----|----|----| | Низкое сотрудничество | Скромное сотрудничество | Высокое сотрудничество | | Мессенджеры «выстрелили» | Мессенджеры пренебрегают | Мессенджеры обучены | | Обязанности уклонялись | Узкие обязанности | Риски разделены | | Наведение обескуражен | Перекрытие допустимо | Наведение рекомендуется | | Неудача приводит к поиску козла отпущения | Неудача ведет к правосудию | Неудача приводит к расследованию | | Новинка дробленый | Новизна приводит к проблемам | Реализована новинка |
Источник: Типология организационных культур, доктор Рон Вестрам, 2004 г.
Заключение
Было бы ошибкой думать, что улучшение показателей DORA автоматически делает команду лучше. Наоборот: инклюзивная, генеративная культура естественным образом дает более высокие ориентиры. Другими словами, нет никаких шансов сохранить элитную команду в среде с низким уровнем сотрудничества и не склонной к риску. Использование показателей в качестве целей не только недальновидно, но и часто свидетельствует о том, что организация скатилась в патологическую или бюрократическую культуру.
Хотели бы вы знать, какой у вас балл по шкале DORA? Пройдите Быструю проверку DevOps и узнайте!
Также опубликовано здесь
Оригинал