Поток Поезда (ART Flow)
Поток Поезда — это состояние, при котором Релизный Поезд (Agile Release Train, ART) непрерывно доставляет клиентам ценные фичи.
Для реализации 6-го принципа — «Обеспечить непрерывный поток ценности» — SAFe выделяет восемь ускорителей потока. Задача ускорителей — оптимизировать процесс и устранять препятствия, чтобы непрерывно доставлять ценность клиентам.
В этой статье описывается, как ускорить поток ценности на уровне Релизных Поездов, применив восемь ускорителей потоков.
#1 Визуализация и ограничение незавершенной работы (НЗР, WIP)
Почему это важно?
Чрезмерное количество одновременно выполняемой работы (незавершенная работа, НЗР, WIP) значительно снижает производительность Релизного Поезда (Agile Release Train, ART) и препятствует потоку ценности. Незавершенная работа перегружает людей и команды, вносит путаницу в приоритеты и вызывает частое переключение контекста. В результате новая функциональность долго доставляется до клиентов.
Agile Release Train обычно делает все, что в его силах, чтобы выполнить запланированную работу. Тем не менее, на практике часто встречается, что что у поезда запланировано намного больше, чем он может выполнить за ограниченный промежуток времени. Эта практика является контрпродуктивной, так как перегруженный ART на практике выполняет меньший объем работы, чем мог бы выполнить при ограничении НЗР (WIP).
Что делать?
- Визуализировать все фичи, которые взяты в работу. Agile Release Train должен управлять «инвентаризацией» всех фич, уже находящихся в разработке. Все фичи должны быть зафиксированы в Канбан системе Беклога Поезда c установленными ограничениями на количество незавершенной работы.
- Контролировать WIP с помощью аллокации ёмкости. Не все работы поезда связаны с разработкой фич. Количество всей незавершенной работы для ART включает в себя как работы, связанные с текущей разработкой фич, так и другие работы, которые выполняет поезд: исследования, инфраструктура, инструментарий, реализация элементов улучшений и многое другое. Легко недооценить время, которое уходит на выполнение другой важной работы, не связанной с разработкой. Чтобы определить общий WIP, предварительно установите распределение емкости между разработкой бизнес-фич ART и другой работой. Со временем внесите корректировки, если необходимо.
#2 Устранение узких мест
Почему это важно?
Узкие места ограничивают производительность всего поезда, поэтому команды должны бороться с ними для улучшения потока. Как только одно «бутылочное горлышко» устранено, возникает новое, для которого также нужно найти решение для повышения производительности потока. Это непрерывный процесс.
Что делать?
- Определить узкое место. Agile Release Train может устранить только те узкие места, о которых он знает. Некоторые «бутылочные горлышки» могут быть выявлены в ходе PI Планирования; другие возникают уже во время выполнения Интервала Планирования (PI) или проведения мероприятия «Inspect & Adapt».
Характерные признаки узкого места:
— Перегруженность одной команды или группы команд
— Частое (неоднократное) отставание по срокам выполнения какого-то действия от одной итерации к другой (например, интеграция, тестирование, развертывание, рефакторинг)
— Задержка в выполнении определенных типов зависимостей
Метрики и инструменты SAFe, такие как Картирование Потока Ценности (Value Stream Mapping), Доска Планирования (Planning Board) и Канбан система Релизного Поезда (ART Kanban), могут помочь выявить узкие места.
- Оценить влияние узкого места в целом на поток ценности. Agile Release Train должен понимать, как его текущие узкие места влияют на поток ценности. Примеры: 1) Медленная обратная связь от клиентов может привести к тому, что ART создаст неправильную функциональность решения, что повлечет за собой значительную переработку и неудовлетворенность; 2) Устаревшая архитектура системы значительно замедляет процесс разработки и делает его менее предсказуемым.
- По возможности увеличить ёмкость в узком месте. Как только проблема выявлена, очевидным решением является увеличение ёмкости в узком месте. Примеры: 1) при недостаточном количестве front-end разработчиков ART может привлечь больше таких специалистов; 2) в случае плохой архитектуры ART может выделить больше времени для сокращения технического долга.
- Обходить узкое место. Далеко не всегда возможно быстро увеличить ёмкость в «бутылочном горлышке», так как могут быть недоступны дополнительные люди и ресурсы. В краткосрочной перспективе наиболее продуктивным может быть избегание этого узкого места. Примеры: 1) взять в работу следующую наиболее ценную фичу, которая не имеет зависимостей; 2) вместо крупномасштабного архитектурного улучшения устаревшей системы — ускорить вывод системы из эксплуатации.
#3 Минимизация передач и зависимостей
Почему это важно?
«Передача» информации и работы происходит, когда элемент работы переходит от одного шага рабочего процесса к другому. А когда для выполнения какой-то работы необходим конкретный специалист или уникальные знания и навыки какого-то другого человека или команды, возникает зависимость. Безусловно, в крупной организации какие-то передачи и зависимости неизбежны, однако чрезмерные и ненужные зависимости и передачи препятствуют потоку.
Что делать?
- Использовать Доску Планирования Релизного Поезда (ART) для визуализации зависимостей. Доска планирования ART помогает отслеживать существенные зависимости между командами и оптимизировать выполнение работ в рамках всего Интервала Планирования. Доска по возможности корректируется по мере появления новых зависимостей.
- Содействовать инкрементальному выполнению зависимостей. Передача большого элемента работы от одной команды к другой чревата неопределенностью, переделками и задержками. Вместо этого зависимости часто можно разделить на более мелкие, более управляемые элементы. Такой подход ведет к частой интеграции между командами, упреждающему обнаружению проблем и несоответствий, а также более предсказуемому и быстрому процессу.
- Часто синхронизироваться. Мероприятие «Синхронизация Поезда» (ART Sync) отлично подходит для синхронизации зависимостей и передач внутри поезда. Кроме того, ART Sync позволяет командам напрямую общаться и обсуждать детали разработки.
- Оптимизировать структуру команд. Чрезмерные зависимости и передачи часто указывают, что некорректно выстроена топология поезда. Чтобы уменьшить количество зависимостей, создавайте кросс-функциональные, междисциплинарные Agile команды и применяйте топологии команд.
- Визуализировать зависимости с внешними поставщиками и управлять ими. У ART передачи и зависимости могут быть как внутренними, так и внешними с другими ART и внешними организациями. Такие элементы также должны быть идентифицированы, и после этого отслеживаться и управляться.
#4 Ускорение получения обратной связи
Почему это важно?
Разработка решения опирается на быструю обратную связь, которая направляет ART и позволяет «не сбиться с пути». Когда обратная связь задерживается или отсутствует, ошибки быстро накапливаются. Это в свою очередь приводит к существенным доработкам для команд, медленной доставке ценности и неудовлетворенности клиентов.
Как показано на рисунке 1, обычно требуется два типа обратной связи:
- Создает ли Agile Release Train решение, которое действительно нужно Заказчику?
- Правильно ли разрабатывает ART это решение?
Рисунок 1. Создаем нужное решение и разрабатываем его правильно
Что делать?
- Получать оба типа обратной связи. Постоянное взаимодействие с клиентами — это единственный способ гарантировать, что ART создает правильное решение. Кроме того, обратная связь может подтвердить поезду, что технология жизнеспособна и что решение соответствует ожиданиям по качеству. Это тестирование должно быть непрерывным и соответствовать функциональным и нефункциональным требованиям (NFR).
- Обеспечить телеметрию решения. Телеметрия приложения может собирать ценные данные об использовании системы и ее поведении. Для того, чтобы получать такие измерения, необходимо заранее запланировать и реализовать энейблеры для конкретного приложения и контекста.
- Взаимодействовать с клиентами как можно раньше и чаще. При каждой возможности демонстрируйте продукт клиенту. По возможности дополнительно тестируйте новые демоверсии функционала.
- Часто интегрировать и тестировать. Интеграция необходима между Agile-командами поезда и внутри самих команд. Совместно с автоматизацией тестирования интеграция является самым быстрым и продуктивным способом убедиться в том, что разработка продвигается в правильном направлении.
- Использовать исследовательские спайки и MVP. Спайки и Минимально Жизнеспособные Продукты (MVP) являются примерами проверки намерений и экспериментов с дизайном. Они помогают быстро получить ценную информацию о клиенте и решении.
#5 Работа с малыми партиями
Почему это важно?
Работа с большими партиями приводит к ухудшению качества, задержкам в получении обратной связи, доработкам и высокой вариативности.
Что делать?
- Определить типы партий и их размеры. Различные потребности разработки создают разные типы партий: планирования, интеграции, тестирования, релиза, обратной связи от клиентов и т. д. Для каждого типа партий должен быть определен оптимальный размер, чтобы свести к минимуму общую сумму расходов, включающую в себя транзакционные затраты и стоимость хранения.
- Использовать каденцию. Каденция ART естественным образом ограничивает количество используемых основных типов партий. Соблюдение рекомендуемой продолжительности итерации и Интервала Планирования помогает в планировании, интеграции и получении обратной связи от клиентов, а также позволяет сохранить небольшой размер партии.
- Управлять размером команды и ART. Следование рекомендуемому размеру Agile команд и ART также уменьшает размер партий.
• Автоматизировать конвейер доставки. Эффективный Конвейер Непрерывной Доставки (CDP) сокращает размер оптимальной партии для интеграции, тестирования и развертывания. - Планировать более мелкие партии. Уменьшению размера партии могут способствовать непосредственные установки самого процесса планирования. Например, планирование конкретных, частых выпусков может помочь контролировать партию релизов.
- Использовать тонкие вертикальные срезы работы. Тонкие вертикальные срезы могут уменьшить размер большинства партий. То же самое можно сказать и о более мелких и более управляемых фичах. Взятие в работу меньшего количества фич в каждой итерации также уменьшает размер партий.
#6 Уменьшение длины очереди
Почему это важно?
Очередь в беклоге ART содержит все работы над фичей, за выполнение которых команды взяли на себя ответственность. Чем длиннее очередь, тем дольше клиент будет ожидать появление нового функционала.
Что делать?
- Иметь гибкие дорожные карты. Зафиксированная на долгосрочную перспективу дорожная карта является примером длинной очереди. Несмотря на то, что некоторые вехи должны быть зафиксированы, дорожная карта должна сохранять гибкость дат и объема работ, когда это возможно. Это позволяет ART реагировать на изменения рынка и новые знания, которые появляются в процессе разработки.
- Создать сильную команду по управлению продуктом. Часто очереди возникают из-за того, что организация не может сказать «нет» и не может эффективно расставить приоритеты в работах. Менеджеры Продукта должны проявлять твердость в управлении объемом работ, которые демонстрируются во время PI Планирования, выполнения Интервала и мероприятия «Инспект-Адапт» (Inspect & Adapt).
- Оставлять резерв ёмкости для неожиданно возникающих задач. ART может планировать только ту работу, о которой он знает до начала планирования. В ходе реализации какие-то работы потребуют дальнейшего изучения или будут зависеть от будущих событий на рынке. Другие события могут произойти неожиданно. В качестве меры предосторожности выделите резервную ёмкость, чтобы команды могли включить в план работ неожиданно возникшие задачи.
#7 Оптимизируйте время «в потоке»
Почему это важно?
Разработка решения в значительной степени зависит от креативности, фокуса внимания и интеллектуальных усилий членов команды. Например, работая над какой-то новой фичей, разработчики и целые команды могут столкнуться с огромным количеством зависимостей между различными системами. Для работы над таким комплексным решением потребуется высокая степень сосредоточенности на протяжении длительного времени, то есть специалисты должны находиться «в состоянии потока». Оптимизация времени, проводимого в потоке, как для отдельных сотрудников, так и для всей команды существенно влияет на продуктивность ART.
Что делать?
- Уменьшить количество незавершенной работы. Слишком большой объем незавершенной работы (WIP) часто приводит к частому переключению контекста. Меньшее количество активных элементов в каждый момент времени означает меньше прерываний в работе.
- Часто интегрировать работу. Регулярная интеграция между командами позволяет быстро устранять несоответствия и проблемы. В противном случае они накапливаются и приводят к тому, что команды с зависимостями часто прерывают друг друга, а затем вынуждены возвращаться к предыдущей работе.
- Поддерживать работоспособность («здоровье») решения. Если команды не будут постоянно устранять технический долг, они будут тратить слишком много времени на погоню за неоднозначными зависимостями и вновь созданными дефектами.
- Проводить эффективные мероприятия. Постоянно оптимизируйте все события для повышения производительности команды, особенно PI Планирование, Демонстрации систем и Инспект-Адапт.
#8 Исправление устаревших политик и практик
Почему это важно?
Устаревшие политики и методики тормозят поток доставки ценности для клиентов и разрушительны для использования новых подходов и практик. И это касается не только команд. Учитывая, что ART доставляют основную экономическую ценность решений и потребляют большую часть инвестиций в R&D, они, несомненно, привлекут большое внимание со стороны ключевых заинтересованных лиц. И, к сожалению, некоторые из этих заинтересованных лиц, возможно, не участвовали в Lean-Agile трансформации, поэтому они могут неосознанно препятствовать потоку.
На что обратить внимание?
Первый шаг – знать, что эти препятствия, скорее всего, существуют. Во-вторых, распознавать их, когда они возникают.
К распространенным препятствиям относятся:
- Традиционное управление проектами и программами (EVM, WBS, IMS, учет затрат по проекту), помимо Agile практик, которые применяют команды
- Системы качества и модели управления, содержащие встроенные водопадные контрольные точки (этапы работ)
- Фиксированный объем работ и жесткие сроки, которые устанавливались без вводной информации от людей, которые будут выполнять работу
- Избыточные встречи по отчетности и выпуску с пересекающимися повестками дня и участниками
- Отделение продуктового дизайна, архитектуры и UX от ART и потоков создания ценности
- «Замораживание» активов (кода) для предотвращения внесения необходимых изменений, в которых нуждаются клиенты
- Медленная и неэффективная подготовка необходимых инструментов и рабочих сред
- Действия по верификации и валидации, а также соответствию требованиям проводятся однократно в самом конце
Что делать?
После выявления устаревших политик команды должны принять корректирующие меры. Однако действия по их устранению уже зависят от конкретных заинтересованных лиц и определяются характером и контекстом препятствий. Агенты изменений часто сталкиваются с тем, что многие из этих заинтересованных лиц не участвовали в трансформации и нуждаются в дополнительном обучении и коучинге. Ни одна трансформация не будет завершена до тех пор, пока изменения не будут полностью внедрены в культуру. При этом даже после окончания трансформации следует регулярно пересматривать политики и методики на предмет их устаревания.
Измерение потока ART
Измерение потока имеет решающее значение для улучшения потока ART. Система «Измерение и Развитие (Measure and Grow)» в SAFe определяет три категории измерений — компетенция, поток и результаты. С их помощью можно измерить и улучшить способность предприятия быстро доставлять инновационные бизнес-решения. Эта система измерения включает в себя шесть показателей, характерных для потока: распределение потока, пропускная способность (скорость), время, загрузка, эффективность и предсказуемость. Все 6 метрик важны для потока ART, но предсказуемость, время и загрузка оказывают на него наибольшее влияние.
Предсказуемость потока ART (ART Flow Predictability)
Предсказуемость Потока ART измеряет, насколько хорошо поезд может планировать и достигать своих целей PI. Для того, чтобы бизнес мог эффективно планировать и осуществлять бизнес-деятельность, Agile Release Train, как правило, должен выполнить большинство своих целей с обязательствами и одну или несколько целей без обязательств. В результате в среднем выполняется 80-100% от общего запланированного объема работ. На рисунке 2 показан пример, когда ART придерживается достаточно консервативного подхода к своим обязательствам по Интервалу Планирования, поскольку средняя предсказуемость регулярно превышает 100%. Чтобы набрать больше 100 %, командам необходимо выполнить свои цели с обязательствами и без.
Рисунок 2. Пример предсказуемости потока ART
Время потока ART
Время потока ART измеряет общее время, затраченное на доставку новых фич. Обычно время рассчитывается от появления идеи до выпуска в производственную эксплуатацию. На рисунке 3 показан пример с достаточно стабильным средним временем потока, равным примерно 36 дням. Резко отклоняющиеся показатели являются распространенным явлением. Они могут указывать на фичи, заблокированные из-за внешних зависимостей, непредвиденных рисков или других факторов.
Рисунок 3. Пример времени потока одного ART
Загрузка потока ART (ART Flow Load)
Загрузка потока ART измеряет общий объем работы в системе в любой точке. Часто загрузка демонстируется в виде диаграммы, основанной на состояниях Канбан системы ART, как показано на рисунке 4.
Рисунок 4. Пример загрузки потока ART
Эта диаграмма иллюстрирует резкое увеличение НЗР для рассматриваемого Agile Release Train. Для того, чтобы разобраться, почему это происходит, потребуется знание контекста этого поезда. Например, ART действительно может быть перегружен НЗР, или, возможно, размер поезда значительно увеличился, и тогда увеличение НЗР просто отражает измененный увеличенный размер поезда.
Эффективность потока ART (ART Flow Efficiency)
Эффективность потока — это сумма активного времени, деленная на общее время, необходимое для прохождения элемента работы через систему. Эффективность потока может быть очень низкой в системе, которая не была оптимизирована. В этом случае элемент беклога проводит большую часть времени в системе в состоянии «ожидания действия». Отправной точкой для понимания эффективности потока является разработка карты потока создания ценности и оценка (или сбор фактического времени), сколько времени элемент бэклога проводит в различных состояниях процесса.
В качестве примера рассмотрим карту потока создания ценности, показанную на рисунке 5. Карта взята из реального упражнения по отображению потока создания ценности DevOps. На рисунке видно, что эта система крайне неэффективна, с эффективностью потока в 5%. Также можно заметить, что почти все время ожидания приходится на один конкретный шаг. Этот шаг является «бутылочным горлышком» и тормозит процесс. Работа над повышением эффективности на других шагах не принесет большой экономической отдачи. Для повышения эффективности ART должен устранить узкое место, и когда это произойдет, время потока также должно резко сократится.
Рисунок 5. Пример эффективности потока ART, полученный на основе картирования потока создания ценности
Резюме по Метрикам Потока
Метрики Потока в SAFe помогут выявить возможности для улучшения потока Agile Release Train. Тем не менее, одни только цифры не могут показать всю картину. Необходимо провести качественный анализ и не забывать про здравый смысл.
Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «ART Flow».
Дополнительно почитать:
Статья «Как обеспечить непрерывное движение ценности?»
Статья «Метрики в SAFe»
Статья «Поток Команды»