Accelerate: мерить поставку, а не строки кода

Игорь объясняет выбор книги через свою работу: он пришёл из эксплуатации, работал в Skype и Microsoft, потом развивал DevOps как консультант Express 42 и написал первое исследование состояния DevOps в России, разобрав методологию из книги. Дальше он выстраивает хронологию: исследование состояния DevOps начинала Puppet как внутреннее маркетинговое, в 2012 году позвала Джина Кима и Джеза Хамбла сделать его публичным, и первый открытый отчёт вышел в 2013 году. Следом появились те самые четыре ключевые метрики, через год к команде присоединилась исследовательница Николь, принёсшая статистику и модель исследования, а ещё через год они основали компанию DORA и вели исследование с Puppet до 2018 года. Саму книгу Игорь называет большим отчётом за пять лет наблюдений, с 2013 по 2017 включительно: на слайде ровно пять кубиков. После выхода книги основатели продали DORA в Google Cloud, выпустили, по словам Игоря, отчёт за 2019 год и ушли; за 2020-й отчёта нет, но новая команда пересобралась и перепроверяет выводы предшественников.

Книга поделена на три части: находки, методология исследования и раздел о применении. У Александра есть свой конспект по первым двум частям — кейс-стади показался ему скучным, — и Игорь соглашается, что структура сырая: хочется сначала увидеть целиковую модель из приложения. Александр всё же защищает подачу: большая картинка пугает, когнитивная сложность зашкаливает, поэтому слона едят по частям, а схему складывают из знакомых деталей. Участники всё равно идут наоборот и начинают со схемы: слева лидерство, инженерные практики и бережливая разработка продукта, справа — Software Delivery Performance с четырьмя метриками и организационная эффективность как конечная цель. Есть и обратные стрелки: предсказуемая пропускная способность поставки снимает с продукта требование проектной предсказуемости. Авторы честно пишут, что это корреляции, а не причинно-следственные связи; в студии вспоминают пример корреляции потребления сыра со смертями от запутывания в простыне и замечают: конструкты в опросе спроектированы заранее, а значит, это не голая статистика.

Авторы противопоставляют свою модель возможностей моделям зрелости, и Игорь с ними не соглашается: против моделей зрелости писал Фаулер, но призыв никто не слышит — даже свежие движения наступают на старые грабли. Он предлагает искать баланс: связать практики, метрики и outcomes capability-моделью, а зрелость отдельной практики оценивать ступеньками. Александр объясняет, почему руководители любят ступеньки: пять уровней укладываются в голове лучше, чем 125 практик, и распространение практик у себя в компании они отслеживают картой практик — волной, где обязательные практики сначала внедряют, а потом расширяют набор. Сходятся на том, что все модели неверны, но некоторые полезны. Дальше разбирают метрики, которые авторы ругают, — строки кода, велосити и утилизацию. Александр видел премии за закрытые стори-поинты и сравнивает утилизацию с врачом, у которого расписан весь день: пациент с экстренной травмой будет ждать в очереди бесконечно.

Четыре метрики — срок поставки, частота развёртывания, время восстановления и доля неуспешных изменений — делятся на темп и стабильность и, по словам Игоря, балансируют друг друга: разгоняя одну, испортишь другую. Новыми они не были: про десять релизов в день говорили на конференции Velocity в 2009 году. Участникам нравится логика частоты релизов: спросить респондента про работу малыми порциями нельзя, зато можно померить, как часто из-под ножа выходит очередной тонкий ломтик. Организационную культуру авторы меряют не по модели Шейна, которую лишь упоминают, а по типологии социолога Веструма: патологическая, бюрократическая и производительная культуры различаются тем, как в организации движется информация. В опроснике это шесть характеристик и шкала Лайкерта, а рядом — лестница реакции на аномалии: подавление, «у нас всё под контролем», локальный фикс, глобальный фикс и поиск корневых причин. Александр прикладывает к ней Boeing: локальные фиксы, пока не упало несколько самолётов, и глобальный фикс скорее под внешним давлением.

Инженерная часть начинается с непрерывной поставки: встроенное качество, небольшие изменения ради быстрой обратной связи, автоматизация повторяющегося и общая цель вместо локальной оптимизации, а фундамент — управление конфигурацией и инфраструктура как код, непрерывная интеграция с короткоживущими ветками и непрерывное тестирование. Александр замечает: шесть лет назад это надо было обосновывать, а сегодня — гигиенический уровень. По архитектуре авторы утверждают, что тип приложения — greenfield или brownfield, своя разработка или аутсорс, мейнфрейм или мобильное — на ключевые метрики не влияет; Игорь по опыту не согласен, а Александр добавляет статистическую поправку: не найти эффект не значит доказать его отсутствие, да и разделять типы приложений исследование не собиралось. Дальше — закон Конвея и обратный манёвр, платформенные и стримлайн-команды и график, где у высокого кластера частота развёртывания на разработчика с ростом команды растёт, а у отстающего падает. Главу про безопасность оба читают как переход команды инфобеза в платформенную: проверки встроены в пайплайн и отданы разработчикам как удобные инструменты.

Вторая часть объясняет, почему опросам можно верить: это первичное количественное исследование со шкалой Лайкерта, но статистический анализ авторы берут трёх простейших типов, поэтому говорят о корреляции и предсказании, а не о причинности — в опросе нельзя манипулировать переменными. Кластеры эффективности получают алгоритмом кластеризации, и границы плавают: элитный кластер добавляли, в 2022 году убирали и потом вернули, так что сравнение с индустрией всегда привязано к году. Игорь признаёт: в российском исследовании 2020 года повторить конструкты было нельзя — опросники DORA тогда не публиковала, — и взяли только ключевые метрики, кластерный анализ и часть практик. Александр объясняет, почему инструментальные данные не спасают: даже внутри подразделения в тысячу человек надо договориться о типах задач, декомпозиции, workflow и точке коммитмента, а между компаниями сравнимость теряется. Кейс голландского банка на девять тысяч инженеров Игорь считает слабым, а Александру он показался просто неинтересным; обновлённая модель DORA Core 2024 меряет эффективность ещё и на уровне команды и изучает влияние ИИ.