Привет, меня зовут Василий Юзов, и я Chief Product Owner в небольшой, но очень гордой IT-компании. У нас 12 продуктовых команд, которые разрабатывают различные решения для автоматизации и цифровой трансформации бизнеса и государства. 

Вообще, мы обычная команда полного цикла разработки. Работали в командах, использовали Agile, Scrum, где-то взлетало, где-то не очень… В какой-то момент все начало разваливаться. Вроде все делаем как всегда: много работаем, делаем дофига и чуть больше, команда растет… Но техдолг тоже растет, и недовольство клиентов растет. И все чаще ребята стали приходить в состоянии “я так больше не могу, пристрелите меня”. 

Мы честно пытались что-то “починить”, взять новых крутых senior’ов, мотивировать и стращать ребят деньгами и всякими материальными и не очень плюшками и фишками. Но в какой-то момент поняли, что менять нужно все и кардинально. Надо все сломать и просто заново выстроить процесс разработки. И решили попробовать фреймворк SAFe®.

Если вы знаете, что такое SAFe®, то просто проскрольте эту часть. Если же нет, то перед тем, как продолжить рассказ, сделаю небольшой экскурс в предмет.

Что такое SAFe® и как оно работает

SAFe® (Scaled Agile Framework)  — один из популярных фреймворков масштабирования Agile для крупных IT-проектов. Как видно из названия, SAFe® - это про то, как масштабировать Agile. Т.е. если одна команда работает по Agile - все понятно, если две, то тоже. Но если у вас несколько команд, которые связаны (или зависят друг от друга), то неизбежно возникают сложности, связанные с синхронизацией работы. SAFe® позволяет устранить рассинхрон и наладить бесперебойный процесс. Считается, что SAFe® подходит для крупных компаний, общей численностью 500 и более человек. Но нас это вообще не остановило)

Разработка продукта по SAFe® ведется так называемыми “поездами” - Agile Release Train (ART). ART - это долгоживущая команда Agile команд, которая совместно с другими заинтересованными сторонами разрабатывает и поставляет продукт. Метафора поезда тут более чем уместна: все, что “вошло” в поезд - берется в работу, что не вошло - увы, ждет следующего. 

Чтобы загрузить этот “поезд”, проводят специальное мероприятие - PI-планирование (потому что Program Increment - это как раз таки набор фич, которые в итоге войдут в поезд). Планируются, как правило, на продолжительный период, примерно на квартал. Внутри квартала команды работают в рамках двухнедельных спринтов. Там они уже сами решают, по какой методологии им работать - Kanban, Srcum или любой другой Agile-инструмент. Сами же авторы фреймворка рекомендуют использовать Scrum с примесью экстремального программирования (ScrumXP).

Подробно про фреймворк можно почитать на официальном сайте. 

Чтобы что?

Осознание проблемы - первый шаг к ее решению. Поэтому сначала мы честно признались себе в своих ошибках и сформулировали ответ на вопрос “зачем” - зачем нам нужно что-то менять.

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

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

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

Очевидно, что мы не первые, кто столкнулся с такими сложностями, мы решили не изобретать велосипед, а посмотреть мировую практику. В результате все свелось к выбору между LeSS (Large Scaled Scrum) и SAFe®. Выбрали мы SAFe®, потому что он более:

1. формализован - у него более четкое описание процессов;

2. распространен, а значит, у него большое комьюнити, можно задавать вопросы единомышленникам, перенимать чужой опыт.

Запрягаем коней

Все, мы решились. Давайте внедрять. Открываем “инструкцию”, читаем пункт первый:

“Возьмите ваши Agile-команды…”

Так, стоп, а у нас есть Agile-команды?... До этого момента каждая команда “жила” так, как ей нравилось. Да, большая часть использовала так или иначе фреймворк Scrum, но явно требовалась определенная синхронизация и выравнивание даже на уровне понятийного аппарата, чтобы все разговаривали на одном языке.

Поэтому перед тем, как внедрять, мы слегка подготовились. Для начала прошли обучение на Scrum Master в SAFe® (6 человек), SAFe® Product Owner & Product Manager (3 человека) и SAFe® Scaled Agile Engineer. После мы организовали и провели ряд обучающих мероприятий внутри компании, чтобы подготовить плацдарм для изменений. 

Примерка

Мы регулярно что-то меняем, внедряем, трансформируем и т.д. Чтобы минимизировать потери от неудачных решений, мы используем “примерку”: перед тем, как раскатать что-то на всю команду и на все процессы, мы пробуем на каком-то усеченном варианте, что получится. Чаще всего - это либо какая-то одна команда, либо просто короткий промежуток времени. Например, для внутренних процессов обычно хватает двух недель, чтобы понять, нет ли вреда от нововведения, и при необходимости откатить все назад без особых потерь. Fail fast, так сказать. Зашло - развиваем, нет - ну и ладно, зато попробовали. 

SAFe® мы тоже «примеряли». Правда здесь двумя неделями было не обойтись. По классике стандартный цикл во фреймворке длится 3 месяца, мы решили попробовать спланировать PI на месяц: 2 производственных спринта + IP-итерация на неделю. Конечно, так никто не делает. Просто потому, что само по себе “PI-планирование”, как мероприятие, довольно-таки сложное и дорогое удовольствие. Нужно “вырвать” на 2 дня из производстводственного процесса и собрать в одном месте все команды и заинтересованных представителей “бизнеса” внутри компании. Но мы решили, что это невысокая цена для проверки нашей гипотезы. 

Наше первое PI-планирование

Состав

В начале августа 2021 года мы вывезли 80 человек за город, чтобы понять, во что мы ввязываемся. Мы решили, что нам нужны:

• CTO и CPO,

• представители бизнес-подразделений, которые непосредственно общаются с заказчиками,

• продуктовые команды со своими PO и Scrum-мастерами, 

• UI/UX дизайнер для экспертной оценки возможных интерфейсов, т.к. это может повлиять на бэкенд,

• представители сопровождения, которые отвечают за внедрение, тиражирование и поддержку пользователей,

• системные администраторы. 

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

Регламент и повестка

Т.к. в мероприятии участвует много людей (80 - это же много), и нужно обсудить и решить большое количество вопросов, у PI-планирования всегда жесткий регламент. Согласно SAFe®, оно должно проходить 2 дня, но мы решили, что примерку проведем за день, т.к. планируем задачи всего на месяц. 

Планирование мы начали с короткого бизнес-контекста, после чего все вместе повторили теорию, и понеслось. 

Для начала командам нужно было посчитать capacity - свою производительность по спринтам с учетом всех известных событий: отпусков, новых внедрений, которые требуют ресурсов команды, и т. п. После шла оценка историй из бэклога и распределение этих историй по итерациям. Тут мы немного добавили огня для ребят, потому что решили заодно уйти от оценки задач в часах и начать мерить их в Story Points (SP). Для большинства это был новый и интересный опыт.

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

Все хорошо, но надо переделать

Не то, чтобы мы думали, что все пройдет легко и гладко... Скорее наоборот, мы знали и очень ждали каких-то интересных ситуаций. И вот во время ревью целей в одной из команд мы поняли, почему авторы методологии настаивают на проведении PI-планирования в 2 дня. Ребята из “бизнеса” увидели, что критичная для клиента фича не попадает в «поезд» и быстро переиграли приоритеты. Команде пришлось перестроить свой план работ на планируемый период. И все бы ничего, если бы не те самые пресловутые зависимости между командами. Смена приоритетов в работе одной команды нарушила зависимость от другой команды, которой тоже пришлось оперативно перестраивать свои спринты. Нам “повезло”, что мы планировали всего лишь 2 спринта (а не 6), поэтому удалось быстро все переиграть и исправить. 

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

Первый Program Board

В результате PI-планирования мы получили Program Board со всеми запланированными историями и выявленными зависимостями. Существует мнение, что на доску есть смысл выносить только зависимости, но команда решила зафиксировать на доске все истории, которые попали в «поезд». Таким образом мы визуализировали свой план на август:

Естественно, позже все переехало в Miro:

Небольшие пояснения по доске. Зеленые стикеры в конце спринта — это цели команды. Грустный смайлик означает, что цель не достигнута. Кстати, многие команды включают в цель спринта несколько пунктов, и мы договорились, что цель считается достигнутой, только если сделаны абсолютно все пункты. Это помогает нам учиться ставить понятные и адекватные цели. 

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

Выводы и итоги

Задача любой примерки - быстро попробовать новую методологию с минимальными рисками для команды и компании. А еще это очень помогает быстро найти “грабли” и наступить на них, пока они маленькие и не достают до лба. Проведя наше первое тестовое PI-планирование, мы для себя сделали несколько важных выводов: 

• Важно иметь проработанный до уровня User Story бэклог. При этом у команд не должно быть не решенных до PI-планирования вопросов по самим историям и критериям их приемки. 

• PI-планирование должно проходить 2 дня.

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

• Program Board лучше сразу делать в Miro и выводить ее через проектор на экран.

Для того, чтобы сделать полноценный вывод, зашла примерка SAFe® или нет, нужно, конечно же, посмотреть на результаты всего PI. И я обязательно расскажу, что мы вынесли из первого мини-поезда. Но забегая вперед, скажу, что процессы стали гораздо прозрачнее и мы активно внедряем SAFe® . Мы провели еще 2 планирования, и наш третий PI уже мчится на всех парах.