Сначала перечислю тезисно самое основное, что отличает работу в 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.
На нем отображаются взаимосвязи между командами поезда и, обсуждая его, проходят еженедельные мероприятия 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)