SAFe ScrumXP

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».

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

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

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

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

Итерация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполнение

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

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

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

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

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

Инкремент

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

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

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

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

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

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

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

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

Участие в System Demo

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

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

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

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

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

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

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

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

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

Роли SAFe ScrumXP

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

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

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

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

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

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

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

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

Все команды Релизного Поезда планируют, демонстрируют и учатся вместе, как показано на рисунке 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»