Value Stream Mapping — инструкция к применению

Value Streams являются основополагающим компонентом SAFe® (Scaled Agile Framework®) и бывают двух типов: разработческие (Development Value Stream, DVS) и операционные (Operational Value Stream, OVS).

Мы предполагаем, что вы уже знакомы с этими терминами, но если вдруг нет или хотите обновить знания, то статья Безжалостное непрерывное улучшение оргструктуры по SAFe отлично подойдет.

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

Как проводится Value Stream Mapping

Value Stream Mapping (VSM) — это системный подход к визуализации шагов, необходимых для создания ценности.

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

Шаг 1. Определите все шаги, от создания концепции до получения выручки

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

Всегда легче разбираться на примере, поэтому давайте представим, что наш Value Stream начинается с определения фич, затем проходит через этапы проектирования, разработки и тестирования. Если наш Продуктовый Менеджмент принимает полученные результаты работ, то фича выкладывается на тестовую среду для проведения smoke-тестов и тщательной приемки от пользователей.

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

Шаг 2. Определите участников процесса

Второй шаг — определение всех людей, которые участвуют в том или ином этапе DVS.

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

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

Шаг 3. Проведите замеры DVS

Третий этап — измерение параметров разработческого Value Stream. Нас будут интересовать три метрики, которые необходимо определить для каждого шага.

Первая метрика — Process Time (PT), она фиксирует фактическое время, необходимое для выполнения работ в рамках отдельного этапа.

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

Вторая метрика — Lead Time (LT). Она определяет интервал времени между завершением предыдущего шага и завершением следующего шага, проще говоря — время ожидания между шагами плюс Process Time следующего шага. По сути — это календарное время.

Lead Time в нашем примере — 700 часов. Помните, что это время с момента завершения приемки Продуктовым Менеджментом до момента завершения переноса на тестовый контур. Оказывается, что длительный Lead Time связан с тем, что перенос на тестовую среду может быть выполнен только в определенные даты, согласованные с релиз-менеджером.

Последняя метрика — Percent Complete and Accurate (%C&A). Она отражает процент результатов, которые могут успешно использоваться на следующем шаге, без необходимости возврата на предыдущие шаги для исправлений.

Для того, чтобы узнать Percent Complete and Accurate для этапа переноса сборки на тестовую среду, мы должны задать вопрос людям, которые проводят smoke-тестирование: «Как часто вы не можете работать, потому что сборка была некорректно установлена на тестовое окружение?». Только не путайте с вопросами из серии: “Как часто вы обнаруживаете дефекты?” или “Какие у вас smoke-тесты?”.

Они могут ответить, что в 90% случаев то, что мы получаем на тестирование, выложено корректно, но в 10% случаев нам приходится возвращать сборку обратно на исправление. Таким образом, для шага развертывания в тестовый контур, метрика равна 90%.

На шаге замера DVS есть три важных правила, о которых нельзя забывать:

• Используйте подход последовательно и заполняйте все три метрики для каждого шага, прежде чем двигаться дальше.
• На некоторых шагах вы сразу увидите, что есть проблемы, которые пришли из предыдущих этапов. В таких случаях уточните метрику Percent Complete and Accurate для шагов, из которых тянутся проблемы.
• Lead Time включает Process Time, поэтому первая метрика должна всегда быть больше или равна второй.

Шаг 4. Рассчитайте финальные метрики

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

Итоговые метрики Total Process Time (Total PT) и Total Lead Time (Total LT) рассчитываются как сумма значений метрик Process Time и Lead Time всех шагов соответственно.

Следующая метрика Activity Ratio — это отношение Total Process Time к Total Lead Time, выраженное в процентах. Она позволит определить, какая часть времени действительно была потрачена на создание ценности, и сколько времени мы провели в ожидании.

Не нужно огорчаться, если вы выяснили, что ваша метрика Activity Ratio далека от 100% — это нормально и предсказуемо. Значение этой метрики обычно низкое, часто сильно ниже 30%, особенно у команд, которые только начинают свой путь в SAFe и DevOps. Вместо огорчения лучше сфокусируйтесь на определении проблемных мест, которые вызывают потерю эффективности.

Андрей Булов, SPC (SAFe Program Consultant), про теорию и практику DevOps максимально простыми словами

Низкий показатель Activity Ratio обычно означает, что у вас есть возможность быстро избавиться от значительных источников временных потерь и задержек.

Метрика Rolled of Percent Complete and Accurate — это вероятность того, что элемент бэклога пройдет через всю последовательность шагов DVS без возвратов на исправление. Метрика рассчитывается путем перемножения показателей %C&A всех этапов DVS, но не как среднее значение.

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

Не следует трактовать полученное значение как процент фич, в которых не было найдено ошибок. Например, в нашем случае следует понимать этот показатель так, что примерно 36 фич из 100 проходят через весь разработческий Value Stream без возвратов на предыдущий этап (переделок, исправлений и т.п.). В то время как остальные 64 в какой-то момент вернулись хотя бы на один шаг назад.

Команды, которые едва знакомы с подходом могут спросить: как должно выглядеть идеальное положение вещей? К каким показателям нам необходимо стремиться?

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

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

Заключение

Value Stream Mapping — это многогранный инструмент, который используется не только для поиска решений, но и для понимания проблемных мест.

Подводя итоги, хочется сказать, что с помощью DVS Mapping, вы не только определите несколько полезных для работы метрик, но и:

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

Без использования Value Stream Mapping мы рискуем решать не те проблемы, вовлекать не тех людей и раз за разом терпеть поражение в попытках провести положительные организационные изменения.

Чтобы еще лучше разбираться в Value Stream Mapping рекомендуем пройти курс SAFe DevOps, который поможет точнее понять взаимосвязь между DevOps и Value Stream.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.