Все статьи
Быстрый старт в RTE #4 – Исполнение PI-плана
Дата: 15.07.2024
Это четвертая заключительная статья серии «Быстрый старт в RTE», в которой рассмотрены рекомендации по сопровождению исполнения PI-плана. Значимость качественного выполнения роли RTE в этих процессах сложно переоценить.
Исполнение PI-плана
RTE — это должен быть человек с опытом демократичного менеджмента или коуч, который хорошо разбирается в бизнесе и продукте.
Как только вы завершите PI-планирование, настанет время приступить к выполнению этих планов. Как RTE, вы несете ответственность за содействие командам в поставке ценности. Различные мероприятия, инструменты и советы помогут вам в этом.
Разобравшись в том, как и какие мероприятия Agile Release Train (ART) необходимо организовать, какие инструменты и показатели для управления потоком использовать, вы поймете обязанности и ответственность роли RTE в течении периода исполнения планов PI.
На иллюстрации ниже отражены пять мероприятий ART и их очередность в цикле PI:
- Coach Sync (Синхронизация коучей/Скрам-мастеров).
- PO Sync (Синхронизация Владельцев продукта).
- ART Sync (Синхронизация Agile Release Train).
- System Demos (Системные демонстрации).
- I&A (Инспекция и адаптация).
В статье мы подробно расскажем об их назначении, участниках, дадим рекомендации по фасилитации и советы, которые помогут вам улучшить ваши мероприятия.
После прочтения статьи вы сможете:
- Определить ключевые события ART, которые происходят во время выполнения планов PI;
- Определить методы, которые помогут организовать события ART;
- Определить метрики для управления потоком и его улучшения.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Agile Release Train (ART)
Agile Release Train (ART) — это долгосрочная команда Agile-команд, которая инкрементально разрабатывает, внедряет и часто эксплуатирует одно или несколько решений в рамках потока разработки ценности.
Release Train Engineer (RTE)
Release Train Engineer (RTE) или «машинист поезда» — это лидер-слуга и коуч в Agile Release Train (ART), который проводит мероприятия и помогает в реализации процессов, а также поддерживает команды в поставке ценности.
PI-планирование
PI-планирование (PI Planning, Планирование Интервала) — это регулярно повторяющееся мероприятие всего ART, которое согласовывает команды и заинтересованных лиц вокруг общей миссии и концепции.
Синхронизация Коучей
Синхронизация Коучей — это мероприятие ART, которое помогает координировать взаимозависимые работы, обеспечивает наглядность прогресса и наличие препятствий.
Синхронизация Владельцев Продуктов
Синхронизация Владельцев Продуктов (Product Owner Sync, PO Sync) — это мероприятие ART, которое обеспечивает прозрачность прогресса ART в достижении PI-целей и возможность внести любые необходимые коррективы.
Синхронизация ART
Синхронизация ART — это мероприятие, которое совмещает Синхронизацию Владельцев Продукта (PO Sync) и Синхронизацию Коучей (Coach Sync).
Системная Демонстрация
Системная Демонстрация предоставляет заинтересованным лицам комплексный обзор новых Фич, которые были реализованы за последнюю итерацию всеми командами ART. Каждая демонстрация дает объективную оценку прогресса и возможность сбора обратной связи.
Инспекция и адаптация
Инспекция и Адаптация (Inspect and Adapt, I&A) — значимое событие, происходящее в конце каждого интервала планирования (Planning Interval, PI), когда демонстрируется и оценивается текущее состояние Решения. Затем команды обдумывают и выявляют элементы бэклога по улучшению с помощью структурированного семинара по решению проблем.
Синхронизация коучей/Скрам-мастеров
Участники
Как RTE, вы фасилитируете Coach Sync. Участие в этой встрече обязательно для представителей всех команд ART. В число участников обычно входят:
- Scrum-мастеры/командные коучи (Scrum Masters/Team Coaches);
- эксперты, которые могут рассказать о соответствующих зависимостях или блокерах;
- заинтересованные лица и Представители бизнеса (Business Owners);
- системные архитекторы.
Необязательные участники посещают Coach Synce время от времени. Четко укажите этих необязательных участников в своем приглашении на собрание, чтобы избежать путаницы.
Повестка
Во время собрания представитель каждой команды, обычно командный коуч/Скрам-мастер, отвечает на ряд вопросов, аналогичных тем, которые задаются при командной синхронизации:
- Чего достигла ваша команда с момента последней встречи?
- Чего ваша команда достигнет до следующей встречи?
- Есть ли какие-либо блокеры?
- Могут ли возникнуть блокеры с вашей стороны в отношении других команд?
После того, как команды ответят на вопросы, заинтересованные лица могут задать свои. После завершения встречи ваша обязанность сообщить ключевым заинтересованным сторонам и организации о любых серьезных препятствиях и проблемах, если это необходимо.
После Coach Sync. Только представители соответствующих команд остаются обсудить решение проблем после общей синхронизации. Начинайте с проблем, затрагивающих большее количество участников, и постепенно переходите к проблемам, которые касаются меньшинства.
Таким образом, участники смогут покидать встречу, не дожидаясь полного её завершения и не потратят время впустую. Следите за временем, но уделяйте его достаточно для решения возникающих проблем.
Возможные проблемы
Иногда Coach Sync превращается в статусное совещание с зачитыванием формальных командных отчетов. Вот возможные решения этой проблемы:
- Переориентировать участников на основную цель встречи: управление зависимостями и препятствиями.
- Использовать доску ART Board для визуализации межкомандных зависимостей.
- Создайте условия для решения проблем. Цель встречи — координировать зависимости и блокеры. Поощряйте совместные обсуждения проблем и поиск их решений.
Создайте безопасную среду для обмена информацией. Обучите командных коучей/Скрам-мастеров делиться своими трудностями и обращаться за помощью.
Советы
Не всегда возможно решить проблемы во время Coach Sync или задержавшись после встречи. Возможно, эти риски или элементы улучшения должны быть предоставлены руководителям более высокого уровня, которые способны решить проблемы или способствовать их разрешению.
Полезным для RTE является создание и ведение бэклога таких задач для руководства, который помогает отслеживать прогресс и передавать ответственность за риски и улучшения руководителям.
Составьте список возможных проблем, которые могут возникнуть во время проведения Coach Sync, и проведите мозговой штурм, чтобы сформировать идеи, которые помогут справиться с проблемами до того, как они возникнут.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Скрам-мастер/Коуч Команды
Скрам-мастер/Коуч Команды (Scrum Master/Team Coach (SM/TC) —) — это лидер и коуч Agile-команды, который помогает в реализации командных процессов, мероприятий и поставке ценности.
Представители Бизнеса
Представители Бизнеса (Business Owners) — ключевые заинтересованные лица ART, которые несут решающую ответственность за технологическую и бизнес-основу возврата инвестиций (Return on Investment, ROI), управления и нормативно-правового контроля (Сompliance).
Системный Архитектор
Системный Архитектор (System Architect) отвечает за определение и донесение общей технической и архитектурной концепции Решений, разрабатываемых несколькими ART.
Agile-команда
Agile-команда (Agile Team) — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Синхронизация Владельцев продуктов
Синхронизация Владельцев продуктов (PO Sync) — это 30-60-минутное мероприятие, которое обычно проводится один или два раза в неделю. Фасилитируют PO Sync обычно RTE или менеджер продукта. Менеджеры продуктов и Владельцы продуктов проверяют прогресс ART в достижении PI-целей и, при необходимости, корректируют объем работ или приоритеты.
Другая цель PO Sync — подготовка бэклога ART для следующего PI. Во время PO Sync проводится проработка Фич и их приоритизация по модели «Самая ценная и короткая работа сначала» (WSJF).
Обязательно используйте PO Sync для подготовки к планированию предстоящего PI. Это удобная площадка для сквозной приоритизации и достижения согласованности мнений по Фичам.
Участники
В PO Sync участвуют:
- RTE;
- Продуктовый менеджмент;
- Владельцы продуктов;
- заинтересованные лица;
- системный архитектор (опционально);
- технические специалисты (опционально).
Может оказаться полезным пригласить системного архитектора или технических специалистов. Всю важную и новую информацию Владельцы продуктов потом доводят до своих команд.
Повестка
RTE фасилитирует встречу и работает совместно с Продуктовым менеджментом. Также полезными инструментами являются доска Канбан ART или другие, которые обеспечивают отслеживание PI-целей и прогресса по Фичам и контрольным точкам (вехам).
Как система, основанная на потоке, SAFe фокусируется на показателях потока. Отслеживание показателей потока помогает вам понять, как продвигается работа по выполнению плана.
Ознакомьтесь со следующими показателями потока и выносите их в PO Sync для обсуждения при необходимости.
Возможные проблемы
Советы
В первой части обсудите текущий PI, определите, не находится ли что-либо из утвержденного плана под угрозой, и обсудите, являются ли внеплановые запросы достаточно ценными, чтобы включать их в планы PI, или их можно пока отложить в бэклог.
Вторую часть посвятите проработке Фич в бэклоге, чтобы подготовить ART к следующему PI-планированию.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Продуктовый Менеджмент
Продуктовый Менеджмент (Product Management) отвечает за определение и поддержку разработки востребованных, осуществимых, жизнеспособных и устойчивых продуктов, удовлетворяющих потребностям клиентов на всем жизненном цикле продукта.
Владелец Продукта
Владелец Продукта (Product Owner, PO) — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Цели Интервала Планирования, PI-цели
PI-цели — это высокоуровневое описание бизнес- и технологических целей, которых команды и поезда собираются достичь в предстоящем Интервале Планирования.
Фичи
Фича представляет собой функциональность решения, которая несет ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, что может быть реализована одним Agile Release Train в рамках одного Интервала Планирования (Planning Interval, PI).
Weighted Shortest Job First (WSJF)
Weighted Shortest Job First (WSJF) — модель приоритизации «Более Ценная и Короткая Работа Сначала» для упорядочивания работ с достижением максимальной экономической выгоды. В SAFe WSJF оценивается делением стоимости задержки на относительную длительность реализации.
Синхронизация ART
Каким должен быть RTE? В первую очередь у него должен быть здравый смысл.
ART Sync – это сочетание Coach Sync и PO Sync.
Для объединения встреч Coach Sync и PO Sync могут быть разные причины, например, желание объединить все руководство ART, в том числе участников Coach Sync и PO Sync. Продолжительность может быть скорректирована по мере необходимости. Пожалуйста, обратите внимание: обычно в дополнение к ART Sync проводятся отдельные мероприятия Coach Sync и PO Sync.
Возможные проблемы
Когда ваш ART Sync будет больше похож на отчет о состоянии дел, попробуйте:
- Переориентировать участников на цели мероприятия и фасилитировать его проведение.
- Пригласите руководство принять участие в Системной демонстрации, где они получат полную информацию о рабочем решении, поставленном ART.
Системная демонстрация
Основные этапы основаны на объективной оценке работающих систем.
Системная демонстрация — это мероприятие, проводимое в конце каждой итерации. Фичи, разработанные и поставленные в ходе последней итерации, презентуются заинтересованным лицам для получения обратной связи. Это мероприятие помогает продемонстрировать метрики прогресса и на каком этапе находится разработка.
Системная демонстрация — важное мероприятие, поскольку на ней демонстрируется рабочее Решение, созданное вашей командой. Это лучшее время, чтобы отметить работу вашей команды и отличная возможность получить отзывы заинтересованных лиц.
Участники
- За проведение демонстрации обычно отвечают Продуктовый менеджмент и Владельцы продуктов.
- Также принимают участие руководители ART (в том числе, Представители бизнеса), заинтересованные лица, системные архитекторы и Agile-команды.
Пригласите руководителей, которые запрашивают обновления статуса, на Системную демонстрацию для оперативного обновления.
Повестка
Полезно ознакомиться с повесткой перед встречей. Ознакомьтесь с бизнес-контекстом и целями PI в течение примерно 5-10 минут, прежде чем открывать Системную демонстрацию. Затем опишите каждую новую Фичу, прежде чем демонстрировать ее в течение примерно пяти минут. В течение следующих 20-30 минут каждая новая Фича будет демонстрироваться в виде сквозного (end-to-end) процесса.
После демонстрации определите текущие риски и препятствия. Организуйте открытое обсуждение вопросов и получение обратной связи. Наконец, подведите итоги прогресса, полученную обратную связь и принятые решения.
Советы
Мы хотим быть уверенными в том, что по мере исполнения планов PI мы действительно поставляем ценность.
Поэтому основной аудиторией Системной демонстрации являются Представители бизнеса (Business Owners). Для получения своевременной обратной связи и корректировки курса, если необходимо.
Продуктовый менеджмент — это те люди, которые играют ведущую роль в подготовке к Системной демонстрации. Работайте с командами, Владельцами продуктов, Системной командой, чтобы убедиться, что у нас есть нужная информация, правильные цели и правильные готовый инкремент, которые мы можем продемонстрировать заинтересованным лицам.
Подготовка является ключевым моментом в этом.
Возможные проблемы
Иногда Фичи, которые не интегрированы в систему, попадают в демонстрацию. Чтобы избежать этого:
- Используйте вертикальную декомпозицию для нарезки на небольшие Фичи, которые приносят пользу. Если компоненты создаются в отдельных функциональных подразделениях, таких как дизайнеры, отдел разработки и тестирования, они не могут быть интегрированы независимо.
- Возможно, не существует промежуточного окружения, аналогичного продуктивному. Инициируйте архитектурные энейблеры для создания необходимых сред для поддержки Системной демонстрации.
Возможно, вы обнаружите, что демонстрации вашей системы постоянно выходят за рамки отведенного времени.
Чтобы избежать этого:
- Заранее определите, сколько времени отводится каждой Фиче.
- Подготовьте методологические рекомендации о том, что выносить на встречу. Например, мы хотим поделиться достижением гипотез о выгоде и результатами, а не выполненными работами или подробными историями.
Советы
Для эффективной Системной демонстрации попросите Продуктовых менеджеров, командных коучей/Скрам-мастеров и команды начать с проблемы, которую они пытаются решить.
Представление решения, которое они предлагают для существующей проблемы, проясняет результат. Четкие рекомендации, касающиеся формата демонстрации, полезны командам и заинтересованным лицам.
Инспекция и адаптация
Если машешь лопатой, тебе не до улучшений. А задача RTE вытащить всех из операционки.
Итоговая системная демонстрация
Системная демонстрация PI напрямую поддерживает принцип SAFe №5, который гласит: «Обосновывайте контрольные точки на объективной оценке работающих систем».
Во время итоговой Системной демонстрации показываются все Фичи, реализованные в ходе PI.Во время демонстрации или до него Представители бизнеса взаимодействуют с Agile-командами, чтобы определить фактическую бизнес ценность достигнутых PI-целей (Actual Business Value, ABV).
Несмотря на то, что Системная демонстрация проводится в конце каждой итерации, встреча в конце PI является заключительной и имеет ряд важных отличий. Как правило, аудитория более широкая. Например, дополнительные представители клиентов или Портфеля, а также Solution Train Engineers (STE) могут принимать участие в этом мероприятии.
Эта встреча также носит более формальный характер и требует дополнительной подготовки. Но, как и в случае с любой другой Системной демонстрацией, она должна длиться не более часа.
Участники
В Системной демонстрации в конце PI принимают участие:
- Agile-команды ART;
- RTE;
- Архитектор/инжиниринговый отдел систем и Решений;
- Продуктовый менеджмент;
- Представители бизнеса;
- ключевые заинтересованные лица;
- поставщики;
- клиенты;
- представители Портфеля
- Владельцы Эпиков
— и другие участники процесса.
Подготовка
Agile-команды, часто при поддержке Системной команды, работают с продуктовым менеджментом над подготовкой к мероприятию. Вместе они определяют сценарии, демонстрирующие интегрированные Фичи, которые была реализованы во время PI. Сценарий должен поддерживать вовлеченность заинтересованных лиц.
Примерная программа итоговой системной демонстрации может выглядеть следующим образом:
- Приветствуем участников и заинтересованных лиц.
- Обзор бизнес-контекста и PI-целей.
- Рассказ о новых Фичах и демонстрация их работы.
- Выявление текущих рисков и препятствий.
- Открытое обсуждение вопросов и получение отзывов.
- Подведение обобщенных итогов прогресса, отзывы и действий по решению вопросов.
Ожидаемый результат итоговой демонстрации — отзывы заинтересованных лиц и клиентов о поставленном Решении, которые могут привести к возможным корректировкам или новым идеям для Решения.
Ниже вы найдете определения всех использованных выше терминов SAFe.
Solution Train Engineer (STE)
Solution Train Engineer (STE) или «машинист поезда решений» — лидер-слуга и коуч, содействующий проведению мероприятий и процессов Solution Train, координирующий работу нескольких ART и поставщиков, а также поддерживающий эти ART в поставке ценности.
Поставщик
Поставщик — это внутреннее подразделение или внешняя организация, которая разрабатывает и поставляет компоненты, подсистемы или сервисы для ARTs и Потоков Разработки Ценности.
Epics — Эпики
Эпик — существенная инициатива по разработке Решения.
Владельцы Эпиков
Владелец Эпика (Epic Owner) отвечает за координацию движения эпиков по этапам системы Канбан Портфеля.
Решение
Решение (Solution)— это продукт, система или сервис, который предоставляет ценность внутренним или внешним клиентам.
Количественные и качественные показатели
RTE использует показатели, которые ART ранее согласился отслеживать. SAFe рекомендует применять показатели потока для оценки того, насколько эффективно организация поставляет ценность для Клиента.
Помимо достижений ART в поставке ценности, также важно понимать о технической зрелости. Оценка командной и технической гибкости может помочь отслеживать ваш прогресс в достижении компетентности Agile-команд, ART и встроенном качестве. Самооценка Agile-поставки продуктов (Agile Product Delivery Assessment) поможет вам оценить и отследить ваш прогресс в области клиентоориентированности и дизайн-мышления, ритмичной работы, регулярной поставки по требованию, а также в области DevOps и непрерывного конвейера поставки.
Ретроспектива и воркшоп по решению проблем
RTE должен быть достаточно смелым, чтобы открыто говорить о любых проблемах, при этом предлагая варианты решений.
Другой вариант — попросить RTE организовать поиск проблем прямо во время проведения мероприятия Инспекция и адаптация.
RTE, как фасилитатор, помогает выявить системные проблемы, над которыми хочет поработать ART.
Как только проблемы выявлены, команды и заинтересованные лица, участвующие в процессе, самоорганизуются вокруг проблемы, которая, по их мнению, является наиболее важной или к которой они имеют отношение.
- «Что»: какая проблема возникла?
- «Где»: где возникла проблема?
- «Когда»: когда возникла проблема?
- «Последствия»: каковы последствия, вызванные проблемой?
Участники
- Вы, как RTE, организуете мероприятие в сотрудничестве с Продуктовым менеджментом и командными коучами/Скрам-мастерами.
- В мероприятии принимают участие Agile-команды, системные архитекторы, менеджеры продуктов, Представители бизнеса и другие участники.
- Заинтересованные лица могут посещать мероприятие по мере необходимости.
Возможные проблемы
Иногда участники не проявляют интереса к Инспекции и адаптации, посещаемость снижается.
Чтобы повысить вовлеченность:
- Измените формат ретроспективы. Ищите способы вовлечения ART и поощряйте участие в решении вопросов.
- Выясните, почему снижается посещаемость, и решайте одну проблему за раз.
- Отслеживайте прогресс и результаты по решению задач из бэклога улучшений, чтобы участники знали, что Инспекция и адаптация приносит пользу.
Советы
Будьте гибкими и готовыми вносить изменения по мере прохождения ретроспективы и воркшопа по решению проблем. Попросите каждую команду представить одну системную проблему, которую они вместе выберут.
Часто команды представляют более одной проблемы. Устанавливайте ограничения, но не слишком жесткие.
Во время проведения Инспекции и адаптации мы делимся некоторыми показателями командного уровня. Напомните участникам, что эти показатели являются сигналами, которые необходимо анализировать.
Объясните руководству и специалистам, что показатели следует использовать не для сравнения команд, а в качестве отправных точек для улучшений.
Сотрудники могут занять оборонительную позицию во время проведения Инспекции и адаптации. Объективное изложение проблем во время встречи может быть затруднено. Помогите командам подготовиться так, чтобы они рассказывали информацию о системе и процессах, а не о людях.
Будьте готовы к смягчению остроты дискуссий. Подготовьте почву для заключения рабочих соглашений и переориентируйте команду на них по мере необходимости.
Запишите две основные проблемы, которые вам необходимо решить при фасилитации мероприятия Инспекция и адаптация. Разработайте план действий по решению этих проблем до начала мероприятия.
Критерии готовности
Критерии готовности (DoD) — это набор соглашений о том, что означает «сделано» для команды, для поставляемого инкремента, Решения или релиза. Для каждого уровня бэклогов критерии «сделано» будут различаться.
Проведите для вашего ART воркшоп по определению Критериев готовности, чтобы сформировать ваши собственные договоренности.
Возможные проблемы
События и инструменты уровня команды
Советы
Запланируйте периодические 30-минутные встречи-синхронизации с вашим системным архитектором и менеджментом продукта, чтобы поддерживать согласованность действий и формировать единую позицию руководства ART.
Наличие определенного времени и места проведения дает вам возможность обсудить любые сообщения от руководителей других организационных функций, сложные ситуации, связанные с прогрессом и объемом работ, корректировки, которые необходимо внести в планы ART, а также случаи, когда руководству ART необходимо выступить единым фронтом.
Поздравляем! Вы изучили все статьи цикла «Быстрый старт в RTE». Желаем успеха во внедрении новых практик и развитии ваших собственных компетенций!
