ScrumXP — Agile-команды на масштабе. Часть 2: Практика

В первой части статьи мы рассмотрели теорию ScrumXP. Настала пора перейти к практике.

Чтобы помочь всем заинтересованным разобраться в этой части SAFe, я попросил помочь мне SAFe-практиков:

• Павел Озолин, Ozolin LLC. SPC, RTE, PSM II, PSPO I, PSK, SPS, CSM, a-CSM, CSP-SM.
• Никита Поселянов, NetCracker. SA, SPC, SaSM.
• Дамир Гарифуллин, Ак Барс Цифровые Технологии. SA, SSM, PSM I, PSPO I.

ScumXP — Scrum в SAFe

В российских компаниях я вижу два подхода к “использованию” Scrum:

1. Фреймворк, помогающий создавать ценность за счёт множества петель обратной связи и работы с ней.
2. Способ организации работы IT-команд.

Ни один из этих вариантов не является плохим или хорошим сам по себе. И уж точно они не говорят ничего о качестве Scrum, каким его задумывали его авторы: Кен Швабер и Джефф Сазерленд.

Со ScrumXP наблюдается похожая картина. И каким именно образом будут работать Agile-команды в вашем контексте зависит только от вас. Тогда в чем же разница? Зачем в Scaled Agile Inc. решили изобрести что-то своё, если можно было просто использовать Scrum?

Если убрать события ART, то ScrumXP от Scrum отличается некоторыми названиями событий, разделением бэклога программы и бэклога команд и отсутствием описанного механизма отмены итерации. В целом, в ScrumXP сохраняется требование к командам поставлять каждую итерацию ценный инкремент и, на мой взгляд, это самое важное.

Дамир Гарифуллин, Ак Барс Цифровые Технологии

Чтобы говорить на одном языке, нужно определиться со словарём:

На первый взгляд, различий и правда не много. Они, тем не менее, есть и прячутся в деталях. И все они вытекают из фундаментального отличия Scrum и SAFe.

Основная единица Scrum — небольшая команда людей, Scrum Team.

Руководство по Scrum

В то время, как в SAFe минимальной боевой единицей является ART. Сам контекст применения фреймворка говорит: если вам достаточно одной команды для создания ценности, то SAFe вам не нужен.

Давайте рассмотрим работу ScrumXP, её отличия от “ванильного” Scrum и попробуем понять плюсы и минусы в разрезе:

1. Ролевой модели.
2. Событий.
3. Самоуправления Agile-команды.

Ролевая модель

В Руководстве по Scrum от 2020 года есть только одна Scrum Team, сфокусированная на общей цели, с тремя разными зонами ответственности: Product Owner, Scrum Master и Developers. ScrumXP говорит о двух ролях в Agile-команде: Владелец Продукта (Product Owner, PO) и Scrum-мастер (Scrum Master, SM).

Владелец Продукта

Роль PO — самая спорная часть SAFe. С точки зрения ScrumXP PO все тот же ключевой авторитет по приоритетам и содержимому бэклога, что и описан в Руководстве по Scrum. Но с точки зрения всего PI (Program Increment) влияние PO на бэклог ограничено как планом PI, так и ролью Продуктового Менеджмента (Product Management, PM), который управляет общим бэклогом PI. Это лишает PO возможности гибко реагировать на обратную связь, полученную командой, и в целом удлиняет цикл обратной связи.

Павел Озолин, Ozolin LLC

В SAFe она «порезана» на разные области ответственности — PO на уровне команды и PM на уровне работы с клиентами и заинтересованными лицами для выявления потребности

Дамир Гарифуллин, Ак Барс Цифровые Технологии

Действительно, в SAFe существует роль PM. Она отвечает за выявление потребностей клиента, приоритизацию фич и разработку Концепции и Дорожной Карты программы. В качестве примера давайте рассмотрим ART, развивающий ипотечное кредитование. В таком случае PM может быть человек, отвечающий за развитие ипотечного кредитования в банке, владелец PnL (Profit and Loss, Доход и Убытки). “Вот он, настоящий PO” — скажете вы. И будете правы. Но если бэклог или количество команд становится слишком большим, то он не может качественно выполнять всю ту работу, которую должен выполнять PO. Для того, чтобы он не стал узким горлышком, а ART и команды могли двигаться вперед, было предложено такое разделение на зоны ответственности.

Всегда ли мы говорим об отдельном человеке? Нет, не обязательно, тем не менее, чаще всего это так.

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

Никита Поселянов, NetCracker

Хорошо это или плохо, каждый решает для себя сам. Могу лишь сказать, что это работает и, часто, весьма достойно. Особенно, если в вашей имплементации вы справились с тем, чтобы не превратить PO Agile-команды в секретаря PM.

Scrum-мастер

Scrum-мастер остается Scrum-мастером, описанном в Руководстве по Scrum. ScrumXP и SAFe в целом предполагают наличие дополнительных обязанностей, связанных с фасилитацией PI Planning и других событий в течении PI. В остальном это тот же самый Servant Leader и адвокат Scrum для команды и организации.

Павел Озолин, Ozolin LLC

Но работа в крупном предприятии накладывает ряд ограничений. Все регламенты, транслируемые предприятием, должны быть понятны и имплементированы на старте работы Команды. Scrum-мастер должен понимать, почему они появились и какой цели служат. Это требует от Scrum-мастера определенного объема компетенций в различных областях знаний.

Навык системного мышления является обязательным для Scrum-мастера в корпорации, ведь то, что является препятствием для команды, может быть обязательным элементом существования предприятия. Например, обязательный для исполнения эмитентами карт Visa, MasterCard и МИР, PCI-DSS (Payment Card Industry Data Security Standard, стандарт безопасности данных индустрии платёжных карт) явным образом требует, чтобы “результаты code review рассматриваются и согласовываются с руководством до выпуска ПО”. Просто так избавиться от “лишнего” согласования выпуска не выйдет. С другой стороны, за долгие годы существования компании в ней неизбежно копятся “организационный” и “бюрократический” долги. У меня нет на руках статистики, но выглядит логичным, что чем больше предприятие, тем выше у него будет уровень таких типов долгов. А значит и потенциал, который Scrum-мастер может высвободить.

Soft-skills — это еще один набор ключевых навыков для Scrum-мастера в корпорации. Надо уметь взаимодействовать и доносить информацию не только до “мини-CEO” PO и разработчиков, но еще и до множества заинтересованных лиц и, что хуже, тех, кого я называю незаинтересованными лицами. На предприятии работает большое количество менеджеров, отвечающих за разные функции и процессы и в силу множества разных факторов индифферентно относящихся к Scrum-мастеру, Agile-команде и их продукту в целом.

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

Никита Поселянов, NetCracker

События

Стоит отдельно поговорить про два события SAFe, которые часто вызывают вопросы у тех, кто с SAFe не знаком: Обзор Итерации (Iteration Review) и Системную Демонстрацию (System Demo). Обзор происходит раз в Итерацию в Командах, а Системная Демонстрация раз в Итерацию на уровне ART.

Фактическая имплементация у всех своя, но в сложных системах надо продемонстрировать и получить обратную связь на интегрированный инкремент всех команд. Любой другой “инкремент” смысла для программы не имеет. Поэтому кто-то отказывается от Обзоров Итераций в пользу общей Системной Демонстрации, кто-то делает два события, а кто-то проводит Системную Демонстрацию раз или два в PI, потому что чаще не позволяют имеющиеся ограничения.

Обзор должен делаться исключительно на основе работающего, готового к поставке решения, синхронизированного с другими командами. То есть не получится делать обзор в состоянии «работает у меня на машине». «Показывать только на общем стенде» стоит рассматривать как часть Definition of Done.

Павел Озолин, Ozolin LLC

Отдельных Обзоров Итерации мы не делаем. Мы объединяем два события — Обзор Итерации и Системную Демонстрацию. Это позволяет командам продемонстрировать результат за Итерацию, в том числе другим командам. А главное, показать реальный прогресс по реализации Фич вместе с другими командами. Такое решение мы приняли из-за опасений, что заинтересованные лица не найдут время чтобы посещать n+1 событий, где n — количество команд.

Дамир Гарифуллин, Ак Барс Цифровые Технологии

Мы разделяем эти два события. В моей среде Обзор Итерации, зачастую, превращается в отчет PO: мы поработали 2 недели — посмотрите, что мы сделали. Вот Acceptance Criteria, вот Definition of Done, вот PO, вот событие по Обзору Итерации. ART демонстрирует интегрированный инкремент раз в 2 Итерации. На них бывает сложно вовлечь Представителей Бизнеса (Business Owners, BO): они не хотят смотреть, как собирают феррари — они хотят сесть и поехать. Но посмотреть инкремент и дать обратную связь могут Эксперты Предметной Области (Subject-Matter Experts, SME).

Никита Поселянов, NetCracker

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

Самоуправление Agile-команды

Диктат XP

То, что в ванильном Scrum является хорошими рекомендуемыми техническими практиками, в ScrumXP становится обязательным: Test-Driven Development (TDD), User Stores, Continuous Integration и прочее. С одной стороны, это хорошо, потому что повышает технический уровень команды. С другой, это лишает команду выбора инструментов самосовершенствования.

Павел Озолин, Ozolin LLC

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

Никита Поселянов, NetCracker

Очевидно, что Scrum не лишает команды технической гибкости. Он оставляет выбор за командой. ScrumXP, в этом смысле, ограничивает команды, говоря им: “У нас в организации есть определенные стандарты и руководства, которым надо соответствовать”. С другой стороны, я не могу не согласиться с Никитой: когда мы говорим о больших и сложных продуктах, реального выбора, использовать лучшие технические практики или нет, просто не стоит. И да, предприятие может и должно задавать стандарты.

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

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

Никита Поселянов, NetCracker

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

Павел Озолин, Ozolin LLC

Ответственность за продукт

Тот же PSI-DSS диктует, что “существует разделение обязанностей между сотрудниками, занимающимися средами разработки/тестирования ПО, и сотрудниками, занимающимися средой производственного функционирования ПО”. Снятие подобных ограничений в пользу повышения ответственности команды за продукт может привести к плачевным последствиям.

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

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

ИТ-ландшафт в корпорации — штука достаточно сложная. Не так часто можно встретить крупную компанию, которую на старте трансформации можно (вопрос целесообразности пока отложим) разделить на идеальные фиче-команды (команды, обладающие всеми навыками, необходимыми для end-to-end реализации Фичи). Но это не значит, что к этому нельзя или не нужно стремиться.

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

Дамир Гарифуллин, Ак Барс Цифровые Технологии

Вполне вероятно, что некоторое время, помимо потоковых команд (Stream-Aligned Teams), у вас будет несколько команд другого типа, например, команды сложных подсистем (Complicated subsystem team).

И одним из вызовов неминуемо станет передача ответственности за продукт таким командам.

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

Никита Поселянов, NetCracker

Нужно искать тот баланс, который будет оптимальным для достижения целей вашей компании.

Заключение

Если у нас бюджетирование на год, откуда возьмется мотив и откуда возьмется автономия у команд и PO?

Никита Поселянов, NetCracker

Бюджетирование является главным вопросом при имплементации любого фреймворка, в том числе Scrum и SAFe. Ответ на него нельзя найти в Руководстве по Scrum или на курсах по фасилитации. Один из вариантов есть на сайте SAFe — это Lean-бюджетирование (Lean Budgets). Другой вариант есть в программах экономических факультетов и MBA — это скользящий бюджет (rolling budget). Но вопрос бюджетирования и передачи ответственности за PnL в руки PO или PM должен быть рассмотрен и решен в рамках Agile-трансформации, иначе он может стать тем самым препятствием, которое заблокирует или сильно затормозит прогресс команд, продукта и всей компании. Но это не вопрос текущей статьи.

Я надеюсь, что данная статья помогла вам разобраться с тем, как в SAFe работают команды, применяющие ScrumXP. С какими сложностями они сталкиваются и как их решают. Ну, или пытаются решить. Часть мифов развеяна и, наверняка, часть новых создана. Я лишь надеюсь, что священных войн станет меньше, а конструктива больше. Огромное количество инструментов лежат вокруг в ожидании, что вы возьмете их и начнете правильно применять. Дерзайте!

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.