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

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

Gene Kim et al., The DevOps Handbook

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

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

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

В центре внимания этой статьи находится пункт 3, который также является Принципов №6 фреймворка. Далее в статье мы рассмотрим, как обеспечить непрерывное движение ценности. SAFe вводит 8 ускорителей потока, которые позволяют улучшить поток на каждом уровне SAFe организации.

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

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

Рисунок 1. Восемь свойств системы потока

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

1. Незавершённая работа (НЗР, WIP, иногда называется «Работа в процессе»). В системе всегда есть какая-то незавершённая работа; если бы её не было, не могло бы быть и потока ценности.
2. Узкие места.  В каждой системе потока одно или несколько узких мест ограничивают прохождение потока через всю систему.
3. Передачи («из рук в руки»). Не было бы необходимости в передачах, если бы один человек мог выполнять всю работу самостоятельно. Но в любой системе материальных потоков разные люди и команды имеют разные навыки и обязанности. Каждый из них играет свою роль в перемещении элементов работы по системе.
4. Обратная связь. Обратная связь от клиентов и заинтересованных лиц является неотъемлемой частью эффективных и действенных результатов. В идеале обратная связь должна происходить на протяжении всего процесса.
5. Партия. Поскольку любая система имеет конечную ёмкость, вся работа не может быть выполнена сразу. Поэтому работа через систему проходит партиями, которые составляются с целью получения максимально возможной эффективности.
6. Очередь. Все начинается с набора элементов работы, которые необходимо выполнить. Кроме того, для каждого потока ценности необходим механизм расстановки приоритетов, чтобы упорядочить работу для достижения наилучшей ценности.
7. Работник. Люди выполняют важную работу по перемещению и преобразованию элементов работы из одного состояния в другое.
8. Политики. Политики являются неотъемлемой частью потока. Это могут быть локальные политики, такие как политики команды, которые определяют, как элемент работы перемещается от одной стадии к другой, или глобальные политики, подобные тем, которые регулируют, как выполняется работа в компании.

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

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

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

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

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

Рисунок 2. Kanban доски делают видимым излишний объём незавершённой работы (WIP)

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

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

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

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

Рисунок 3. Узкие места тормозят прохождение ценности через поток создания ценности

Процессы, находящиеся выше по течению (раньше), заблокировали движение ценности. Процессы, находящиеся ниже по течению, «голодают» и ждут. Другими словами, узкие места заставляют поток ценности работать медленно и нерентабельно, намного ниже ее потенциальной ёмкости. Это подчеркивается в Теории ограничений Голдратта [2], [3], которая утверждает, что пропускная способность любой системы потока ограничена пропускной способностью узкого места. Согласно этой теории, инвестиции в оптимизацию системы в любой другой точке, а не в узком месте, являются пустой тратой времени, так как это не улучшит пропускную способность системы в целом.

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

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

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

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

Рисунок 4. Чрезмерные передачи и зависимости становятся видимыми на доске планирования Поезда (ART)

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

Например, серия формальных передач внутри 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):

Рисунок 5: Каждый цикл PDCA собирает два вида обратной связи

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

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

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

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

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

Рисунок 6. U-образная кривая для нахождения оптимального размера партии

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

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

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

Рисунок 7. Длинные очереди замедляют обслуживание и поток; Закон Литтла определяет среднее время ожидания.

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

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

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

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

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

Рисунок 8. Время «в потоке» часто занимает небольшое количество времени от общего рабочего дня.

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

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

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

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

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

Рисунок 9. Лабиринт устаревших политик и практик.

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

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

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

Рисунок 10. Метрики потока в SAFe

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

Вместе эти метрики обеспечивают комплексное представление того, как новая ценность проходит через разработческий поток создания ценности. Важно, чтобы эти показатели относительно просто можно было собирать и поддерживать в актуальном состоянии. Они также должны быть видимыми. Все это вместе делает метрики ценными, полезными и практически применимыми. К счастью, их можно автоматизировать с помощью большинства современных инструментов 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] Goldratt, Eliyahu M. The Goal: A Process of Ongoing Improvement. The North River Press Publishing Corporation, 1986

[3] Goldratt, E. M. What is this Thing called Theory of Constraints and How should it be Implemented? North River Press, Inc, 1990

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

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

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

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

[8] 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»

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

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

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

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

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

Статья «Метрики SAFe»