Быстрый старт в SAFe® #5 – Cобытия и динамика Аgile Release Train
Дата: 01.02.2024
Пятая заключительная статья серии «Быстрый старт в SAFe®». В этом обзоре Scaled Agile Framework® (SAFe®) изучаем взаимодействие внутри Agile Release Train: как работает ART, ключевые роли и события синхронизации для обеспечения поставки по требованию.
Динамика и события ART
Каждый участник или заинтересованные лица Agile Release Train (ART) играют активную роль и имеет право голоса в ART. Вы получите базовые знания о событиях, уникальных ролях и динамике ART.
Agile Release Train
Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.
Вот несколько общих принципов, которым следует ART:
- ART, как поезда в железнодорожных перевозках, следует синхронизированному фиксированному расписанию.
- Фиксированное расписание – ART использует временной интервал (PI – Planning Interval, Интервал планирования) от 8 до 12 недель, что соответствует 4-6 итерациям. Расписание фиксировано, поэтому, если Фича «не успевает на поезд», ART доставляет ее в следующем PI. Аналогичным образом, новые Фичи планируются для следующих PI и не добавляются в план в середине PI.
- Двухнедельные системные инкременты – каждый ART поставляет инкремент каждые 2 недели. Команды демонстрируют ценность, которую они разработали на Системной демонстрации. Системная демонстрация – это механизм оценки работающего решения.
- Синхронизация – команды придерживаются одинаковой частоты и продолжительности временных интервалов для итераций в PI. Даты начала/окончания PI и итераций одинаковы для всех команд в поезде.
Организация вокруг ценности
Ничто не сравнится с Agile-командой, за исключением команды Agile-команд, работающих над достижением общей цели.
Дин Леффингвелл
ART – это Agile-команды, созданные для поддержки принципа SAFe №10 «Организация вокруг ценности».
Организации формируют ART с целью объединить людей, которые работают в едином потоке ценности, устранить зависимости и связанные с ними задержки, а также сократить вывод фич на рынок.
Функция ART — разрабатывать и поставлять продукты, услуги или системы для заказчика. ART являются кросс-функциональными и обладают всем необходимым программным и аппаратным обеспечением, а также могут самостоятельно определять приоритеты и объем работы, создавать, проверять и выпускать ценность.
Численность ART может составлять 50-125 сотрудников.
Сила ART — в Agile-командах. Поскольку ART состоит из нескольких команд, то общий успех зависит от результатов работы каждой Agile-команды внутри ART.
Agile-командам важно работать сообща и синхронизировано, чтобы обеспечить поставку ценности.
Кто есть кто в вашем ART
Как и в Agile-команде, в ART есть специализированные роли.
Подобно Agile-команде, ART-лидеры работают в сотрудничестве.
Release Train Engineer (RTE), продуктовый менеджмент и системный архитектор/инженер находятся в тесном контакте, чтобы обеспечить работоспособность ART.
Для того, что поддерживать согласованность действий внутри ART, RTE тесно сотрудничает со Скрам-мастерами, Продуктовый менеджмент работает с Владельцами продуктов, а Cистемный архитектор/инженер поддерживают команды и технических руководителей.
Release Train Engineer
Брать на себя ответственность за решение чужих проблем является злоупотреблением нашими полномочиями.
Питер Блок, управляющий директор
Скорее всего, вы впервые встретитесь с RTE на каком-либо событии ART. RTE гарантирует, что ART поставляет ценность, фасилитирует события ART и производственный процесс. У этой влиятельной роли есть ключевые обязанности:
- Фасилитация PI-планирования.
- Поддержка исполнения PI-планов.
- Тренинги и Agile-коучинг ART.
- Оптимизация рабочего потока.
- Создание среды для постоянных улучшений.
Менеджеры продуктов
Этот человек – иголка в стоге сена. Практически невозможное сочетание структурированного мыслителя и дальновидного лидера.
Тони Фаделл «Build. Неортодоксальное руководство по созданию стоящих вещей»
Продуктовый менеджмент определяет продукты, которые ART создает. Они помогают поставлять решения, которые нужны клиентам, и обеспечивают соответствие развития продукта видению компании. Решение, которое разрабатывает ваш ART может поддерживать один или несколько Продуктовых менеджеров.
- Исследования рынка и пользователей.
- Поддержание связи с покупателями.
- Определение стратегии, видения и дорожной карты развития продукта.
- Управление и приоритизация бэклога ART.
- Поставка ценности.
Системный архитектор/инженер
Систему необходимо постоянно адаптировать, иначе она становится все менее приемлемой.
Мэнни Леман «Показатели и законы эволюции программного обеспечения»
Техническая и архитектурная система, обеспечивающая поставку ценности, является ответственностью системного архитектора/инженера. Эту функцию может выполнять один или несколько человек. Они поддерживают ART, обеспечивая Agile-подход к проектированию и созданию систем. Системные архитекторы тесно сотрудничают с Продуктовым менеджментом, RTE и другими архитекторами и поддерживают команды во время внедрения.
- Адаптирует архитектуру под бизнес-приоритеты.
- Определяет и делится архитектурным видением.
- Развивает системный дизайн вместе с командами.
- Поддерживает внедрение встроенного качества и участвует в определении нефункциональных требований.
- Поддерживает DevOps и конвейер непрерывной поставки.
Представители бизнеса
Когда все чем-то владеют, никто этим не владеет, и никто не заинтересован напрямую в поддержании или улучшении этого состояния.
М. Фридман и Р. Фридман «Свобода выбора: наша позиция»
Представители бизнеса — это небольшая группа заинтересованных лиц конкретного ART, ответственных за бизнес-результаты, которые ART обеспечивает с технической и бизнес точек зрения. Представители бизнеса присоединятся к Agile-командам во время PI-планирования и определяют значение бизнес-ценности для тех целей, которые команда ставит перед собой. Они также принимают участие в мероприятии «Инспекция и Адаптация».
Во время выполнения PI-планов представители бизнеса остаются вовлеченными, участвуют в системной демонстрации и предоставляют своевременную обратную связь, которая дает возможность командам на ранних этапах вносить корректировки в свою работу при необходимости.
- Являются примером лидерства.
- Взаимодействуют с менеджментом уровня портфеля.
- Выравнивают деятельность ART для достижения стратегических целей.
- На PI-планировании приоритизируют цели ART.
- Отвечают за бизнес-результаты.
- Спонсируют постоянные улучшения.
Обзор событий ART
Вспомните о командных событиях и о том, что у каждого из них была уникальная цель. Теперь масштабируйте их на весь ART.
Специальные события позволяют всем командам, входящим в состав ART, эффективно взаимодействовать, заблаговременно выявлять риски, возможности для улучшения и достигать PI-целей.
События ART схожи по характеру и цели с командными мероприятиями и следуют циклу «Планируй-делай-Проверяй-корректируй»:
- Планируй – PI-планирование (PI Planning).
- Делай – Работа в PI.
- Проверяй – Системная демонстрация (System Demo).
- Корректируй – Инспекция и адаптация (Inspect and Adapt, I&A).
ART проводят процедуру PI-планирования; в течении PI делают демонстрацию результатов работы и проводят ретроспективу, чтобы поразмыслить над последним PI и найти идеи для улучшения, с которыми они могут поэкспериментировать во время следующего PI.
Часть событий ART направлены на то, чтобы синхронизировать команды, убедиться, что ART все еще находится на верном пути, скорректировать работу при необходимости и и поставлять ценность для достижения PI-целей.
Посмотрите пример календаря событий ART:
Синхронизация Скрам-мастеров
Если вы являетесь участником Agile-команды, то можете выявить зависимости, препятствия и риски во время DSU (Daily Stand-Up) вашей команды. Скрам-мастер доводит до сведения SoS (Scrum-of-Scrums, синхронизация Скрам-мастеров) препятствия, которые команда не может устранить самостоятельно. Участники команды также могут присоединиться к SoS в качестве экспертов предметной области.
Как заинтересованное лицо, вы можете присоединиться к SoS, чтобы наблюдать и поднимать проблемы после того, как все команды поделятся информацией. После встречи RTE сообщает заинтересованным сторонам о любых серьезных проблемах, которые поднимают команды.
- встреча Daily Stand-Up (DSU, Ежедневный Стендап) была переименована в Team Sync (Синхронизация Команды);
- Scrum-of-Scrums (Синхронизация Скрам-мастеров) была переименована в Coach Sync (Синхронизация Коучей).
Синхронизация Владельцев продуктов
На встрече по синхронизации Владельцы продуктов управляют границами работ во время PI, анализируют прогресс, корректируют приоритеты и готовятся к следующему PI.
Бэклог ART
Фичи состоят из историй.
Фичи – это сервисы, которые удовлетворяют потребности заинтересованных лиц. Бэклог ART содержит Фичи, приоритизированные продуктовым менеджментом.
Когда команда готова взять Фичу в работу, они с Владельцем продукта разделяют Фичу на пользовательские Истории. Владелец продукта, при участии команды, приоритизирует Истории в бэклоге команды.
Синхронизация ART
ART Sync – это комбинация синхронизации коучей команды (Coach Sync) и синхронизации Владельцев продуктов (PO Sync). Некоторые ART предпочитают собирать участников этих двух мероприятий на одной общей встрече, чтобы они были в едином контексте. Участвуют RTE, Скрам-мастера/Коучи, Продуктовый менеджмент, системный архитектор/инженер, заинтересованные лица и приглашенные эксперты предметной области.
Как правило, зависимости и основные блокеры обсуждаются вначале, в рамках синхронизации коучей, а прогресс ART в достижении целей PI и необходимые корректировки плана следуют далее, в рамках синхронизации Владельцев продуктов.
Системная демонстрация
На системной демонстрации в конце каждой итерации команды демонстрируют интегрированные и работающие решения. Весь ART участвует в демонстрации, чтобы быть в курсе всех деталей поставляемого решения. При проведении демо командами ART участники обмениваются конструктивной обратной связью.
Участники системной демонстрации:
- Продуктовый менеджмент и Владельцы продуктов, которые отвечают за проведение демо.
- Участники Системной команды, которые помогают настроить демонстрацию на предпродуктивном окружении.
- Представители бизнеса, бизнес-спонсоры, клиенты и доверенные лица клиентов.
- Системный архитектор, ИТ-специалисты и другие участники разработки.
- По возможности, участники Agile-команд ART.
Пример повестки:
- Краткий обзор бизнес-контекста и целей PI.
- Краткое описание новых Фич перед непосредственно демонстрацией.
- Демо новых Фич в виде сквозного (end-to-end) сценария использования.
- Выявление текущих рисков и препятствий.
- Открытое обсуждение вопросов и обратной связи.
- Подведение итогов.
- Предоставляйте обратную связь в доброжелательной форме.
- Во время демонстрации не забывайте упомянуть тех, кто внес вклад в создание Решения.
- Помните, что Системная демонстрация – это отличная возможность продемонстрировать результаты своей работы, а для представителей ART – познакомиться с вами поближе.
Инспекция и адаптация
Кайдзен заключается в изменении существующего порядка вещей. Если вы полагаете, что все в порядке так, как оно есть, вы не сможете применять кайдзен. Так измените что-нибудь!
Тайичи Оно
Неустанное совершенствование – одна из четырех основных ценностей SAFe. Как и каждая Agile-команда в конце каждой итерации, каждый ART делает паузу в конце каждого PI, проводит обзор и анализ результатов, проводит ретроспективу и определяет области улучшения в следующем PI. Все участники ART принимают участие в мероприятии «Инспекция и адаптация» (Inspect and Adapt, I&A).
Участники инспекции и адаптации:
- Agile-команды.
- RTE, Системные архитекторы и архитекторы Решений.
- Продуктовый менеджмент, представители бизнеса и другие заинтересованные стороны.
- Заинтересованные стороны Solution Train также могут посетить это мероприятие.
Повестка:
- Итоговая Системная демонстрация PI.
- Обзор достигнутых количественных и качественных показателей.
- Ретроспектива и воркшоп по решению проблем.
Как участник ART вы можете участвовать в каждой части I&A и имеете право голоса при формировании задач по улучшению в следующем PI.
PI-планирование
Поехали!
Юрий Гагарин
Планирование PI – это двухдневное мероприятие, которое проводится в конце каждого PI для планирования следующего. В PI-планировании участвует весь ART, заинтересованные стороны и клиенты.
Это уникальное мероприятие, которое собирает всех представителей ART, заинтересованных лиц и клиентов в одном помещении, чтобы в плотном взаимодействии спланировать свою работу для следующего PI.
Несмотря на ценность очного PI-планирования, во время пандемии возникла необходимость провести это мероприятие в онлайн-формате в режиме реального времени и одновременно. Онлайн-мероприятие также применяется для обеспечения участия распределенных команд.
Тот, кто выполняет работу – планирует работу. Команды берут на себя обязательства за достижение целей, которые они определяют для себя сами. Менеджмент не планирует и не берет на себя обязательства по выполнению работы за тех, кто ее выполняет.
В SAFe нет никакой магии… за исключением, разве что, PI-планирования.
Авторы SAFe®
В начале PI-планирования руководство ART делится бизнес-контекстом на брифинге для руководителей.
Продуктовый менеджмент делится информацией по видению продукта и приоритетным Фичам, а системный архитектор/инженер рассказывает про архитектурный контекст и энейблеры.
Когда весь ART выровнялся в части бизнес-контекста и видения, они начинают планировать PI, определяя емкость команд. Вот обзор активностей, в которых команда участвует в течении PI-планирования:
- Команды проводят встречи по планированию своей работы, выявляют зависимости и прорабатывают их совместно с другими командами.
- Команды демонстрируют свои проекты планов представителям ART и бизнеса, чтобы получить обратную связь и выявить риски.
- Команды разделяются и продолжают разрабатывать свой окончательный план.
- Команды демонстрируют свой окончательный план представителям ART.
- Представители бизнеса принимают окончательный план каждой команды.
- Когда весь ART получил окончательный план, проводится голосование уверенности (имеется в виду уверенность в реалистичности планов).
PI-цели
Принятие и выполнение небольших обязательств укрепляет доверие.
Нонака Икуджиро, Такеучи Хиротака «Компания-создатель знания»
PI-цели аналогичны целям итерации, которые команды ставят перед каждой итерацией. Во время PI-планирования команды определяют свои командные PI-цели, которые обобщают бизнес- или технические цели команд. Команды делятся своими целями с ART и обязуются их достигать.
Постановка PI-целей обеспечивает единый контекст, формирует видение команд на ближайшую перспективу, выявляет зависимости и позволяет оценить ценность для бизнеса, которую они приносят.
- Первое PI-планирование – это интенсивный опыт для любого нового участника ART. Если вы являетесь заинтересованным лицом, вы можете обратиться с вопросами к Скрам-мастеру/Коучу команды, участникам команды или RTE.
- Участвуйте в обсуждениях на уровне команды и ART во время PI-планирования. Сила PI-планирования заключается в наличии всей информации в голове каждого участника ART.
- PI-планирование требует значительной подготовки с точки зрения организационной, содержательной и логистической готовности.
Тест — проверьте, насколько хорошо вы усвоили материал
Время вышло