2.0 Введение в часть 2: Метрики потока

Если часть 1 это философия измерения, то часть 2 это место, где эта философия встречается с самой доставкой: метрики, описывающие не только то, насколько быстро и насколько безопасно команда перемещает код от идеи к работающей системе, но и то, какого рода ценность вообще движется через этот конвейер. Эта часть организована вокруг Flow Framework, модели, созданной Миком Керстеном в его книге 2018 года Project to Product, которая рассматривает доставку программного обеспечения как поток создания ценности и даёт этому потоку общий словарь: четыре типа элементов потока и пять метрик потока, связывающих инженерную активность с бизнес-стратегией в терминах, которые действительно может использовать нетехническая заинтересованная сторона.

Этот выбор организующего фреймворка намеренный. Метрики DORA, частота развёртывания, время выполнения, доля неудачных изменений и время восстановления, по-настоящему подтверждены исследованиями и остаются одним из лучше всего обоснованных доступных фреймворков доставки, но они измеряют механику конвейера, а не то, что через него течёт. Команда может показывать отличные показатели DORA, пока её фактически доставляемая ценность тихо дрейфует к переделке или прочь от работы с долгом и риском, защищающей будущее системы. Эта часть покрывает DORA полностью, но как единую сводную справочную тему в конце (тема 2.10), потому что более срочный, более часто отсутствующий вопрос для большинства организаций не «насколько быстр наш конвейер», а «что наш конвейер на самом деле доставляет». Каждая тема этой части по-прежнему следует той же дисциплине, установленной в части 1: сформулировать метрику, назвать способ её подделки и сочетать её со страховочной метрикой, улавливающей это манипулирование.

Для крупных команд метрики потока это то, что делает возможным межкомандное сравнение, не теряя из виду ценность. У платформенной команды, мобильной команды и команды данных может быть почти ничего общего в их повседневной работе, но скорость потока и распределение потока, вычисленные последовательно, позволяют руководству задать справедливый вопрос по всем трём: доставляет ли эта команда тот вид ценности, который действительно требует её текущая фаза. Корпоративные и государственные организации полагаются на метрики этой части, чтобы обосновать инвестиции в платформу, сравнить отдачу от конкурирующих усилий по модернизации и продемонстрировать, с доказательствами, а не анекдотами, что инженерная мощность распределена так, как руководство считает.

Темы этой части

2.1 Flow Framework: Происхождение фреймворка, его модель потока создания ценности и почему эта книга использует его, а не только DORA, для организации метрик доставки и потока.
2.2 Элементы потока: функции, дефекты, риски и долг: Таксономия фреймворка из четырёх типов, её распределение мощности с нулевой суммой и как классификация подделывается при ретроспективном применении.
2.3 Скорость потока и распределение потока: Сколько было отгружено и какого рода была эта ценность, всегда читаемые вместе.
2.4 Время потока и нагрузка потока: Как закон Литтла доказывает, что перегруженный поток создания ценности математически замедляется, а не просто вероятно.
2.5 Эффективность потока и незавершённая работа: Почему занятость не то же самое, что скорость, и как ограничение незавершённой работы контринтуитивно улучшает пропускную способность.
2.6 Время цикла и его составляющие: Разбиение инженерного времени изменения на составляющие его этапы, чтобы команда точно знала, куда на самом деле уходит время.
2.7 Теория очередей: Математика под нагрузкой потока, временем потока, временем цикла и незавершённой работой, и почему время ожидания на общем ресурсе взрывообразно растёт по мере приближения утилизации к своему пределу.
2.8 Метрики бережливого потока создания ценности: Классический инструментарий Lean, время выполнения, время процесса, время цикла, процент полноты и точности, время такта, от которых происходят специфичные для программного обеспечения метрики этой части, и как навести мост между двумя словарями.
2.9 Метрики пулл-реквестов и ревью кода: Метрики, живущие внутри одного этапа конвейера доставки, и как они могут исказить качество ревью при неосторожном использовании.
2.10 Фреймворк метрик DORA: Четыре метрики DORA полностью, намеренно размещённые последними, потому что они измеряют конвейер, а не ценность, текущую через него.

Как эти темы взаимосвязаны

Тема 2.1 вводит Flow Framework в целом; тема 2.2 даёт его таксономию элементов потока, а темы 2.3 и 2.4 покрывают между собой его пять метрик потока, скорость и распределение вместе, затем время и нагрузку вместе, с нагрузкой и временем, напрямую привязанными к закону Литтла. Темы с 2.5 по 2.7 приближают механику под временем потока и временем цикла конкретно: эффективность потока и незавершённая работа объясняют, почему инженерные этапы часто медленнее, чем кажутся, время цикла разбивает эту инженерную часть на её этапы, а теория очередей формализует, в доказуемых математических терминах, почему все утверждения предыдущих тем о нагрузке, времени ожидания и утилизации истинны. Тема 2.8 отступает назад, чтобы проследить всё это до его происхождения в классическом картировании потока создания ценности Lean, общем словаре, от которого обобщаются специфичные для программного обеспечения метрики этой части. Тема 2.9 покрывает единственный этап конвейера, который большинство команд может улучшить быстрее всего. Тема 2.10 закрывает эту часть метриками DORA полностью, представленными как хорошо обоснованный, но более узкий справочный слой, когда более широкая, обращённая к бизнесу картина из предыдущих тем уже в поле зрения.

Дисциплина страховочных метрик этой части напрямую связана с темой 1.2: скорость потока никогда не сообщается без распределения потока рядом с ней, а метрики скорости DORA остаются сочетаемыми с её метриками стабильности, так что команда не может улучшить показатель скорости, тихо отгружая более рискованный код или более узкий набор ценности. Это сочетание не случайно для любого из фреймворков; это центральное озарение каждого фреймворка, и метрики надёжности части 6 продолжают ту же половину стабильности этого сочетания в производственных операциях после того, как код уже отгружен.