Что такое Agile Release Train — в теории SAFe® и на практике российских компаний

Вольный перевод статьи: Agile Release Train — Scaled Agile Framework® — а также примеры ART в российских компаниях.

Agile Release Train

Чем больше у вас согласованности, тем больше автономии вы можете себе позволить. Первое обеспечивает второе. © Стивен Бангей, автор и консультант по стратегии

Agile Release Train (далее — ART или поезд) согласовывает команды вокруг общей бизнес- и технологической миссии. Каждый поезд представляет собой виртуальное подразделение (обычно 50-125 человек), которое совместно планируется, берет обязательства, разрабатывает и развертывает. ART организованы вокруг ключевых потоков создания ценности компании (Development Value Streams) и существуют исключительно для ее доставки путем создания Решений, которые приносят пользу конечному потребителю.

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

Поезда придерживаются общих принципов:

• Определенное расписание — поезд отправляется со станции по известному и четкому расписанию с заранее определенным интервалом — Инкремент Программы (Program Increment, PI). Если Фича (Feature) пропустила запланированный отъезд и не вошла в текущий PI, тогда она может попасть в следующий.

• Новый инкремент системы каждые 2 недели — каждый поезд производит новое приращение функциональности (инкремент) системы каждые 2 недели. Системная Демонстрация (System Demo) обеспечивает механизм оценки работающей системы, которая является интегрированным инкрементом всех команд.
• Синхронизация — все команды поезда синхронизированы одинаковой продолжительностью PI (обычно 8–12 недель) и общими датами и продолжительностью начала и завершения Итераций.
• Известная производительность — каждый ART может уверенно оценить объем груза (новых Фич), который может быть доставлен за PI.

• Agile-команды — Agile-команды придерживаются Agile-манифеста разработки программного обеспечения, Ключевых Ценностей и принципов SAFe. Они применяют Scrum, Экстремальное Программирование (Extreme Programming, XP), Kanban, а также практики Встроенного Качества (Built-In Quality).
• Выделенные сотрудники — большинство людей, необходимых ART, посвящают все свое время поезду, независимо от их функциональной структуры подчиненности.

• PI-планирование лицом к лицу — ART периодически планирует свою работу преимущественно в формате лицом к лицу на сессии PI-планирования (PI Planning).

• Инновации и Планирование — IP-итерация (Innovation and Planning Iteration, IP Iteration) происходит в конце каждого PI и обеспечивает выделенное время для PI-планирования, инноваций, непрерывного обучения и работы с инфраструктурой.
• Инспекция и Адаптация — сессия Инспекции и Адаптации (Inspect and Adapt, I&A) проводится в конце каждого PI. Проводится демонстрация и оценка текущего состояния решения, затем команды и руководство на сессии разрешения проблем определяют работы по улучшению.
• Разработка Каденциями, Релиз по Потребности — ART применяет каденции и синхронизацию, чтобы упростить управление изменчивостью в процессах исследования и разработки. Однако, процесс релиза обычно отделяется от каденций разработки. ART может выполнить релиз решения или некоторых его элементов в любое время.

Кроме того, в больших потоках создания ценности несколько ART могут сотрудничать между собой для создания более крупных решений, образуя Solution Train. Некоторые заинтересованные лица ART участвуют в мероприятиях Solution Train, таких как Предварительное и Заключительное PI-планирование (Pre- and Post-PI Planning) и Демонстрация Решения (Solution Demo).

Организация вокруг ценности

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

• поставка ценности замедляется из-за необходимости передачи информации и задержек;
• политика препятствует сотрудничеству;
• колодцы способствуют географическому распределению;
• коммуникация через колодцы затруднена.

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

Вместо этого ART применяет системное мышление (принцип SAFe №2) и организацию вокруг ценности (принцип SAFe №10) для построения кросс-функционального подразделения, оптимизированного для ускорения потока ценности от идеи до развертывания, релиза и эксплуатации.

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

Agile-команды — вагоны поезда

Поезда состоят из команд, которые определяют, создают и тестируют Фичи, а также развертывают, обновляют и эксплуатируют решение. Команды применяют Agile-процесс —  обычно это Scrum, XP и Kanban. Каждая Agile-команда включает 5-11 выделенных специалистов всех ролей, которые необходимы для создания качественного прироста ценности после каждой итерации. Команды бывают технологическими, разрабатывающими программное и аппаратное обеспечение, или бизнесовыми. В каждой Agile-команде есть две специальные роли: Scrum-мастер (Scrum Master) и Владелец Продукта (Product Owner). И, конечно же, Agile-команды внутри ART сами по себе являются кросс-функциональными.

Как ART, так и Agile-команды этого ART должны быть организованы вокруг ценности. Иначе невозможно обеспечить непрерывность потока ценности, ведь команды утонут в управлении взаимными зависимостями.

Для упрощения дизайна команд SAFe предлагает четыре типа команд:

1. Потоковая команда (Stream-aligned team) – организована вокруг потока работ и способна доставлять ценность непосредственно клиенту или конечному пользователю.
2. Команда сложной подсистемы (Complicated subsystem team) – организована вокруг определенной подсистемы, требующей глубоких специальных навыков и экспертизы.
3. Платформенная команда (Platform team) – организована вокруг разработки и поддержки платформы, которая предоставляет сервисы другим командам.
4. Вспомогательная команда (Enabling team) – организована для поддержки других команд специализированными возможностями и помощи в овладении новыми технологиями.

При формировании ART и команд полезно визуализировать типы команд. Потоковые команды показываются ​​стрелками, что отражает поток. Квадрат – команда сложной подсистемы. Вытянутый прямоугольник – команда платформы. Пунктирный эллипс – вспомогательная команда. Можно добавить названия конкретных команд, чтобы получить более полную картину. Визуализация всей картины целиком и порядка команд позволяет отобразить все возможные взаимодействия между командами. Сравнивая несколько таких опциональных дизайнов команд: плюсы и минусы каждого — можно выбрать оптимальный дизайн, который максимально соответствует цепочке поставки ценности.

Подробнее про топологии команд читайте в статье Масштабирование по SAFe®: как собрать АRT из команд разных типов.

Ключевые роли поезда

Успешное выполнение работ в ART опирается на следующие роли:

• Release Train Engineer (RTE) — это лидер-слуга, который фасилитирует события ART, способствует устранению препятствий, управлению рисками и зависимостями, а также постоянному совершенствованию.

• Продуктовый Менеджмент (Product Management) — отвечает за вопрос: что должно быть сделано — в соответствии с Концепцией (Vision), Дорожной Картой (Roadmap) и новыми Фичами в Бэклоге Программы (Program Backlog). Совместно с Владельцами Продуктов они выявляют потребности клиентов.
• Системный Архитектор/Инжиниринг (System Architect/Engineering) — специалист или команда, которая определяет общую архитектуру системы. Они определяют нефункциональные требования (Non-functional Requirements, NFR), ключевые элементы системы, подсистемы и интерфейсы.
• Представители Бизнеса (Business Owners) — ключевые заинтересованные лица ART, которые несут ответственность за бизнес-результаты поезда.
• Клиенты (Customers) — конечный выгодоприобретатель Решения.

Дополнительные функции ART:

• Системная Команда (System Team) — настраивает и поддерживает непрерывную интеграцию и тестовые окружения.
• Общие Сервисы (Shared Services) — специалисты, к примеру, безопасность, архитекторы, администраторы баз данных, которые необходимы для успеха ART, но не могут быть его членами на постоянной основе.

Описание поезда

Параметры и границы ART, заинтересованные лица и связь с потоками создания ценности могут быть зафиксированы с помощью канваса ART.

Синхронизация команд

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

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

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

Непрерывная поставка и DevOps

ART стремится постоянно приносить ценность клиентам. Эта цель обеспечивается за счет Конвейера Непрерывной Поставки (Continuous Delivery Pipeline). Эти процессы проходят одновременно и непрерывно при использовании DevOps.

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

• Непрерывное Изучение (Continuous Exploration) — процесс постоянного изучения потребностей рынка и пользователей, а также определения Концепции, Дорожной Карты и Фич, которые призваны удовлетворить эти потребности.
• Непрерывная Интеграция (Continuous Integration) — процесс разработки, тестирования, интеграции и проверки в промежуточной среде Фич из Бэклога Программы, после которого они готовы к развертыванию и релизу.
• Непрерывное Развертывание (Continuous Deployment) — процесс развертывания проверенных фич из промежуточного окружения в промышленное, где они проверяются и готовы к релизу.
• Релиз по Потребности (Release on Demand) — процесс доставки ценности конечным пользователям, а также проверки гипотез и извлечения уроков.

Разработка и управление Конвейером Непрерывной Поставки поддерживается практиками и культурой DevOps в каждом ART.

Визуализация, измерение и управление потоком задач всей системы производится с помощью Kanban Программы.

Большие и маленькие поезда

ART определяет, кто будет формировать планы и работать вместе, а также какие продукты, сервисы, Фичи или компоненты будет поставлять этот поезд.

Эффективные ART обычно объединяют от 50 до 125 человек. Верхний предел основан на числе Данбара — это максимальное количество людей, с которыми можно эффективно и стабильно поддерживать социальные связи. Нижний предел основан главным образом на практике применения.

Существует два типовых дизайна ART:

• Небольшие решения может поддерживать один ART.
• Большие решения — несколько ART.

Крупные компании для больших решений используют элементы и практики уровня Large Solution SAFe, собирая Solution Train, который упрощает координацию поездов и внешних поставщиков между собой.

Подробнее про дизайн поездов читайте в статье Безжалостное непрерывное улучшение оргструктуры по SAFe.

Примеры российских компаний

Азбука вкуса — Ритейл

Текущая оргструктура была выбрана изначально для запуска кросс-функциональных команд для e-com – первый ART для электронной коммерции и программы лояльности. Затем появился второй ART для всех процессов, связанных с продажами в офлайн-канале, а также всех Change-процессов, связанных с разработкой. © Айсылу Абдалова, Директор по трансформации и Agile-развитию, Азбука вкуса

Ак Барс Банк — Финансы

На данный момент мы работаем ART по каналам и продуктам. Это продиктовано структурой бизнеса, под которую выровнены ART на соответствующую дирекцию. Но сейчас смещаем фокус на взаимоотношение с клиентом, формируем новые ART по ценностям для клиента (UJM/CJM). ART становятся более крупными. © Александр Киверин, Технический директор, Ак Барс Цифровые Технологии (Ак Барс Банк)

Xsolla — ИТ

В 2019 году было решено настроить 3 поезда, по числу существующих бизнес-направлений. Каждый из них работал с одним или двумя этапами воронки AARRR. В эти 3 поезда мы загрузили 10 продуктовых команд. По прошествии 10 инкрементов мы перенастроили поезда, переместив 20 продуктовых команд в 4 новых value chains. Сейчас меняем процессы и архитектуру с тем, чтобы уменьшить количество зависимостей между командами. © Александр Сайфуранов, Director of R&D, VP, Xsolla Inc.

Smart Consulting — Госсектор

В своей деятельности выделяем два потока: продукты и проекты/контракты. Почти все наши ART строятся из потоковых команд (Stream-Aligned Teams) и активно дополняются общими сервисами (Shared Services) в зависимости от потребности в текущий момент. Сейчас собираем ART вокруг продуктов/проектов (на 1-2 PI) и смотрим в новую логику построения ART на основе карты клиентского пути (Customer Journey Map, CJM). © Станислав Мерзляков, Технический директор, Smart Consulting

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