Для скорости и гибкости нужны кросс-компонентные фиче-команды

2024-11-20 18:49 Scrum

Скрам-команды доставляют ценность на рынок каждый Спринт:

Скрам-команды являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Спринте (Руководство по Скраму).

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

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

Посмотрите на Бэклог Продукта одной из продуктовых групп, с которой я работал.

Бэклог Продукта одной из продуктовых групп

Для того, чтобы создавать ценность каждый Спринта необходимо вносить доработки в несколько архитектурных компоненты: Web, Siebel, App, Portal, Sales Force.

К сожалению, типичное Аджайл-внедрение выглядит так:

Формируются компонентные команды Web, Portal, Sales Force, App;
К каждой команде прилагается локальный “Владелец Продукта”, который отвечает за локальный “Бэклог Продукта” (надеюсь, вы понимаете, что Web, Sales Force, App это не продукты)

Типичное Аджайл-внедрение, типичный SAFe

К слову, так выглядит типичное SAFe внедрение! Вдохновители подобных конструкций опираются на ошибочные ментальные модели:

“Скрам это командный фреймворк”: нет, Скрам не командный, а продуктовый фреймворк, который прикладывается к продуктам, приносящим прибыль (PnL), а не к командам;
“Если части (Web, Portal, Sales Force, App) будут продуктивны и эффективны, то и целое (продукт) будет в выигрыше”: нет, потому что производительность системы зависит от взаимоотношения частей, а не от того, насколько они эффективны по отдельности (законы Рассела Акоффа).

Создание локальных “Бэклогов” и “Владельцев Продуктов” приводит к тому, что система наполняется многочисленными очередями. А это порождает асинхронные зависимости между командами, и поэтому доработки происходят в различных Спринтах.

Пример асинхронных зависимостей в большом ритейлере

Команды “продуктивно и эффективно” заливают систему начатой незавершенной работой (WIP). Работа, которая должна заканчиваться в Спринт, “переезжает” от Спринта к Спринту. Чем занимаются Скрам-мастера и “Владельцы Продуктов”?

Управляют зависимостями, оттачивая навык декорирования электронных и физических дашбордов красными нитками.

Декорирование дашбордов красными нитками

Давайте говорить начистоту. Принципы Аджайл Манифеста грубо нарушаются:

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

Переходим к кросс-компонентным фиче-командам

Не стоит отчаиваться, если вы узнали свои процессы и организацию в описании выше. Смахнем скупую слезу и разберемся, как можно исправить ситуацию.

Секрет гибкости и скорости—в создании кросс-функциональных и кросс-компонентных команд, работающих из общего Бэклога Продукта.

И вот, что вы должны понимать самое важное о фиче-командах. Посмотрите на картинку ниже.

Компонентные команды имеют бизнес-зависимости, а фиче-команды зависимости на уровне кода

Самое большое отличие компонентных от фиче-команд заключается в том, что они имеют различные типы зависимостей.

Компонентные команды. Имеют зависимости на уровне бизнес-логики, что порождает длинные релизные циклы и проблемы для бизнеса, которые мы обсуждали выше. С другой стороны, компонентные команды имеют эксклюзивный доступ к своей песочнице (компоненту). Закрытая кодовая база и сильное владение кодом является предохранителем от явной глупости. С таким сетапом можно худо-бедно жить, даже если нет авто-тестов, существует большой технический долг и низкий уровень инженерной культуры.

Фиче-команды. Автономны и в идеале доставляют фичи без задержек за итерацию (Спринт), что дает преимущества бизнесу. Тем не менее, появляется новый тип проблем. Теперь команды работают в общей архитектурной песочнице. Любая фиче-команда может внести изменения в соседний архитектурный компонент. К счастью, с этой сложностью можно успешно справиться, вооружившись современными инженерными практиками (авто-тесты, чистый код, строгие архитектурные стандарты, непрерывная интеграция, inner source подход). Так работают ведущие мировые компании, например, Google, Microsoft. В дополнение к инженерным практикам потребуются дополнительные координационные механизмы:

Сообщества: архитектурное, UI/UX, CI/CD и другие, участники которых регулярно встречаются и вырабатывают общие стандарты и подходы, распространяют знания между командами;
Менторы компонентов: глубокие специалисты в компонентах / функциях, к которым можно обратиться за помощью;
Путешественники: редкие спецы, которые переходят от команды к команде, заполняя дыры и обучая команды;

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

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

Например, так работают команды в кейсе Pasha Pay: 10 фиче-команд специализируются в трех клиентских доменах для снижения когнитивной нагрузки (розница, бизнес, внутренние клиенты).

Фиче-команды в Pasha Pay берут работу из общего Бэклога Продукта, что устраняет асинхронные зависимости

Постепенный переход к фиче-командам

Частое возражение—у компании большое количество архитектурных компонентов. Согласитесь, непрактично создавать команды численностью 20-30 человек. Слишком дорого.

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

Siebel + ESB + Database
Portal + Web + App
Web + Sales Force

Далее планируйте перекрестное обучение и расширяйте кросс-компонентность со временем. Помните, что люди могут учиться и осваивать новые технологии. Я часто использую инструмент Feature Adoption Map для подобных эволюционных внедрений.

Планируем плавный переход с помощью Feature Team Adoption

Если вы хотите основательно разобраться в фиче-командах, которые оптимизируют скорость и гибкость, то добро пожаловать на сертификационный тренинг Certified LeSS Practitioner (CLP). Увидимся, друзья!

Основные мысли

Когда продуктовая стратегия требует высокой скорости и гибкости, то кросс-функциональных команд недостаточно. Нужны не просто кросс-функциональные, а и кросс-компонентные команды.
Типичное Аджайл-внедрение опирается на компонентные команды, которые эффективны и продуктивны локально, но заливают систему очередями и порождают длинные релизные циклы.
Зависимости нужно устранять, а не заниматься декорированием дашбордов красными нитками.
Компонентные команды имеют бизнес-зависимости, но комфортно работают в своих песочницах. Фиче-команды автономны, но требуют внедрения современных инженерных практик и дополнительных координационных механизмов.
Большое количество архитектурных компонентов требует плавного перехода к фиче-командам. Вам поможет инструмент Feature Team Adoption Map.