Скрам-команды доставляют ценность на рынок каждый Спринт:
Скрам-команды являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Спринте (Руководство по Скраму).
Только так вы можете быть гибкими и скоростными, валидировать гипотезы и предположения с помощью коротких циклов обучения.
Важно понимать, что кросс-функциональность подразумевает не только способность выполнять различные типы работ (аналитика, разработка, тестирование и т.д.), но и вносить изменения в многочисленные архитектурные компоненты в периметре продукта. Такие команды называются фиче-командами.
Посмотрите на Бэклог Продукта одной из продуктовых групп, с которой я работал.
Бэклог Продукта одной из продуктовых групп
Для того, чтобы создавать ценность каждый Спринта необходимо вносить доработки в несколько архитектурных компоненты: 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.
