Масштабирование по SAFe®: как собрать АRT из команд разных типов

Вольный перевод статьи: Organizing Agile Teams and ARTs: Team Topologies at Scale.

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

Общий принцип

Принцип №10 фреймворка SAFe^® — организуйтесь вокруг ценности — помогает предприятиям организовывать людей и команды вокруг одной цели: непрерывной поставки ценности клиенту. Но для этого необходимо продумать, как лучше всего организовать свои Agile-команды и Agile Release Trains (ART). Это можно сделать разными способами: выстроив команды вокруг фич (той или иной функциональности), компонентов, источника финансирования, даже географического расположения и т.д. Каждый подход имеет цель объединить людей и кросс-функциональные навыки для улучшения потока доставки ценности и радости от работы.

До сих пор выстраивание команд вокруг фич и компонентов была стандартным подходом для команд и ART в SAFe и Agile в целом.

В своей книге «Топологии команд» Мэтью Скелтон и Мануэль Пайс предложили новую концепцию организации разработчиков решений с использованием четырех основных типов команд:

• команда, ориентированная на поток (ценности — прим. переводчика),
• команда сложной подсистемы,
• платформенная команда,
• вспомогательная команда.

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

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

Детальное описание

Любое программное решение можно рассматривать с двух точек зрения:

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

Организация команд вокруг фич (фиче-команды) и компонентов (компонентные команды) была и остается доминирующей моделью в Agile. Это позволяет каждой Agile-команде оставаться сфокусированной на выполняемой работе на протяжении длительного времени и в то же время ограничивает их когнитивную нагрузку. Другими словами, командам не обязательно понимать всю систему в целом; они могут сосредоточиться на той части системы, за которую они отвечают.

Однако, этот подход не лишен проблем. Характерные особенности фиче-команды часто неясны и не всегда подразумевают комплексную доставку ценности. Также противоречивы и мотивы создания «компонентных» команд. Обычно решения по созданию компонентных команд принимаются из-за стремления к оптимизации ресурсов вокруг конкретных технических знаний и повторного использования программного обеспечения. Зачастую это приводит к тому, что команды становятся излишне специализированными или сильно привязываются к технологиям, что увеличивает зависимости и тормозит поток.

В своей книге Скелтон и Пайс описывают альтернативный подход. Они описывают четыре типа команд, что позволяет улучшить и упростить задачу организации вокруг поставки ценности (рисунок 1):

Рисунок 1. Четыре фундаментальных типа команд

1. Потоковая команда (Stream-aligned team) — организована вокруг потока работы и способна доставлять ценность непосредственно заказчику, клиенту или конечному пользователю.
2. Команда сложных подсистем (Complicated subsystem team) — организована вокруг определенных подсистем, требующих глубоких специальных навыков и опыта.
3. Платформенная команда (Platform team) — организована вокруг разработки и поддержки платформ, которые предоставляют услуги (сервисы) другим командам.
4. Вспомогательная команда (Enabling team) — организована для оказания поддержки другим командам специализированными возможностями и помощи в овладениями новыми технологиями.

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

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

Потоковые команды (Stream-Aligned Teams)

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

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

Одним из наиболее значительных преимуществ такой организации команд является ориентация на клиента (клиентоцентричность); каждая команда имеет прямое отношение к клиентам или заказчикам, на которых она работает. Потоковые команды применяют методы дизайн-мышления (design thinking), чтобы лучше понимать сегменты клиентов — создавая и поддерживая желаемые фичи. Разумеется, большинство команд в Lean-Agile организации должны быть потоковые.

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

• конкретное решение или подмножество решений,
• набор фич,
• сегмент пользователей,
• конкретные шаги клиентского пути (customer journey),
• конкретная предметная область бизнеса (бизнес-домен),
• соответствие нормативным и регуляторным требованиям,
• новые инновационные продукты.

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

Обязанности и подходы потоковых команд:

Для каждого типа команд Скелтон и Пайс определяют набор ожидаемых подходов в работе. В контексте SAFe мы интерпретируем их как обязанности потоковых команд и выделяем следующие:

• Знать своего клиента (KYC — Know Your Customer) — команды должны выстраивать и поддерживать прямые отношения с клиентами и развивать глубокое понимание сегментов рынка, на которые они работают.
• Поставлять стабильный поток новых фич — фичи описывают потребности клиентов и связанные с ними выгоды. Новые фичи должны составлять большую часть работы, которую выполняют потоковые команды.
• Применять методы дизайн-мышления — понимать полный контекст проблемы, изучать варианты решений, проверять их с клиентами и учитывать обратную связь.
• Применять методы непрерывного улучшения — резервировать время для улучшения процессов и инструментов, необходимых для выполнения работы.
• Повышать качество — брать ответственность за обеспечение соответствия всей работы надлежащим стандартам качества на протяжении всего процесса разработки.
• Сотрудничать — выявлять и управлять совместной работой с другими командами в ART и общими сервисными командами.
• Отвечать потребностям клиента — реагировать на запросы новых фич, инциденты и корректировать курс дальнейших действий.
• Поддерживать решения в продуктивной среде — потоковые команды должны брать ответственность за поддержку своих элементов решения в продуктивной среде. Другими словами, команды сами поддерживают то, что разрабатывают.

Команды сложных подсистем (Complicated Subsystem Teams)

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

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

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

Команда сложной подсистемы может разрабатывать такие вещи, как:

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

Хотя на подсистемы можно декомпозировать практически любое решение, не для каждой подсистемы требуется специализированная команда. Уровень опыта, сложность и риск должны быть единственными решающими факторами для создания команды сложной подсистемы.

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

Обязанности и подходы команд сложных подсистем:

• Разрабатывать, сопровождать и поддерживать сложную подсистему — определять и вносить изменения в разрабатываемые критически важные технические элементы.
• Поддерживать уровень знаний — продолжать совершенствовать знания и навыки, необходимые для работы в предметной области подсистемы.
• Сотрудничать с поточными командами — быть уверенными, что разрабатываемые подсистемы соответствуют требованиям клиентов.
• Эффективно планировать и расставлять приоритеты — выравнивать дорожную карту развития подсистемы с потребностями потоковых команд.
• Разрабатывать правильные интерфейсы — скрывать сложную реализацию подсистем за хорошо документированными и простыми в использовании интерфейсами.
• Брать ответственность за качество — обеспечивать качество, производительность и архитектурную надежность подсистемы.

Платформенные команды (Platform Teams)

Технологическая или вычислительная платформа — это набор сервисов, которыми пользуются потоковые команды. Обычно это происходит с помощью API (Application Program Interface, программный интерфейс приложения), предоставляемого платформой. Подобно командам сложных подсистем, платформенные команды (как и платформы, которые они поддерживают) создаются для уменьшения когнитивной нагрузки на потоковые команды. Более того, команды должны быть выделены таким образом, чтобы повысить автономность потоковых команд. Можно дать следующее определение платформенной команде:

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

Акцент на платформенных командах как на «поставщиках услуг» (service providers) сильно влияет на работу этих команд. Платформы рассматриваются как «продукты», разработанные для их клиентов, которыми в данном случае являются потоковые команды. В данном контексте также применимы такие методы, как клиентоориентированность (клиентоцентричность) и дизайн-мышление. Кроме того, предоставляемые командами сервисы должны быть хорошо документированы, просты в использовании, соответствовать целям, быть легковесными и иметь возможность повторного использования.

Обязанности и подходы платформенных команд:

• Сотрудничать с потоковыми командами — быть уверенными, что разрабатываемые платформы соответствуют требованиям клиентов.
• Разрабатывать платформу инкрементально — разрабатывать и выпускать инкрементально, учитывая частую обратную связь и результаты проверки гипотез от клиентов.
• Фокусироваться на удобстве использования — используя возможности самообслуживания и сопроводительную документацию, предоставлять простые в использовании платформы.
• Поддерживать и обслуживать — обеспечивать устойчивость и бесперебойную работу платформы, а также соблюдение соответствующих соглашений об уровне обслуживания (Service Level Agreement, SLA).
• Быть примером — сохранять платформы легковесными, разрабатывать их поверх других платформ, там, где это возможно.

Вспомогательные команды (Enabling Teams)

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

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

Одним из примеров вспомогательной команды в SAFe является System Team, которая помогает командам ART (среди прочего) создавать и поддерживать конвейер непрерывной поставки (CDP, Continuous Delivery Pipeline). Хорошими более специализированными примерами областей, в которых вспомогательные команды способны предоставить экспертные знания и поддержку, могут быть:

• внедрение DevOps-практик,
• автоматизированное тестирование,
• инструменты для непрерывной интеграции и сборки,
• практики обеспечения качества (Quality Assurance, QA) и тестирования,
• безопасность,
• среды (окружения) и конфигурации.

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

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

Обязанности и подходы вспомогательных команд:

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

Agile-команды в ART

В SAFe команды работают как часть Agile Release Train (ART). При формировании ART и команд, которые их составляют, может быть полезно визуализировать эти команды в терминах типов, к которым они относятся. Для пояснения различных типов команд можно воспользоваться схемой, показанной на рисунке 2.

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

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

Рисунок 2. Применение типологий к Agile-командам в ART

Применение типов команд в масштабе

Мы обсудили, как типы команд могут помочь в организации команд в рамках ART. Но многим предприятиям также необходимо организовывать ART, которые являются частью более крупных Solution Trains. К счастью, эти типы могут быть легко расширены, что позволяет найти здоровый компромисс при организации ART (рисунок 3).

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

При масштабировании этих типов до ART требуется учесть некоторые дополнительные моменты.

Потоковый ART

Потоковый ART, как и потоковая команда, будет иметь необходимый состав специалистов, обладающих требуемыми навыками и полномочиями для поставки ценности, будь то полный продукт, сервис, подсистема, или какая-либо часть решения, над которой они работают.

Зоны ответственности этих потоковых ART в целом такие же, как и у потоковых команд. Варианты их организации по определенному типу здесь применимы так же, как описано ранее.

ART сложной подсистемы

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

Платформенный ART

Точно так же Solution Trains обычно имеют платформенные ART, обслуживающие потоковые ART. Продолжая пример автономного транспортного средства, система связи, управляющая данными, передаваемыми между различными подсистемами, вероятнее всего, будет представлена ​​как платформенный ART с четко определенными интерфейсами.

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

Рисунок 3. Сочетание АRТ различных типов в рамках Solution Train

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

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

Резюме

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

Конечно, все это требует постоянного анализа того, насколько хорошо нам служат наши нынешние организационные модели. Таким образом, организации должны постоянно проверять и адаптировать (Inspect and Adapt, I&A) и, при необходимости, реорганизовывать свою структуру, чтобы следовать ценностям, движущим рынок. Именно этого требует организационная гибкость (Organizational Agility).

О переводчиках

Александр Киверин
Ак Барс Цифровые Технологии, Технический директор

В менеджменте ИТ более 10 лет, выстраивал работу команд как небольших проектов в сфере E-commerce, так и крупных Enterprise-решений в сфере трейдинга, медицины и финтеха. Последние 4 года участвую в трансформации и развитии Ак Барс Банка, чтобы наши клиенты жили лучше. Certified SAFe^® Agilist.

Игорь Ларченко
Deutsche Telekom IT Russia, Scrum мастер

В IT более 25 лет. Прошел путь от разработчика до Enterprise архитектора в таких областях, как индустрия гостеприимства, компьютерные системы, финтех, нефть и газ. С 2015 года сфокусирован на формировании команд, управлении процессами в IT и их настройкой на большом масштабе. Professional Scrum Master, Professional Scrum Product Owner, Certified SAFe^® Agilist.

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