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