Специфика работы Agile-команды в SAFe относительно Scrum на практике | Амплеев Евгений - Scrum Master / Full stack web developer
Читаете:
Специфика работы Agile-команды в SAFe относительно Scrum на практике
Поделиться:
heart interface icon418

Специфика работы Agile-команды в SAFe относительно Scrum на практике

Avatar
Автор статьи: Yevgeniy Ampleev
04 февраля 2020 в 15:59
Image

После публикации среди друзей первой статьи о Burn Down Chart, в комментариях первый вопрос, который был задан: "Было бы интересно узнать подробнее про ваш опыт с SAFe". Поэтому, в этой статье я постараюсь раскрыть специфику работы в SAFe относительно Scrum на нашей практике. Я точно не претендую на истину в первой инстанции и буду рад любым исправлениям и уточнениям со стороны коллег.

Сначала перечислю тезисно самое основное, что отличает работу в SAFe от SCRUM, на мой взгляд.

  • Increment в Scrum и Program Increment в SAFe
  • ART - Agile Release Train
  • Количество взаимодействующих команд
  • PIPE
  • SOS
  • PO - не собственник бизнеса
  • RTE
  • Пятый спринт для обучения
  • System Demo

Increment в Scrum и Program Increment в SAFe. На самом деле разные термины, но в них легко запутаться т.к. никто не использует у нас термин Program Increment, все говорят просто Increment - а это уже другой термин, который используется в SCRUM. Но в целом они достаточно похожи с точки зрения смысла, на мой взгляд. Increment в SCRUM - это по сути текущий продукт + запланированные истории на спринт в выполненном состоянии (прошедшие DOD команды). Program Increment - это временной интервал в течение которого поезд (Agile Release Train) доставляет инкрементальную ценность в продакшн. По длительности у нас это 4 спринта по 2 недели на разработку и один спринт на обучение.

Agile Release Train - это команда команд, работающих над одним потоком создания ценности. Мы это называем просто поездом, но по фреймворку правильно это называть "Solution". В нашем случае, это правило не полностью соблюдается и команды часто работают над разными продуктами с технической точки зрения, т.к. большинство бизнес-фич реализуется комплексно и затрагивают несколько продуктов. Это с технической стороны. Но, уверен, что кто-то считает все it-системы одним продуктом компании и, возможно, так даже правильнее.

Количество взаимодействующих команд у нас в SAFe существенно больше, в сумме рекомендуется до 125 человек в одном поезде. У нас 3 поезда и не в каждом это правило соблюдается, есть поезда с количеством более 125 человек. SCRUM не описывает как взаимодействовать с другими командами, на сколько мне известно, в отличие от SAFe, где есть очень четкие рекомендации по этому поводу. Самый яркий, на мой взгляд, артефакт для этого - это Program Board.

Image

На нем отображаются взаимосвязи между командами поезда и, обсуждая его, проходят еженедельные мероприятия Scrum Of Scrums (SOS) у нас.

Примерно каждые 2,5 месяца (каждые 5 спринтов) происходит событие PIPE - Programm Increment Planning Event. Это когда все распределенные команды собираются в одном зале на 2 дня и планируют свои работы на следующие 2,5 месяца. В процессе этого мероприятия появляются такие артефакты, как Program board, например, на котором отображаются все зависимости команд между собой для каждого из поездов, выше я уже показал как он выглядит. Задачей Скрам Мастера каждой команды на этом мероприятии является фасилитация выявлений максимального количества зависимостей, затем по-возможности, их удаление (посредством передачи компетенций устно, например, от команды команде или посредством забора зависимости от одной команды в другую, чтобы команда могла автономно реализовать свою фичу ни от кого не зависив). На практике это у нас так и происходит. Сначала декомпозируются фичи на User Story, User Story раскидываются по 4 спринтам. Фичи размещаются на Program Board и выставляются зависимости от других команд какие есть. В течение мероприятия это обсуждается, корректируется.

SOS - Scrum Of Scrum. Это мероприятие проходит раз в неделю для каждого поезда отдельно. Скрам Мастера всех команд поезда собираются в онлайне, транслируется Program Board поезда и обсуждаются статусы всех зависимостей и фичей команд конкретного поезда. По сути это мероприятие необходимо для центролизованной синхронизации команд внутри поезда. Что-то вроде стендапа, но раз в неделю и не для команды, а для Скрам Мастеров.

PO (Product Owner) - не собственник бизнеса. Есть Product Manager - он работает с Bussiness Owner'ами соответствующих направлений бизнеса и по сути раздает фичи Product Owner'ам. Product Owner работает уже непосредственно в команде - бъет фичи на User Stories (в нашем случае совместно с командой) и не всегда бъет, но мы постоянно прогрессируем в этом направлении.

RTE (Release Train Engineer - машинист поезда. Скрам Мастер Скрам Мастеров. Проводит мероприятия SOS своего поезда. Взаимодействует с Product Manager'ом на уровне фич. Фасилитирует PIPE.

Пятый спринт для обучения - да, в отличие от Scrum, здесь выделен команде целый спринт в конце инремента на обучение. Мы, как правило, на практике используем его в первую очередь для посещения тренингов внутренних в том числе и по SAFe, но не только. Частные курсы и митапы стараемся планировать на это время по возможности. Также у нас есть разработчики, которые расширяют свой стек в течение 5 спринта, чтобы была возможность закрыть чью-либо компетенцию в команде (подстраховать при необходимости).

System Demo. В результате PIPE у каждой команды есть список целей на инкремент и каждая из этих целей оценена Buisseness Owner'ом поезда по 10-бальной шкале. Это называется Business Value. Цели эти делятся на основные и расширенные. Основные цели - это цели, в которых команда не видит никаких рисков в достижении. Расширенные - это цели с рисками достижения. Все цели обязательные и объем работ планируется под все цели. На System Demo Business Owner принимает результаты работы за инкремент. Допустим, у команды было 3 основных цели с оценками 10, 6, 8 и 2 расширенные с оценками 10, 3. Представим, что Business Owner поставил соответственно оценки следующие: 8, 6, 4, 2, 0. Теперь можно посчитать процент достижения целей: за 100% берется изначальная сумма балов за основные цели, в нашем случае это 10+6+8=24. Достигнутые баллы считаются с учетом расширенных целей(т.е. 20 из 24 команда достигла), т.е. в результате процент достижения целей у команды будет (20*100)/24 = 83,3%. Нормальным результатом считается достижение от 80% до 100%.

Во всем остальном мы работаем по SCRUM. Ну или почти во всем :) Что касается нашего опыта: могу сказать, что, с моей точки зрения, эволюция очевидна. За год работы команды сильно выросли, стали самоорганизующимися, какие-то команды, правда, развалились, но и в этом просматривается определенная эволюция. Расти тоже еще есть куда.

Комментарии коллег из facebook

«Женя, привет! Круто, что пишешь, молодец! Чуть поправлю про поезда - собираются они не вокруг продукта, а вокруг потока создания ценности. А в рознице у нас с точки зрения SAFe не поезд, а Solution. Просто для удобства коммуникации и упрощения понимания, мы продолжаем называть это поездом)»
Константин Воронин (представитель проектного офиса Ингосстраха)
«Ну и может кто-нибудь заметит, что с точки зрения SAFe оценка целей проходит на I&A (куда SD входит как часть, но напрямую с оценкой не связан) а сами SD должны проходить каждый спринт (после демо команд). Но мы пока от этого далеки, поэтому осознанно называем все как написано у тебя в статье)»
Константин Воронин (представитель проектного офиса Ингосстраха)
«Женя, продолжай, пожалуйста, очень полезно!»
Алексей Ионов (Сертифицированный тренер по SAFe)


    Добавить комментарий
    divider graphic

    Возможно, вам будет интересно

    Image
    14 декабря 2019 в 08:54
    heart interface icon290

    Практика использования персонального рейтинга каждого члена команды в контексте Scrum и SAFe

    В этой статье я планирую рассказать как на своей практике мы считаем и применяем персональный рейтинг каждого члена команды в Scrum в процессе работы по фреймворку SAFe

    Image
    Yevgeniy Ampleev
    Image
    20 февраля 2020 в 09:56
    heart interface icon215

    Как заставить микросервисы общаться? Часть 1.

    В этой статье мы постараемся разобраться в одном из подходов к построению микросервисной архитектуры

    Image
    Yevgeniy Ampleev
    arrow-up icon