О переходе на Agile-практики и Scrum на Хабре сейчас рассказывают многие компании. Но немногие говорят о том, как этот переход сложен для больших организаций. Всё-таки Agile — это про работу небольших команд. А если таких команд много, как наладить между ними взаимодействие? Классический Scrum не даёт ответа на этот вопрос. Зато его даёт SAFe (Scaled Agile Framework). О том, как мы в Страховом Доме ВСК перешли на SAFe, и расскажем в этом материале. Если интересно, каково по этой системе трудиться разработчику, чем в SAFe занимается менеджмент и какие навыки на всех уровнях выходят на первый план, — скорее переходите под кат!

Что такое SAFe

Действительно, что такое всё-таки Scaled Agile Framework? Если совсем коротко — это надстройка над классическим Agile, которая помогает координировать Agile-команды разработчиков внутри крупного проекта и между проектами.

К примеру, у нас существует важное направление добровольного медицинского страхования. Одна Agile-команда из восьми гениальных разработчиков и продакт-оунера-визионера не вытянет всю разработку по этому направлению. В нём просто слишком много разноформатных, но при этом одинаково важных задач.

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

А если просто расширить Agile-команду? Тогда она, очевидно, потеряет свою гибкость и опять же вернётся к подобию каскадной разработки. Тоже плохо.

Наконец, можно собрать несколько команд для одного направления разработки. Этот вариант вроде бы оптимальный: проектом занимается достаточное количество людей, а разработка остаётся гибкой.

Но если все команды погрузятся в решение собственных задач и не будут общаться, то итог будет плачевный. В лучшем случае отдельные аспекты разработки будут выполнены блестяще, но между ними не будет синергии. А в худшем разработка окажется даже медленнее вотерфольной, потому что между командами, работа которых зависит друг от друга, не будет синхрона.

Собственно, эту проблему решает надстройка SAFe. SAFe-поезда объединяют несколько Agile-команд, а менеджмент этих поездов помогает командам общаться, чтобы задачи, важные для всего поезда, всегда выполнялись своевременно. При этом сами разработчики не тратят своё драгоценное время на коммуникации и постоянные попытки объяснить коллегам из другой команды, что тем нужно оставить все свои дела и выполнить какую-то срочную задачу уже сейчас.

В общем, SAFe помогает делать то же, что и Agile, но с командами из 100 и более человек. К тому же работа по SAFe не ограничивается только созданием поездов. SAFe-практики могут распространяться на все уровни руководства компанией, вплоть до методики Lean Portfolio Management. По ней команды команд в тандеме с высшим руководством компании определяют, какая именно работа необходима, чтобы бизнес развивался органично, быстро поставлял свои ценности и решения клиенту.

Как мы выбрали SAFe и готовились к переходу

Зимой 2020 года, в ходе разработки новой стратегии компании, мы в ВСК окинули свежим взглядом свою классическую модель управления и поняли — нужно что-то менять. Привычный вотерфол больше не отвечал нашим требованиям и ожиданиям. Чтобы удовлетворить запросы клиентов и сделать качественный рывок, компании нужна была гибкая разработка.

Более того, у нас уже был опыт работы в стандартном Agile, но весьма неоднозначный. Когда в 2017 году в ВСК перевели направление дистанса на Agile-разработку, в этом направлении удалось наладить хорошие взаимоотношения между разработкой и бизнесом и совместное интерактивное решение проблем. Плюс, разработка действительно стала во многом проще — некоторые бизнес-решения с айтишниками просто коротко обговаривались, после чего их можно было воплощать в жизнь без бумажной волокиты.

Но были и проблемы. Многие представители бизнес-стороны восприняли методику очень упрощённо. Agile — это когда айтишники работают быстро! Больше не надо составлять и продумывать письменные требования, даже если эти требования очень сложные! Достаточно проговорить их — и программисты примутся за работу. Отсутствовала система приоритезации задач, перед разработчиками постоянно ставили новые срочные задачи, копился технический долг.

Из-за этого впечатления вместо налаженной системы Agile для нас стал набором костылей. Айтишники вместо погружения в разработку тратили время на то, чтобы чётко сформулировать, сделать жизнеспособными предложения бизнес-стороны и клиентов.

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

При этом разработчики в системе трудятся, как в обычном Scrum. А сам принцип работы помогает выявлять слабые звенья в структуре, ведь перед командой всегда стоит прозрачная, регулярно проверяемая задача. Крупной, но ожидаемой проблемой при запуске SAFe стало именно то, что лидеры команд, выбранные на ключевые роли в Agile-поездах, хоть и прошли обучение, но сами не очень понимали, зачем нам SAFe нужен. Из-за чего не очень хорошо доносили информацию по новой системе до своих команд.

Важным преимуществом SAFe для нас стало то, что в нём команда строится вокруг ценности продукта.

Мы решили перейти на SAFe без пилота. Выбрали три стратегически важных направления: агентское, дистанционный сервис и медицинское страхование. В феврале 2020 года мы защитили методологию и архитектуру SAFe перед руководством компании. Реакция была положительной, мы принялись формировать поезда по этим направлениям.

Из-за начала пандемии возник период неопределённости. Мы не стали внедрять новую методику сразу же весной. С мая по август у нас был подготовительный период: мы разбирались, что в работе SAFe-поездов изменится на удалёнке, обучали сотрудников, в том числе лидеров и визионеров, которые должны были в будущем вести за собой, формировали команды. И ещё перекладывали SAFe-подход на наши рельсы: наше системное обеспечение и инструменты в том же Jira.

Главным на этом коротком этапе подготовки стало сформулировать стратегическое видение и задачи для команд. Нужно было разложить сложные глобальные задачи на простые и понятные. Наш совет всем, кто переходит на SAFe: ещё на этапе подготовки создавайте наброски планов уровня портфеля, разбирайтесь в том, какие у вас есть стратегические задачи и как их разделить внутри команд.

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

В команды набирали как старожилов ВСК, так и новичков с опытом работы в Agile и Scrum. В итоге в трёх наших первых поездах собрались 88 участников и 11 Agile-команд. Новичков набралось порядка 40 %. Как оказалось, некоторые специалисты помоложе по большей части работали уже именно с гибкими практиками, так что SAFe их не слишком пугал.

Составляли команды из специалистов разных направлений по компетенциям, в соответствии с теми задачами, которые выявила аналитика для каждого поезда.

Кроме того, мы запустили опрос среди айтишников: цель опроса не раскрывали, но спрашивали, какие роли участники хотели бы занимать в потенциальной SAFe-команде — например, архитектора или Scrum-мастера. С помощью этого опроса мы получили ценную обратную связь. После опроса была проведена оценка потенциальных кандидатов на соответствие требованиям и компетенциям выбранной роли. По итогам часть людей, успешно прошедших оценку заняла свои желаемые позиции.

Конечно, костяк поездов образовали разработчики, аналитики, тестировщики. Роль DevOps при переходе на SAFe-поезда выделилась особенно ярко. Продакт-оунеры пришли из бизнеса, скрам-мастера переквалифицировались из менеджеров проектов.

С начала перехода на SAFe мы запустили с нуля ещё пять поездов. Итого к январю 2022 года у нас уже насчитывается восемь Agile-поездов.

Как в SAFe работается разработчику на уровне Agile-команды

Итак, представим, вы пришли работать в одну из наших Agile-команд. Что вас ждёт?

Вряд ли вы попадёте прямо на начало инкремента. Скорее, окажетесь в эпицентре рабочего процесса: команда будет выполнять свою задачу в рамках спринта, все будут заняты, а что делать вам?

Поскольку SAFe — гибкая методика разработки, коллеги сразу смогут предложить вам полезные для бизнеса и при этом несложные задачи. Долгого изучения многолетней истории разработки не понадобится. Волноваться не о чем: опытные разработчики из вашей команды быстро введут в курс дела и объяснят, чем команда и весь поезд заняты прямо сейчас.

Кстати, вероятнее всего, одной из ваших первых задач станет знакомство и налаживание контактов. Прежде всего — со всеми членами своей команды. Agile-разработка сильно зависит от слаженности, того, насколько у всех её членов хорошие взаимоотношения. Если команда не может общаться, результат точно пострадает.

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

Встречи офлайн редки, происходят, в основном, когда весь поезд собирается для планирования следующего инкремента. Горизонт планирования в SAFe составляет 2,5 месяца. Финальный спринт каждого инкремента как раз посвящён подведению итогов текущего и планированию следующего. Разработчики собираются, делятся результатами, вместе с менеджментом определяют задачи на следующий рабочий период. Естественно, для многих команд, успевших сплотиться онлайн, эта встреча — ещё и хороший повод провести общие командообразующие мероприятия.
Вернёмся к рабочим вопросам. Вы приехали на свою первую сессию PI-планирования (так это называется в SAFe) и немного беспокоитесь. Достаточно ли вы сделали для своей команды? Не ждёт ли вас и ваших коллег разнос? Вы же всё-таки только начинаете работу.

Можем вас успокоить. Во-первых, в SAFe задачи ставятся в начале инкремента для уже собранной команды. То есть ваш приход в команду до очередного PI-планирования не прибавил магическим образом нагрузки вашим коллегам. Эта особенность несколько смягчает адаптацию в методике для новичков.

Во-вторых, разносов на PI-планировании не бывает. Эта встреча в первую очередь нужна затем, чтобы команды взяли на себя посильные задачи на предстоящий инкремент. Итогом PI-планирования является перечень целей по каждой команде, которые оценивают бизнес-владельцем по десятибалльной шкале. Оценка определяет приоритетность поставленной цели для бизнеса, чем выше оценка, тем цель приоритетнее.
Бывают ситуации, когда на PI-планировании цель оценена оценивают на 9, а на систем-демо при подведении итогов инкремента цель получает оценку достижения, равную 5. И это повод не для обвинений (и тем более не для увольнений), а для анализа допущенных ошибок всей командой и даже всем поездом. Так что не бойтесь говорить на планировании о явных и потенциальных проблемах созданного вашей командой решения. Эти данные необходимы вам, вашим коллегам и всей компании для адекватного планирования работы.

Кстати, о посильных задачах. Вы, наверное, задаётесь вопросом — а чем будет заниматься моя команда? Не выйдет ли так, что нас бросят на решение проблем, для которых у нас просто не хватит экспертизы?

Ответ, конечно, «нет». Для SAFe вполне нормально, что некоторые команды внутри поезда занимаются более сложными задачами, например, разработкой новых фич, а некоторые — решают вопросы попроще. И то, чем вы будете заниматься в новом инкременте, зависит не от начальства, а главным образом от вас.

Если вы и ваши коллеги ещё относительно неопытны, не очень уверены в своих силах или среди вас недостаёт узконаправленных специалистов, вряд ли вы заявите на очередном планировании, что готовы быстро и качественно реализовать сложное решение. Обычно мощные команды в SAFe некоторое время вызревают, пока все их участники не соглашаются — пришло время взяться за серьёзную работу, показать себя. Стремление сделать что-то крутое, которое естественно идёт снизу, а не сверху, от руководства, качественно отличает эту методику от каскадной разработки.

Наверное, уже понятно, что задачи любой команды в SAFe-разработке сильно меняются от инкремента к инкременту. А это значит, однажды на этапе планирования вы можете понять, что мало чем поможете коллегам в предстоящей работе. Что делать? Перейти в другую команду. Да, придётся снова налаживать связи с коллегами и вливаться в коллектив. Но зато вы будете решать задачи, которые подходят вашей экспертизе. К тому же ваши связи с коллегами из прошлого коллектива никуда не денутся. Наоборот, помогут наладить сотрудничество и добиться лучших результатов. Такой обмен членами команд тоже сильно укрепляет структуру SAFe-поезда.

Чем занимается в SAFe менеджмент поезда

Теперь, когда понятно, как работается специалисту в одной из команд SAFe-поезда, давайте поговорим о тех, кто этот поезд направляет.

Менеджмент поезда — это три специалиста: системный архитектор, продакт-менеджер и инженер релизного поезда (RTE). Никто из них не руководит поездом в одиночку, все три роли равно важны.

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

Системный архитектор отвечает на вопрос: «Как будет работать будущий продукт?». Это главный технический специалист поезда: в частных вопросах, связанных с разработкой, продакт-менеджер полагается на системного архитектора. На его плечах лежит важная задача — сделать технический дизайн разрабатываемых решений максимально удобным и полезным для будущих пользователей. Это не значит, что архитектор сам принимает все важные дизайнерские решения в начале инкремента, а дальше ждёт от команд их выполнения. Если архитектор так делает, то со своими обязанностями он справляется плохо. Его задача — объяснить всем командам, какие основные принципы нужно соблюдать в разработке решения, а потом следить за тем, как эти принципы эволюционируют во время спринтов, и помогать Agile-командам искать ответы на возникающие вопросы. Какие элементы дизайна необходимы проекту? От каких можно избавиться? Системный инженер отвечает на эти вопросы.

RTE в меньшей степени отвечает за суть реализуемого продукта. Но без этого специалиста Agile-поезд точно встанет или даже сойдёт с путей. Инженер релизного поезда обеспечивает слаженную работу всех команд. Он общается с каждым участником поезда. Подбирает новых людей в команды и перераспределяет ветеранов. Помогает командам распределять задачи из бэклога. По сути он — главный методолог поезда.

Внутри каждой команды RTE не принимает решений, его роль чисто менторская. Например, он может научить, как кратко и содержательно вести дейли, чтобы все высказались за 15 минут и поняли текущее состояние дел. Но не будет следить каждый день за дейли команды: воплощать изученное в жизнь нужно самим.

На PI-планировании продакт и системный архитектор рассказывают о фичах на будущий инкремент. RTE проводит планирование. Здесь он собирает все задачи будущего инкремента на вот такую доску:

На ней отражены все взаимодействия будущей работы: поскольку команды в поезде связаны и делают решения для одного продукта, многим для выполнения своих задач нужно, чтобы задачи выполнили и коллеги. RTE выявляет все подобные связи, составляет на их основе таймлайн инкремента, а после вместе с продакт-оунерами следит за его исполнением.

Кроме того, часто Agile-команды во время спринта взаимодействуют со смежниками, работающими по традиционным методикам. Без RTE общение со смежниками сильно затруднено: у тех свой месячный план и помощь Agile-поезду в него не входит. Именно RTE с помощью своих выдающихся софт-скилов должен наладить с внешними командами хороший контакт, чтобы разработчики не отвлекались от, собственно, разработки.

Вообще, суть менеджмента поезда в том, чтобы дать разработчикам разрабатывать, не отвлекаясь на реализацию громоздких бизнес-аспектов проекта. Помимо ежедневных контактов с командами разработки, менеджмент поезда участвует в мероприятиях — демо и ретроспектива.

Заключение

С момента запуска наших первых SAFe-поездов прошло 1,5 года. Постепенно мы планируем перевести всю разработку внутри компании на SAFe, а пока инкремент за инкрементом улучшаем работу уже существующих команд. Для успешной разработки нужно постоянно и внимательно прислушиваться к запросам клиентов и запросам внутри своей команды. Основанный на синтезе хард- и софт-скилов SAFe помогает успешно это делать и эволюционировать даже крупной компании.