Как повышать качество разработки. Часть 1. DORA метрики, Control Chart и инциденты

Любая уважающая себя команда разработки стремится создавать качественный продукт и улучшать свои процессы. Пробуя новые практики и инструменты, на ретроспективах и обсуждениях команда может оценить улучшения, но эта оценка будет субъективна, поскольку она основывается на ощущениях разработчиков. Чтобы вывести процесс повышения качества разработки в объективное поле, существует специальный набор метрик, о котором мы расскажем в этой статье.

Для понимания сути этого процесса остановимся сначала на очень простом и фундаментальном понятии в разработке ПО. Это понятие — инцидент.

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

Мы разделяем два типа инцидентов: технический и сервисный. Технический инцидент приводит к неправильной работе или неработоспособности системы для пользователя. Сервисный инцидент — это событие, которое влияет на качество обслуживания, предоставляемого клиентам, но не связано напрямую с функционированием системы. Например, отказ в работе серверов или сетевой инфраструктуры — это технический инцидент. А отсутствие реакции на обращение клиента в течение регламентированного времени — сервисный.

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

Инциденты — это важная объективная единица измерения на пути к улучшениям.

Второе важное определение — это формулировка улучшения в контексте разработки ПО. Ответ на этот простой вопрос не так очевиден, как кажется на первый взгляд. Что значит улучшить процесс разработки? Качественнее проектировать код, бороться с бюрократическими проблемами, сокращать ручной труд, оптимизировать тестирование? Все вместе? И что важнее?

После долгих дебатов и обсуждений внутри команды мы пришли к выводу, что улучшение, которого мы хотим достигнуть, это ускорение выдачи версий на продакшн, то есть, выкладывание конечных версий продукта для релиза. Иными словами, улучшение для нас — это сокращение релизного цикла. При этом, качество выпущенного продукта не должно пострадать.

Общепринятый стандарт индустрии для ответа на эти вопросы — это система из четырех метрик, созданная группой DevOps Research and Assessment (DORA) в Google для оценки эффективности разработческих команд в рамках масштабного исследования, которое учло результаты опросов множества компаний с целью выявить лучшие практики в разработке программного обеспечения.

1. Deployment Frequency / Частота обновлений — количество обновлений за месяц. Как часто вы выпускаете обновления? В бенчмарках отчетов Google и в обозначенной нами цели, чаще — значит лучше. В идеале обновления должны выпускаться по требованию, то есть, если нужно, то хоть по несколько раз в день. Однако нельзя рассматривать эту метрику в отрыве от реального проекта. Если частое обновление веб-приложений ожидаемо и никак не отражается на пользователе, то для мобильного приложения такие частые обновления избыточны и потенциально могут привести к проблемам.

2. Time to Restore Service / Время на восстановление сервиса — медианное время на восстановление после сбоя в календарном месяце. После возникновения инцидента, как быстро вы можете восстановить работу системы? В идеале на это должно уходить не больше часа, а время больше нескольких дней может быть сигналом для того, чтобы обозначить себе новую цель для улучшений. Чтобы быстро находить источник проблемы и восстанавливать сервис за минимальное время, мы используем систему мониторинга, о которой мы рассказали в другой статье.

3. Change Failure Rate / Процент проблемных обновлений — какой процент ваших обновлений привел к возникновению инцидентов или ухудшению сервиса для пользователя? Эта метрика не должна ухудшаться с ростом первой метрики: если мы выпускаем обновления в два раза чаще и имеем в два раза больше проблем, то мы должны обратить внимание на их качество, а не гнаться за частотой.

4. Lead Time for Changes / Время проведения обновления — скорость поставки комитов на прод. Сколько времени проходит до момента, когда изменения в коде попадают на продакшен? Если это время больше месяца, в момент выпуска кода команда будет погружена в следующую задачу, и в случае неудачной поставки и возникновения инцидента, ее сложнее будет исправить.

Поскольку мы “нетипичная” разработческая команда, так как работаем не над одним собственным продуктом, а одновременно разрабатываем около 20 продуктов для наших заказчиков, мы руководствуемся не бенчмарками индустрии, а спецификой проекта, которая влияет на то, какие факторы мы считаем важными и какие показатели считаем хорошими или предпочитаемыми. Например, мобильное приложение не следует обновлять чаще нескольких раз в месяц, поэтому мы не будем считать плохим низкий показатель Deployment Frequency для мобильного приложения.

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

Такие практики, при которых всегда существует актуализированная стабильная версия, которую можно сразу выложить и доставить конечному пользователю, необходимы для того, чтобы обеспечить возможность быстро выпустить простое, но важное обновление, потому что иначе цикл разработки живет в двух фазах, одна из которых — стабилизация и устранение ошибок.

В наших проектах DORA метрики отслеживают тим-лид и проектный менеджер, и пользуются при этом разными инструментами.

Тим-лид использует DevLake Technical Board, который позволяет подключаться к различным системам, хранящим данные о технических и управленческих транзакциях в проекте (GitLab, Kira, Jenkins), собирать с них разнообразные метрики, визуализацию которых можно легко настроить для последующего анализа. На основе этих данных можно рассчитать не только DORA-метрики, но и дополнительные целевые показатели, определяемые для проведения целевых улучшений в проектах.

DORA описывает ситуацию верхнеуровнево, но инструменты DevLake позволяют строить графики и по более детальным показателям. Например, на одном из наших проектов мы увидели, что после сокращения количества разработчиков увеличилось количество задач со статусом “Критично” и выросло время реализации требований. Это помогло нам понять, что сокращение существенно повлияло на проект, текущих ресурсов недостаточно, и команду следует увеличить.

Проектный менеджер использует Jira Control Chart. Это инструмент для выявления аномалий в прохождении тикетов через цепочку статусов. Настраиваемый дашборд позволяет выбрать нужный отрезок времени, статус, тип тикета и посмотреть на тренды и пики задержек. Если выбрать в качестве цели уменьшение ожидаемого времени разработки, графики позволят отследить, изменилось ли что-нибудь после внедрения изменений, которые должны были способствовать достижению этой цели. Графики хорошо иллюстрируют проблемные зоны в процессе и являются незаменимым инструментом для проектного менеджера.

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