2.6 Время цикла и его составляющие

Обзор и мотивация

Время цикла это внутренняя разбивка времени потока изменения (тема 2.4) на составляющие его инженерные этапы: время кодирования, время ревью, время тестирования и время развёртывания, иногда дополнительно разделённые на время подхвата (как долго изменение ждёт, прежде чем кто-то начнёт над ним работать) и активное время (сколько это занимает, как только кто-то начинает). Там, где время потока даёт вам единственное число для того, сколько времени занимает изменение сквозным образом через весь поток создания ценности, время цикла говорит вам, куда на самом деле уходит это время, как только оно достигает инженерии, что и есть диагностический слой, который, как обещала тема 2.4, лежит под её собственным сводным числом.

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

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

Ключевые принципы

• Время цикла объясняет время выполнения; оно его не заменяет. Сообщайте оба вместе, с временем цикла как диагностикой и временем выполнения как сводкой.
• Время ожидания обычно доминирует над активным временем. Большая часть задержки в доставке программного обеспечения происходит от работы, простаивающей в очереди, а не от активных усилий (тема 2.5 покрывает это напрямую через эффективность потока).
• Раскладывайте по этапам, прежде чем предлагать исправление. Исправление, нацеленное не на тот этап, тратит усилия впустую и может деморализовать команду, которую попросили «работать быстрее», когда реальное узкое место было в другом месте.
• Общее узкое место для многих команд это возможность для платформенной инвестиции, а не просто серия индивидуальных командных проблем.
• Данные времени цикла подвержены тем же рискам манипулирования, что и время потока (тема 2.4): следите за границами этапов, которые тихо сдвигаются, чтобы приукрасить число.

Рекомендации

Инструментируйте каждую границу этапа явно

Разбейте путешествие изменения на именованные этапы с ясными инструментируемыми границами: кодирование (от первого коммита до открытия пулл-реквеста), подхват (от открытия пулл-реквеста до первого ревью), ревью (от первого ревью до одобрения) и развёртывание (от одобрения до продакшена). Захватывайте временные метки для каждого перехода автоматически из событий контроля версий и CI/CD, а не из самоотчётного отслеживания этапов, применяя тот же принцип инструментирования важнее самоотчёта из темы 1.5.

Отделяйте время ожидания от активного времени внутри каждого этапа

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

Ищите общее узкое место, прежде чем диагностировать команду за командой

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

Используйте время цикла, чтобы установить реалистичные специфичные для этапа цели улучшения

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

Следите за манипулированием границами этапов

Точно так же, как начальная и конечная точки времени потока могут дрейфовать (тема 2.4), отдельные границы этапов времени цикла могут сдвигаться способами, приукрашивающими число конкретного этапа без какого-либо реального улучшения, например, отмечая ревью как «начатое» в момент назначения рецензента, а не когда он фактически начинает читать изменение. Периодически проверяйте инструментирование границ этапов против их документированного определения.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Грубое время цикла (два-три этапа)	Просто инструментировать и объяснять	Может не указать на фактическое узкое место достаточно точно, чтобы действовать
Детализированное время цикла (много этапов, разделение ожидания и активности)	Точная диагностика, действенные специфичные для этапа цели	Больше усилий на инструментирование; больше чисел для обслуживания и объяснения
Командный обзор времени цикла	Подогнан под фактический рабочий процесс каждой команды	Может упустить общее межкомандное узкое место, скрывающееся за похожими локальными числами
Межкомандный агрегированный обзор времени цикла	Раскрывает общие узкие места на уровне платформы	Требует стандартизированных определений этапов между командами, чтобы быть значимым

Центральное напряжение: диагностическая точность против стоимости инструментирования. Более детализированное отслеживание времени цикла даёт более действенную диагностику, но стоит дороже строить и обслуживать и добавляет больше чисел, которые команда должна понимать и которым должна доверять. Разрешайте это напряжение, начиная грубо (кодирование, ревью, развёртывание) и добавляя более тонкие разделения, ожидание против активного времени внутри конкретного этапа, только после того как этот этап подтверждён как настоящее повторяющееся узкое место, достойное дополнительной инвестиции в инструментирование.

Вопросы для обсуждения в команде

1. Если бы время выполнения регрессировало сегодня, могли бы мы сказать в течение часа, какой конкретный этап был ответственен, используя данные, а не догадки? Это основной тест того, действительно ли ваше инструментирование времени цикла служит своей диагностической цели. Если честный ответ «нет», эту брешь стоит закрыть до того, как произойдёт следующая регрессия.

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

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

4. Установили ли мы специфичные для этапа цели улучшения, или только единую общую цель времени выполнения без ориентира о том, на чём сосредоточиться? Расплывчатая цель оставляет команду гадать, куда вкладывать усилия; специфичная для этапа нет. Проверьте ваши текущие цели на это различие.

5. Дрейфовала ли когда-либо какая-либо граница этапа времени цикла в нашем инструментировании от своего документированного определения со временем? Границы этапов подвержены тому же риску дрейфа определения, что и само время потока (тема 2.4). Проверьте выборку недавних событий перехода этапов против письменного определения.

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

Отраслевой взгляд

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

Малый бизнес. Базовая аналитика платформы контроля версий обычно раскрывает достаточно времени на уровне этапов (время до первого ревью, время до слияния) без кастомного инструментирования. Сосредоточьтесь сначала на этапе ревью, поскольку это самое распространённое раннее узкое место и самое простое для исправления небольшим изменением процесса вроде ротации рецензентов.

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

Государство. Данные времени цикла это сильный конкретный инструмент для обоснования модернизации процесса перед скептически настроенными заинтересованными сторонами, поскольку «время ожидания ревью в среднем четыре дня из-за единственной узкой роли утверждения» это гораздо более убедительный конкретный аргумент для инвестиции, чем абстрактное заявление «наш процесс медленный».

Примеры

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

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

Бизнес-кейс: мотивация, ROI и TCO

Отдача от разложения времени цикла: целенаправленная эффективная инвестиция: организация, точно знающая, какой этап является узким местом, может исправить именно этот этап, а не распределять усилия тонко по всему процессу в надежде, что что-то поможет. Пример с ревью безопасности выше типичен: точно нацеленное исправление, расширение одного конкретного узкого ресурса, разрешило общеорганизационную проблему гораздо дешевле, чем это сделала бы широкая нефокусированная инициатива «ускорить доставку».

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

Антипаттерны и ловушки

• Реакция на регрессию времени выполнения без диагностики времени цикла: часто приводит к исправлению не того этапа.
• Предположение, что активные усилия, а не время ожидания, являются доминирующей стоимостью: обычно неверно; очередь доминирует в большинстве реальных конвейеров доставки (тема 2.5).
• Упущение общего межкомандного узкого места из-за рассмотрения времени цикла только команда за командой: оставляет необнаруженным высокорычажное платформенное исправление.
• Установление расплывчатой общей цели времени выполнения без ориентира, специфичного для этапа: оставляет команды гадать, на чём сосредоточить усилия.
• Дрейф определения границы этапа: приукрашивает число конкретного этапа без реального улучшения.
• Инструментирование каждого возможного детализированного этапа до подтверждения, что какой-либо из них является настоящим узким местом: тратит усилия на инструментирование деталей, пока не информирующих решение.

Модель зрелости

• Уровень 1, Инициация: Время цикла вообще не разлагается; команды гадают об узких местах, когда время выполнения регрессирует.
• Уровень 2, Развитие: Некоторые команды неформально отслеживают грубое время по этапам, но нет последовательного инструментирования или межкомандного сравнения.
• Уровень 3, Стандартизация: Границы этапов последовательно инструментированы по всей организации, с временем ожидания, отделённым от активного времени на доминирующих узких этапах.
• Уровень 4, Управление: Межкомандная агрегация времени цикла активно выявляет общие узкие места; специфичные для этапа цели улучшения заменяют расплывчатые общие цели времени выполнения.
• Уровень 5, Оркестрация: Данные времени цикла напрямую управляют приоритизацией платформенных инвестиций, и организация может указать на конкретные целенаправленные исправления, расширенный пул ревью, более быстрый общий конвейер, которые измеримо улучшили время выполнения по многим командам одновременно.

Идеи для обсуждения

1. Каков наш текущий доминирующий узкий этап, и насколько мы уверены в этом ответе?
2. Сколько времени этого узкого этапа это время ожидания против активного времени?
3. Разделяют ли какие-либо наши команды одно и то же узкое место, предполагая исправление на уровне платформы?
4. Когда мы в последний раз устанавливали специфичную для этапа, а не общую цель улучшения доставки?
5. Менялось ли когда-либо определение границы этапа в нашем инструментарии без документирования?

Основные выводы

• Время цикла раскладывает время потока на инженерные этапы, кодирование, ревью, тестирование, развёртывание, и является диагностическим слоем под этим сводным числом.
• Отделяйте время ожидания от активного времени внутри каждого этапа; очередь обычно доминирует над активными усилиями (тема 2.5).
• Ищите общие узкие места между командами, прежде чем предполагать, что замедление специфично для команды; общая причина часто является возможностью для платформенной инвестиции.
• Устанавливайте специфичные для этапа цели улучшения, а не расплывчатые общие цели, чтобы команды точно знали, на чём сосредоточиться.
• Границы этапов подвержены тому же риску дрейфа определения, что и само время потока; проверяйте их периодически.
• Тема 2.7 даёт лежащую в основе математику, закон Литтла, для того, почему незавершённая работа и время цикла движутся вместе.

Источники и дальнейшее чтение

• The Principles of Product Development Flow, Дональд Г. Рейнертсен.
• Actionable Agile Metrics for Predictability, Дэниел С. Ваканти.
• Accelerate: The Science of Lean Software and DevOps, Николь Форсгрен, Джез Хамбл и Джин Ким.
• The Goal, Элияху М. Голдратт.