Как стать автором
Обновить

Как мы “примеряли” SAFe

Управление разработкой *Agile *Управление продуктом *
Из песочницы

Привет™, меня зовут Василий Юзов, и я 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™, Scrum или любой другой™ 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® Agile Software 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 со всеми запланированными историями и выявленными зависимостями. Существует мнение™, что на доску есть смысл выносить только™ зависимости, но команда решила™ зафиксировать на доске все истории, которые попали™ в «поезд». Таким образом мы визуализировали свой план на август™:

 Наш первый Program Board
 Наш первый™ Program Board

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

Program Board в первом PI
Program Board в первом™ PI

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

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

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

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

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

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

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

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

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

Теги:
Хабы:
Всего голосов 6: ↑5 и ↓1 +4
Просмотры 2.4K
Комментарии Комментарии 2