Как обеспечить непрерывное движение ценности?

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

Gene Kim et al., The DevOps Handbook

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

Принципы и практики, которые обеспечивают непрерывный поток ценност и в SAFe, являются неотъемлемой частью установок Lean-Agile и «Бережливого Мышления» [1], которые можно резюмировать следующим образом:

1. Точно определить ценность для каждого продукта
2. Идентифицировать поток создания ценности для каждого продукта
3. Обеспечить непрерывное движение ценности
4. Позволить клиенту (со своей стороны) «вытягивать» ценность от производителя
5. Стремиться к совершенству

В центре внимания этой статьи находится пункт 3 — как мы создаём поток с непрерывным движением ценности.

Что такое поток?

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

Каждое из 8 свойств потока кратко описано ниже:

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

Политики. Политики являются неотъемлемой частью потока. Это могут быть локальные политики, такие как политики команды, которые определяют, как элемент работы перемещается от одной стадии к другой, или глобальные политики, подобные тем, которые регулируют, как выполняется работа в компании.

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

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

Узкие места.  В каждой системе потока одно или несколько узких мест ограничивают прохождение потока через всю систему.

Работник. Люди выполняют важную работу по перемещению и преобразованию элементов работы из одного состояния в другое.

Незавершенная работа (НЗР, WIP, иногда называется «Работа в процессе»). В системе всегда есть какая-то незавершенная работа; если бы ее не было, не могло бы быть и потока ценности.

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

Восемь ускорителей потока

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

#1 Визуализация и ограничение незавершенной работы (НЗР/WIP)

Перегрузка команд и поездов бОльшим количеством работы, чем может быть объективно выполнено, является распространенной и пагубной проблемой. Слишком много незавершенной работы (WIP) путает приоритеты, вызывает частое переключение контекста и увеличивает накладные расходы. Это перегружает людей, перенаправляет внимание на сиюминутные задачи, снижает производительность и пропускную способность, а также увеличивает время ожидания для новой функциональности. Нет ничего хорошего в том, чтобы загрузить в систему больше работ, чем она может обработать. Ситуация с перегрузкой потока напоминает состояние скоростного шоссе в час-пик.

Первое корректирующее действие заключается в том, чтобы сделать текущую НЗР (WIP) видимой для всех заинтересованных сторон. На рисунке 2 показана простая Kanban доска, которая иллюстрирует общее количество НЗР и стадию процесса для каждого элемента работы. Этот Канбан служит начальной диагностикой процесса, показывая текущие узкие места. Часто простая визуализация текущего объема работ уже становится «тревожным звонком», который заставляет организацию искать решение для системных проблем, связанных со слишком большим объемом работы и слишком малым потоком.

Следующим действием является уравновешивание объема НЗР с доступной ёмкостью разработки. Это делается путем установки и постоянной корректировки пределов НЗР для соответствующих шагов. Новая работа не выполняется, если какая-либо стадия рабочего процесса достигает предела НЗР. Это выравнивает спрос и ёмкость, при этом увеличивая поток через систему.

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

#2 Устранение узких мест

Узкими местами (бутылочными горлышками) являются люди или ресурсы (системы, материалы и т. д.) в потоке ценности, спрос на которые равен или превышает доступную емкость [2]. Например, это может быть нехватка специализированных навыков (таких как обработка и анализ данных), недостаточная вычислительная мощность для серверов сборки в конвейере CI/CD или нехватка полупроводников для создания интегральных схем киберфизической системы. Работа накапливается в узком месте и ограничивает эффективную пропускную способность для течения ценности, как показано на рисунке 3. Процессы, находящиеся выше по течению (раньше), «голодают» и ждут. Другими словами, узкие места заставляют систему работать медленно и нерентабельно, намного ниже ее потенциальной ёмкости.

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

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

#3 Минимизация передач из рук в руки и зависимостей

Передачи из рук в руки происходят всякий раз, когда существует разделение между знаниями, ответственностью, действием и обратной связью [4]. Например, зависимости возникают между командами, когда одна команда не может продолжать свою работу до тех пор, пока другая команда не завершит соответствующую работу со своей стороны. (см. Рисунок 4). И то и другое приводит к потерям в виде периода ожидания внутри потока ценности. Передачи и зависимости также могут привести к переделке, поскольку передача знаний может быть недостаточной, что приведет к дальнейшим задержкам.

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

Например, серия формальных передач внутри Agile команды или задержки в ожидании решений, которые будут приняты за пределами Релизного Поезда (Agile Release Train, ART). Такие мероприятия, как картирование потока создания ценности (Value Stream Mapping), ретроспективы и Мастерская Решения Проблем (Problem-Solving Workshop, входит в мероприятие Инспект-Адапт), могут помочь определить корневые причины и разработать потенциальные решения.

#4 Ускорение получения обратной связи (ранняя обратная связь)

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

Тем не менее, мы часто обнаруживаем, что получение ранней обратной связи может быть затруднено по целому ряду причин, например:

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

Быстрая обратная связь, как правило, достигается путем применения классического цикла обучения «Планировать-Делать-Проверять-Корректировать» (Plan-Do-Check-Adjust, PDCA). Однако мы обнаружили, что для существенного ускорения потока этого недостаточно, нужно делать еще больше, в том числе:

• Применять клиентоцентричность и дизайн-мышление в продуктовой разработке и часто взаимодействовать с клиентами
• Улучшать конвейер непрерывной доставки, включая автоматизацию сборки и тестирования, практики разработки на основе тестирования (test-first practices) и непрерывную интеграцию
• Сохранять разрабатываемые элементы небольшими, чтобы они быстрее приводили к работающим инкрементам ценности
• Использовать практики встраивания качества, моббинг, парную работу и «роение» (swarming) для повышения сплоченности команды и сосредоточения внимания на завершении работы «по одному элементу беклога за один подход»
• Поддерживать четкое определение выполненности (Definition of Done, DoD), чтобы команды могли совместно работать над созданием инкрементов ценности и делиться знаниями
• Быть в состоянии «останавливать весь конвейер» для немедленного устранения проблем при их возникновении

Как правило, разработчикам решения требуется два типа обратной связи от каждого цикла PDCA (рисунок 5):

1. Обратная связь о создании правильного продукта/решения. Эта обратная связь может исходить только от тех пользователей, клиентов и заинтересованных в экономических результатах стейкхолдеров, которые могут измерить фактическую ценность решения. Каждый цикл PDCA — это возможность для такого обучения. Это могут быть ранние макеты и карты историй, демонстрации системы, проводимые во время разработки, или обратная связь по пре-выпускам и развернутым системам в рабочей среде.
2. Обратная связь о правильности самой разработки продукта/решения. Инновационные системы постоянно раздвигают границы технологий и навыков разработчиков. Каждый цикл PDCA также оценивает, применяется ли правильная технология для оптимального решения проблем клиента и удовлетворения критически важных нефункциональных требований, которые характеризуют надежность и эффективность решения.

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

#5 Работа с малыми партиями

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

Экономически оптимальный размер партии зависит от стоимости хранения (стоимость задержки обратной связи, снижения ценности в связи с хранением, задержка доставки ценности и т. д.) и транзакционных издержек (стоимость подготовки и реализации всей партии). На рисунке 6 показана u-кривая оптимизации для размера партии [2].

Чтобы улучшить экономику обработки небольших партий, команды должны сосредоточиться на снижении транзакционных издержек, что приведет к увеличению пропускной способности. Уменьшение размера партии обычно связано с инвестициями в автоматизацию Конвейера непрерывной доставки (Continuous Delivery Pipeline, CDP), включая инфраструктуру и автоматизацию, непрерывную интеграцию, сборку, регрессионное тестирование и многое другое. Используйте более короткие итерации и Инкременты Программ, чтобы уменьшить размер партий.

#6 Уменьшение длины очереди

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

С точки зрения разработки решения, чем длиннее очередь из выполняемой работы, тем больше время ожидания новых фич независимо от эффективности команды. Например, предположим, что Agile Release Train имеет среднюю скорость потока 10 фич в квартал, при этом в беклоге находится 30 фич. В этом случае поезду придется ждать три квартала, прежде чем начнется разработка каких-либо новых фич.

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

#7 Оптимизация времени «в потоке»

«Быть в потоке» (также иногда называется «быть в состоянии потока») — это психическое состояние полного погружения и крайней сосредоточенности на какой-то деятельности, когда работа кажется легкой и не требует усилий, а время проходит быстро. Люди и команды «в потоке» демонстрируют более высокую креативность, производительность, счастье и личную реализацию. Чтобы войти в это психическое состояние, требуется время для достижения непрерывного фокуса, автономия, компетентность и тесная связь с коллегами-единомышленниками, чтобы раскрыть свой потенциал и внутреннюю мотивацию. [6]

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

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

#8 Исправление устаревших политик и практик

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

Существует много примеров таких устаревших практик. Ниже приведены некоторые из самых распространенных:

• Продолжающаяся зависимость от жестких этапов выполнения работ (phase-gate milestones) и железный треугольник в виде фиксированных требований, но переменных ресурсов и времени. В действительности все три компонента становятся фиксированными, а не компромиссами между ограничениями.
• Устаревшие или ненужные комитеты надзора за изменениями, включая внешние надзорные и контрольные органы.
• Водопадные системы управления качеством для соответствия регуляторным требованиям.
• Устаревшие технические стандарты — спецификации проектирования, методы аудита и тому подобное — в средах, где они не являются обязательными или не требуются для обеспечения качества.
• Продолжение ведения отчетов по использованию рабочего времени в дополнение к инструментам гибкого управления жизненным циклом (Agile Lifecycle Management, ALM), что требует двойного учета времени.
• Традиционные оценка эффективности сотрудников со стороны HR и компенсационная политика вызывают нездоровую внутреннюю конкуренцию и противоречия в части личных приоритетов.
• Agile внедряется только на уровне команд. Менталитет менеджмента и управление портфелем остаются без изменений.

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

Измерение потока

Трудно улучшить то, что не измеряется. Исторически сложилось так, что было непонятно как измерить процесс разработки, поскольку в нем рабочие элементы в основном неосязаемы и невидимы, они живут в основном в умах работников умственного труда, которые проектируют и разрабатывают системы. Но физика и инструментарий потока (ограничения по времени, Канбан, картирование потока создания ценности, конвейер непрерывной доставки, истории, фичи и многое другое) обеспечивают новую основу для измерений потока ценности, используя понятие разработческого потока создания ценности. (Перейти на статью «Метрики SAFe», где описываются шесть метрик для изменения потока: распределение, пропускная способность/скорость, время, загрузка, эффективность и предсказуемость) (см. рисунок 10).

• Распределение Потока измеряет количество рабочих элементов каждого типа в определенном потоке ценности. Это помогает поддерживать здоровый баланс между разработкой новых фич, с одной стороны, и сокращением технического долга, обслуживанием и другими техническими работами, с другой.
• Пропускная способность (скорость) потока измеряет среднее количество выполненных элементов работы (истории, фичи, возможности/капабилити, эпики), и показывает ёмкость команды для доставки ценности, помогая прогнозировать будущие доставки.
• Время Потока измеряет, сколько времени требуется рабочему элементу для прохождения через систему. Это помогает командам прогнозировать, когда новая ценность станет доступной, и помогает выявлять задержки в процессе.
• Загрузка Потока измеряет общий объем незавершенной работы в системе. Это помогает команде оптимизировать пропускную способность, ограничивая спрос реально доступной емкостью.
• Эффективность потока измеряет, сколько от общего времени потока тратится на действия по добавлению ценности по сравнению с ожиданием между шагами. Это помогает выявлять узкие места, передачи и зависимости.
• Предсказуемость потока обобщает способность команд достичь цели Инкремента Программы (PI). Если предсказуемость низкая, это признак того, что риски или препятствия должны быть устранены.

Вместе эти метрики обеспечивают комплексное представление того, как новая ценность проходит через разработческий поток создания ценности. Важно, чтобы эти показатели относительно просто можно было собирать и поддерживать в актуальном состоянии. Они также должны быть видимыми. Все это вместе делает метрики ценными, полезными и практически применимыми. К счастью, их можно автоматизировать с помощью большинства современных инструментов Agile Lifecycle Management (ALM). Кроме того, организации должны сочетать метрики потока с данными, измеряющими клиентские качества создаваемой ценности, чтобы гарантировать, что поток доставки создает правильные решения для клиентов и тогда, когда это необходимо по времени.

Заключение

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

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом.

[1] Womack, James P., and Jones, Daniel T. Lean Thinking: Banish Waste and Create Wealth in Your Organization. Free Press, 2003.

[2] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.

3] Goldratt, Eliyahu M. The Goal: A Process of Ongoing Improvement. The North River Press Publishing Corporation, 1986

[4] Oosterwal, Dantar P. The Lean Machine. AMACOM, 2010

[5] Ward, Allen, and Durward Sobeck. Lean Product and Process Development. Lean Enterprise Institute, 2014.

[6] Csikszentmihalyi, Mihaly. Flow. HarperCollins, 1990

[7] Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018.

Дополнительно почитать другие статьи из цикла:

Статья «Ускорение Потока с  помощью SAFe»

Статья «Управление Потоком Создания Ценности»

Статья «Поток Портфеля»

Статья «Поток Поезда»

Статья «Поток Команды»

Статья «Коучинг потока в организации»