SAFe Scrum

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

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

Что такое SAFe Scrum?

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

Многие команды используют SAFe Scrum как свой основной Agile подход. Вместе с тем команды не ограничены применением только Scrum, они также могут использовать метод SAFe Team Kanban. При этом все Agile команды в SAFe-организации применяют техники Встраивания качества, а также другие практики и инструменты, которые не заявлены в Scrum.

SAFe Scrum команды взаимодействуют с другими Agile командами и заинтересованными лицами Agile Release Train, разрабатывают и развертывают Решения, которые приносят пользу клиентам.

При разработке ценности Agile команды, применяющие SAFe Scrum, придерживаются регулярного ритма проведения мероприятий для достижения общих целей. Команды имеют полномочия и автономию для планирования, выполнения и управления своей работой, принятия решений в процессе разработки и адаптации к изменяющимся условиям наилучшим, по их мнению, образом. Принцип SAFe No 9 «Децентрализация принятия решений» способствует выравниванию и деликатному, не административному направлению SAFe Scrum команд со стороны менеджмента.

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

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

Цикл SAFe Scrum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итерация

Итерации (Спринты) являются сердцебиением Scrum и задают ритм для работы на более продолжительный временной промежуток — Интервал Планирования (PI). Внутри цикла команды выполняют работу, необходимую для достижения целей итерации, включая: планирование, синхронизацию команды, обзор и ретроспективу итерации. Каждая итерация имеет фиксированную продолжительность по времени, которая как правило составляет две недели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели итерации — это высокоуровневое резюме бизнес- и технических целей, о выполнении которых члены Agile команда договаривались на Планировании Итерации. Они крайне важны для координации Agile Release Train (ART) как самоорганизующейся, самоуправляемой команды Agile-команд.

Цели Итерации помогают:

• Обеспечить согласованность членов команды в соответствии с общей целью организации
• Синхронизировать команды относительно общих целей Поезда на Интервал Планирования и помочь в управлении зависимостями
• Обеспечить прозрачность и управляемость для менеджмента

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

Цели итерации предоставляют гибким командам, заинтересованным лицам поезда и руководству информацию и единый язык для поддержания согласованности, управления зависимостями и внесения необходимых корректировок во время выполнения Интервала Планирования (PI).

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

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

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

Доставка

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

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

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

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

Синхронизация Команды (Team Sync)

Синхронизация Команды — короткая встреча, которая обычно проводится ежедневно и занимает не более 15 минут. Цель мероприятия — контроль прогресса в достижении целей итерации, обсуждение и корректировка предстоящей запланированной работы. Команда может использовать любую структуру или технику для проведения такой синхронизации. Результатом Синхронизации команды должен быть понятный всей команде план скоординированных действий на последующие 24 часа.

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

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

На мероприятии Скрам Мастер / Коуч Команды фиксирует темы, которые требуют более детального обсуждения и выносит их за рамки короткой синхронизации. Обычно обсуждение планируется сразу же после Team Sync и называется «встреча-после». На «встречу-после» остаются только вовлеченные стороны, и поднятые темы подробно обсуждаются уже более узким кругом.

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

Инкремент

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

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

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

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

На мероприятии Scrum команда также определяет дальнейшие корректировки для продукта или процесса. Основываясь на представленных результатах, заинтересованные лица и команда обсуждают что делать дальше. Беклог команды также может быть скорректирован с учетом новых возможностей. Продолжительность Обзора Итерации составляет не более 2-х часов для двухнедельной итерации.

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

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

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

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

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

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

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

Участие в System Demo

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

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

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

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

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

Команда отслеживает свой прогресс в рамках Итерации с помощью Канбан Доски (Рисунок 2). Зрелые Scrum команды доставляют истории за Итерацию без выстраивания «водопадного» процесса внутри цикла.

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

Роли в SAFe Scrum

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

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

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

• Владелец продукта (обычно полная занятость) понимает потребности и ожидания клиентов. Он/она отвечает за контент в беклоге команды и расставляет в нем приоритеты. Таким образом Владелец Продукта обеспечивает, что команда работает над нужным продуктом правильным способом.

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

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

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

Однако для оптимизации потока команды должны стремиться доставлять сквозную ценность как можно более независимо. Для реализации более масштабной цели Agile команды в SAFe организации объединяются в команду команд — Agile Release Train (ART). Таким образом создается среда для синхронизации и взаимодействия с другими командами, которые работают над созданием более крупных решений. Такая организационная структура позволяет выявлять зависимости и работать с ними, а также ускорять Поток Команды и Поток Поезда.

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

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

Более подробно детали участия каждой команды в ответственности за доставку ценности для клиентов приведены в статье «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. и не является официальным переводом статьи «SAFe Scrum».