SAFe ScrumXP

11 октября 2022

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

Хиротака Такеучи и Икужиро Нонака, “The New, New Product Development Game”
Хиротака Такеучи и Икужиро Нонака, “The New, New Product Development Game”

SAFe Scrum XP — что это?

SAFe ScrumXP — это метод, используемый Agile Командами в составе Релизных Поездов (Agile Release Train, ART), для планирования, выполнения, ретроспективы и доставки ценности клиентам в наикратчайшие сроки. ScrumXP сочетает в себе силу Scrum и практики экстремального программирования (XP).

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

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

Принцип SAFe No 9 «Децентрализация принятия решений» способствует выравниванию и деликатному, не административному направлению гибких команд со стороны менеджмента. Команды сами определяют, как они выполняют работу и какой объем работы они могут взять на каждый период времени. Команды создают и уточняют элементы беклога, которые обычно представлены в виде историй с установленными критериями приемки. Эти элементы определяют ожидаемые результаты Итерации, за достижение которых команды берут на себя обязательства. После взятия обязательств команды разрабатывают, тестируют, развертывают новую функциональность и обеспечивают встроенное качество для каждого инкремента Решения.

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

Цикл SAFe ScrumXP

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

Цикл SAFe ScrumXP
Рисунок 1. Цикл SAFe ScrumXP

 

Далее в статье мы рассмотрим более подробно все элементы «цикла SAFe ScrumXP».

Итерации как базовый блок Agile разработки и каждое отдельное событие (ритуал) Scrum, включая планирование, выполнение, ежедневный стендап, обзор и ретро, кратко описаны ниже, при этом все имеют отдельные, более развернутые отдельные статьи в рамках фреймворка.

Беклог Команды

Беклог Команды содержит всю будущую работу, которую команде предстоит выполнить для развития Решения. Большая часть работы фиксируется в виде пользовательских историй, но в беклог также могут быть включены и другие виды работ и активностей (например, обучение, поддержка). В течение мероприятия «PI Планирование» команды готовят предварительную версию беклога, устанавливают Результаты (Цели) Инкремента Программы, которые выравнены и встраиваются в общую миссию (предназначение) Поезда.

«По моему опыту работы со многими компаниями при запуске SAFe практически всегда встает вопрос «вокруг чего именно пишутся PI Objectives?». Более-менее устоявшийся перевод «Цели на Инкремент Программы» не полностью отвечают изначальной идее, заложенной в SAFe.

Фреймворк требует, чтобы команды сами сформулировали и подписались не просто под какими-то «высокими целями», а именно под результатами, которые достигнет эта команда в отдельности или в сотрудничестве с другой командой (командами) Поезда.

Распространённым анти-паттерном здесь является «внешнее подписание» команд на цели, которые высшее руководство поставило менеджменту, и достижение которых находится далеко вне зоны влияния и контроля команды.

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

Для выравнивания разработки вокруг общих целей бизнеса в SAFe предусмотрены другие действенные механизмы и инструменты.»

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

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

«Как написано в рекомендации выше, уточнение беклога должно являться непрерывным процессом. Это означает, что члены команды будут по необходимости собираться и обсуждать беклог, постоянно обеспечивая его проработанность хотя бы на 2 итерации вперед.

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

В результате вся тяжесть обсуждения беклога командой переместится на мероприятия Обзора и Планирования Итерации, и результатом будет менее качественное выполнение Итерации и меньшая предсказуемость в работе команды.

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

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Итерация

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

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

Планирование итерации

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

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

Планирование Итерации затрагивает следующие темы[1]:

  • Почему эта итерация имеет ценность?
  • Что можно сделать, чтобы доставить ценность?
  • Как будет выполняться работа?

На Планировании Итерации команда уточняет критерии приемки для каждой истории и оценивает свои усилия по ее выполнению. Команда выбирает истории-кандидаты на основе доступной емкости команды на итерацию. Для каждого выбранного элемента команда планирует работу, которую необходимо выполнить для создания инкремента ценности. При этом разработанный инкремент ценности должен соответствовать всем Определениям Выполненности (Definition of Done, DoD), гарантируя тем самым, что работу можно считать завершенной/выполненной.

«Для обязательного артефакта команды «Definition of Done, DoD» иногда используется русскоязычный термин «Критерии готовности», который с точки зрения практики может создать существенную путаницу.

Во-первых, в SAFe для элементов беклога существуют обязательные «Критерии приёмки» (Acceptance criteria), а во-вторых, некоторые организации используют в работе кроме DoD другой артефакт, называемый DoR, или «Definition of Ready», название которого также иногда переводят как «Критерии готовности».

Обсуждение того, на сколько DoR является частью Agile разработки, выходит за рамки данной статьи. Одновременно, дословный перевод DoD звучит именно как Определение Выполненности или Завершённости, и именно этот термин мы используем в работе во избежание путаницы.»

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Непрерывная разработка инкрементов функциональности системы требует масштабируемого DoD (Определения Выполненности), чтобы обеспечить, что работа выполнена правильно.

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

Беклог размещается на видимом месте, таком как доска историй, Канбан доска или другом инструментарии управления Agile работами. Мероприятие «Планирование Итерации» занимает не более четырех часов для двухнедельной итерации. Для опытной команды при условии регулярно в течение итерации прорабатываемого командой беклога обычно планирование итерации занимает не более двух часов для двухнедельной итерации.

Цели Итерации

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

Беклог Итерации

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

Кроме того, команды постоянно получают обратную связь — не только по завершении предыдущих итераций, но и по результатам System Demo и в течение процесса разработки от других команд, с которыми они взаимодействуют. Источников влияния на содержание беклога итерации достаточно много: это локальная ситуация в команде (дефекты, технический долг и обслуживание), выполнение Беклога Программы всем поездом и ситуация с достижением Целей Инкремента Программы (созданием высокоуровневых результатов PI), за которые команда взяла на себя ответственность.

Выполнение

В SAFe команды доставляют ценность на основе каденции и синхронизации требований на уровне Релизного Поезда (Agile Release Train). Это облегчает выравнивание, управление зависимостями и обеспечивает быстрые, встроенные в разработку циклы обучения для всего Решения. Во время итерации каждая команда совместно определяет, разрабатывает и тестирует истории, за выполнение которых она взяла на себя ответственность на Планировании Итерации.

Команды отслеживают прогресс итерации и улучшают поток ценности, используя доску историй и Канбан доску, а также мероприятия ежедневных стендапов (Daily Stand-Up, DSU). Задачей команды является организоваться таким образом, чтобы доставлять истории на протяжении всей итерации и не допускать «водопадного» подхода внутри итерации. Команда должны применять практики Встроенного Качества для правильной разработки системы. Эти практики требуют в том числе демонстрации завершенных историй на протяжении всей итерации, а также на Обзоре Итерации.

«Здесь в качестве анти-паттерна можно привести ситуацию, когда Владелец Продукта не участвует в непрерывном рассмотрении результатов работы по каждой Истории в течение итерации и «приходит» только на Обзор итерации, где принимает или не принимает отдельные Истории.

Также анти-паттерном будет обратная ситуация, когда команда не проводит мероприятие Обзора итерации, поскольку «и так всё понятно».

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Ежедневная встреча (Daily Stand-Up, DSU)

Ежедневная встреча команды (стендап, Daily Stand-Up, DSU) — короткая встреча, которая обычно проводится ежедневно и занимает не более 15 минут. Ежедневный стендап используется для самоконтроля прогресса в достижении целей итерации, общения и корректировки запланированной работы. Команда может использовать любую структуру или технику для проведения DSU, создавая план действий по координации работы в течение следующего дня.

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

Инкремент

Инкремент, отображенный на рисунке 1, появляется в процессе выполнения командой итерации. Выделение инкрементов ценности позволяет управлять развитием новой функциональности решения в каждой итерации. Новый инкремент неразрывно связан с предыдущими и проверяется, чтобы гарантировать, что все инкременты одновременно и совместно работоспособны.

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

Подводя итог итерации, команда рассматривает на мероприятии «Обзор Итерации» все созданные инкременты.

Обзор Итерации

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

«Еще один анти-паттерн, который встречается в некоторых организациях – изменение последовательности выполнения мероприятий Итерации. Причина кроется в неполном понимании, как выходная информация одного мероприятия ScrumXP становится входной для следующего.

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

Таким образом, мероприятие Обзор Итерации готовит данные и темы для обсуждения на Ретроспективе, которая должна следовать после Обзора Итерации.

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Ретроспектива итерации

Ретроспектива итерации — последнее мероприятие итерации. Основная цель — поразмышлять над тем, как прошла итерация, и разработать новые идеи для улучшения инкремента и процесса. Ретроспектива помогает привить концепцию неустанного улучшения — одну из основных ценностей SAFe.

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

Участие в System Demo

Демонстрация Cистемы дает комплексное представление о новых фичах, которые были доставлены всеми командами Поезда за самую последнюю завершенную итерацию. Каждая демонстрация дает заинтересованным лицам ART объективную оценку прогресса в создании результатов во время PI. Все участники ART участвуют или, по крайней мере, посещают демонстрацию системы.

«Демо Системы проводится на основании завершенной итерации. До начала очередного Демо Системы команды проводят Обзор, Ретро, и, возможно, планируют и уже приступают к выполнению следующей итерации.

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

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Посмотреть Календарь мероприятий SAFe

Отслеживание прогресса

Kanban системы управляют беклогами и потоком работ на всех уровнях SAFe. Канбан Доска Agile Команды (рисунок 2) отражает уникальный процесс доставки ценности для этой команды, оптимизированный под специфику текущего потока работы и доступную ёмкость этой команды.

Пример беклога команды и потока работы, представленных на Канбан доске
Рисунок 2. Пример беклога команды и потока работы, представленных на Канбан доске

Встроенное Качество

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

SAFe описывает многие инженерные подходы и практики качества, вдохновленные Экстремальным программированием (XP):

  • Непрерывная интеграция
  • Раннее тестирование (Test-First), включая разработку на основе тестирования (TDD) и разработку на основе поведения (BDD)
  • Рефакторинг
  • Парная работа
  • Коллективное владение

Некоторые команды используют и другие практики XP, такие как парное программирование, метафоры систем и многое другое.

Роли SAFe ScrumXP

Размер и структура команды оптимизированы для общения, совместной работы и способности доставлять ценность. «Scrum команда достаточно мала, чтобы оставаться проворной, и достаточно велика, чтобы выполнить значительную работу за спринт.[2].”

SAFe Agile Команда
Рисунок 3. SAFe Agile Команда

 

SAFe Agile команды, в том числе те, которые используют Scrum, имеют две специализированные роли, каждая из которых имеет уникальный набор обязанностей:

  • SAFe Scrum Мастер (может быть с частичной занятостью) помогает координировать доставку ценности клиентам. Для этого Скрам Мастер:
    • Проводит коучинг вокруг принципов Lean-Agile
    • Отслеживает, поддерживает, направляет и облегчает (фасилитирует) устранение препятствий на пути прогресса команды
    • Создает эффективную самоорганизацию и самоуправление внутри команды
    • Поддерживает среду высокой производительности и неустанного улучшения.

SAFe Scrum Master может иметь дополнительные обязанности, такие как коучинг DevOps, практик Встроенного Качества, Kanban и потока.

  • Владелец Продукта (обычно полная занятость) понимает потребности и ожидания клиентов и заинтересованных лиц. Для этого Владелец Продукта:
    • Владеет контентом в беклоге команды
    • Расставляет приоритеты в работе, помогая гарантировать, что команда создает правильное решение.
    • Взаимодействует с другими командами в поезде, обеспечивая согласование приоритетов и последовательности доставки ценности.

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

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

Поэтому Agile команды в SAFe объединяются в Релизные Поезда (Agile Release Train, ART) и создают таким образом среду для согласования и сотрудничества с другими командами при разработке более широких возможностей решения.

Все команды Релизного Поезда планируют, демонстрируют и учатся вместе, как показано на рисунке 4. Это помогает им одновременно сосредоточиться как на локальных задачах, так и на общей, более крупной цели Релизного Поезда Agile. Наравне с пониманием более крупной цели такое выравнивание, выполненное правильным образом, позволяет каждой команде более независимо изучать, интегрировать, развертывать и выпускать ценность.

Agile команды планируют, демонстрируют и обучаются вместе
Рисунок 4. Agile команды планируют, демонстрируют и обучаются вместе

 

[1] Nonaka and Takeuchi, The New, New Product Development Game, Harvard Business Review, January 1986.

[2] Sutherland, Jeff, and Schwaber, Ken. The 2020 Scrum Guide, Scrumguides.org.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом.

Дополнительно почитать:

Статья «Kanban в SAFe»

Статья «Мероприятия Scaled Agile Framework»

 

Другие статьи в блоге:

Agile Команда
Что такое Agile команда? В чем ее эффективность? Роли в команде и четко определенные обязанности Agile команды. Как формируются команды и топология команд. Agile команды в Agile Release Train.
Release Train Engineer
Все о Release Train Engineer в одной статье: обязанности и характеристики RTE, кому подчиняется и с кем взаимодействует, роль RTE в ключевых мероприятиях SAFe, как стать RTE и как определить хорошего RTE?
WSJF, Weighted Shortest Job First
Что такое WSJF? Как оценить стоимость задержки? Как оценить продолжительность работы? Как вычислить WSJF? Когда и где применяется WSJF? В каких случаях эта техника требует уточнений?