Accelerate: наука о скорости доставки

О чём книга

Николь Форсгрен, Джез Хамбл и Джин Ким потратили четыре года на то, чтобы статистическими методами доказать связь между техническими практиками и бизнес-результатами. Они собрали данные у более чем 23 000 респондентов из 2 000 организаций через ежегодный State of DevOps Report, который они проводили совместно с Puppet. Организации были самые разные: стартапы, Fortune 500, некоммерческие проекты, компании в процессе цифровой трансформации. Форсгрен, будучи PhD в области информационных систем, привнесла в исследование академическую строгость, которой так не хватало разговорам о DevOps.

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

Ключевые идеи

Центральная мысль Accelerate: производительность доставки софта можно измерить четырьмя метриками. Deployment Frequency показывает, как часто команда выкатывает код в продакшен. Lead Time for Changes фиксирует время от коммита до работы кода на проде. Change Failure Rate считает процент деплоев, которые приводят к инцидентам. Time to Restore Service измеряет, как быстро команда восстанавливает сервис после сбоя.

Авторы обнаружили, что команды группируются в кластеры по этим метрикам: Elite, High, Medium, Low. Элитные команды деплоят по несколько раз в день с lead time меньше часа, держат change failure rate ниже 15% и восстанавливаются за час. В отчёте 2018 года авторы впервые выделили элитных перформеров как отдельную категорию: 7% от всех высокопроизводительных команд.

Второй ключевой тезис: скорость и стабильность не противоречат друг другу. Это контринтуитивно. Многие менеджеры десятилетиями считали, что нужно выбирать между «быстро» и «надёжно». Данные Форсгрен показали обратное: элитные команды превосходят остальных и по скорости, и по стабильности одновременно.

Третья идея: конкретные технические практики предсказывают производительность. Авторы через статистический анализ выделили 24 «capabilities», которые коррелируют с высокой производительностью. Среди них: trunk-based development, непрерывная интеграция, автоматизация тестирования, мониторинг и наблюдаемость, работа малыми батчами, loosely coupled architecture. Каждую из этих практик авторы подкрепили данными, а не мнениями.

Что можно применить

Начните с измерения. Четыре метрики DORA достаточно просты, чтобы собрать их из уже имеющихся инструментов. Частоту деплоев вы достанете из CI/CD-логов, lead time посчитаете по git-истории и временным меткам деплоев, change failure rate соберёте по тикетам инцидентов, MTTR возьмёте из системы алертинга. Не покупайте для этого платформу за тысячи долларов в месяц. Таблица в Google Sheets, которую вы заполняете раз в неделю, на старте работает не хуже.

Книга даёт конкретный чеклист: если ваша команда не использует trunk-based development, начните с него. Если CI прогон занимает сорок минут, сократите его до десяти. Если деплой требует ручного одобрения от трёх человек, автоматизируйте approval. Каждый пункт из 24 capabilities можно превратить в конкретную инженерную задачу с измеримым результатом.

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

Критика

Методология исследования вызывает вопросы. Все данные собраны через опросы с самооценкой (self-reported surveys), а это значит, что на результаты влияет halo effect: команды, которые считают себя успешными, склонны завышать все показатели разом. Форсгрен и её коллеги не опубликовали ни полные тексты вопросов, ни сырые данные. Без этого независимые исследователи не могут воспроизвести анализ и проверить выводы.

Рецензент Кюнву Ли написал подробный разбор, в котором указал на «неаккуратную и вводящую в заблуждение» подачу статистических корреляций. Корреляция между практиками и результатами не означает причинно-следственной связи, а авторы местами подают её именно так.

Исследователь Джунейд Али совместно с британской социологической фирмой Survation провёл отдельное исследование и обнаружил, что инженеры и широкая публика считают другие факторы значимее четырёх метрик DORA для оценки производительности.

Ещё одна проблема: команда DORA в октябре 2023 года выпустила предупреждение о том, что метрики нельзя использовать для сравнения команд между собой. Но организации делают именно это, превращая DORA в инструмент давления на отстающие команды.

Наконец, книга ничего не говорит об опыте самих разработчиков: удовлетворённости, когнитивной нагрузке, состоянии потока. Четыре метрики описывают здоровье delivery pipeline, но молчат о том, каково людям работать внутри этого pipeline. Позднее фреймворки SPACE и DevEx Framework попытались закрыть этот пробел.

При всех ограничениях, Accelerate остаётся книгой, которую стоит прочитать первой, если вы начинаете думать о Developer Experience. Она задала язык, на котором индустрия обсуждает производительность разработки, и любой последующий фреймворк так или иначе строится на фундаменте, который заложили Форсгрен, Хамбл и Ким.