Организация Agile команд и ARTs: Командная топология в масштабе

Топологии команд - относительно свежий взгляд на то, как можно описывать, классифицировать и формировать дизайн команд. Этот подход описан в книге Manuel Pais и Matthew Skelton Team Topologies и востребован в попытках выбрать правильные модели Agile команд для своей организации, обеспечивая работоспособность программного обеспечения и оптимизируя потоки создания ценности. На топологии команд, как на один из компонентов своего очередного «коктейля», ссылается Jurgen Appelo при описании своей организационной модели unFix (доступна на русском). Интересно, что описание SAFe тоже стало включать этот подход, как для формирования своих знаменитых поездов, так и для описания взаимодействия поездов в рамках больших решений. Расширяя таким образом область применения топологий команд на следующий уровень.

Интересно? Давайте разбираться!

Принцип SAFe #10 – Организация вокруг ценности помогает предприятиям организовывать людей и команды вокруг одной цели: непрерывной доставки ценности клиенту. Но для этого они должны рассмотреть, как лучше всего спроектировать свои Agile команды и релизные поезда (ARTs). Традиционно это достигалось различными способами: организация вокруг функций, компонентов, источника финансирования, даже географии и т.д. Каждый подход преследует цель объединить людей и кроссфункциональные навыки для улучшения потока, повышения ценности и даже радости от работы.

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

В своей книге «Team Topologies» Matthew Skelton и Manuel Pais продвинули мышление в области командного дизайна. В частности, они дают представление о том, как организовать людей, создающих решения вокруг четырех фундаментальных командных «топологий»: поточно-ориентированные, сложные подсистемы, платформенные, разблокирующие.

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

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

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

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

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

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

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

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

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

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

Термин «поточно-ориентированный» акцентирует важность организации команд для непрерывной поставки внутри ее развивающего потока создания ценности (Development Value Stream), который создает, запускает и поддерживает продукт или решение. Skelton и Pais определяют команду, ориентированную на поток, следующим образом:

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

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

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

• Конкретное решение или подмножество решений
• Набор фич
• Конкретный образ клиента
• Конкретные шаги на пути клиента
• Конкретный бизнес-домен
• Соответствие и нормативные требования
• Инновации в новом продукте

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

Обязанности и поведение поточно-ориентированных команд
Для каждого типа команд Skelton и Pais определяют набор ожидаемых моделей поведения. В контексте SAFe мы интерпретируем эти обязанности поточно-ориентированных команд следующим образом:

• Знать своего клиента – строить и поддерживать прямые отношения с клиентами и развивать глубокое понимание обслуживаемых сегментов рынка.
• Разрабатывать постоянный поток новых фич – фичи описывают потребности клиентов и связанные с ними преимущества. Новые фичи должны составлять большую часть работы, выполняемой командами, ориентированными на поток.
• Применять дизайн–мышление - разбираться в пространстве проблем, изучать варианты решений, проверять их у клиентов и вводить циклы обратной связи.
• Использовать практики непрерывного совершенствования – резервировать время для совершенствования процессов и инструментов, необходимых для выполнения работы.
• Встраивать качество – брать на себя ответственность за обеспечение соответствия работы стандартам качества на протяжении всего процесса разработки.
• Работать совместно – определять и управлять взаимодействием с другими командами в ART и общих сервисах
• Реагировать на потребности клиентов – реагировать на запросы новых фич, инциденты и корректировать порядок действий.
• Поддерживать решения в промышленной эксплуатации – поточно-ориентированные команды берут на себя ответственность за поддержку своих элементов решения в промышленной эксплуатации. Другими словами, «они строят это; они управляют этим».

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

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

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

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

• Узкоспециализированные системные компоненты, часто используемые в нескольких системах
• Элементы критически важных для безопасности систем, которые имеют высокую стоимость сбоя
• Специальные алгоритмы или бизнес-правила, которые имеют решающее значение для пригодности использования в данной области
• Часть киберфизической системы (например, модуль управления двигателем в автономном транспортном средстве)

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

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

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

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

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

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

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

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

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

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

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

Одним из примеров разблокирующей команды в SAFe является Системная команда, которая помогает командам АRT (среди прочего) создавать и поддерживать конвейер непрерывной поставки. Некоторые более специализированные примеры разблокирующих команд могут предоставить экспертные знания и поддержку в следующих областях:

• Реализация DevOps
• Автоматизированное тестирование
• Непрерывная интеграция и инструменты для сборки
• Методы обеспечения качества проектирования
• Безопасность
• Среды и конфигурация

Разблокирующие команды также могут быть сосредоточены на оказании помощи поточно-ориентированным командам, в первые несколько раз, когда им необходимо интегрироваться с определенной подсистемой или платформой. Однако разблокирующие команды не предназначены для устранения проблем с качеством, вызванных поточно-ориентированными командами. Скорее, они работают с ними в течение коротких периодов, как правило, в течение одного PI (Program Increment (Инкремент Программы) - примечание переводчика) или около того, чтобы повысить их навыки и внедрить необходимые возможности.

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

Обязанности и поведение разблокирующих команд включают в себя:

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

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

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

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

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

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

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

Области ответственности для этих поточно-ориентированных ARTs как правило, такое же, как и для поточно-ориентированных команд. И те же варианты выравнивания вокруг определенного аспекта, о которых говорилось ранее, применимы и здесь.

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

Платформенные ARTs
Аналогичным образом для Solution Train характерно наличие платформенных ARTs, предоставляющих услуги, которые расширяют и развивают поточно-ориентированные ARTs. Продолжая пример автономного транспортного средства, система связи, которая управляет данными, передаваемыми между различными подсистемами, скорее всего, будет представлена в виде платформы с четко определенными интерфейсами.

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

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

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

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

Резюме
Эта статья приводит новые шаблоны к задаче организации Agile команд и АRТs для крупномасштабной разработки систем и программного обеспечения. Применение четырёх фундаментальных топологий может упростить эту сложную задачу.

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

Приложение: Топологии команд в масштабе – действующий пример
Чтобы проиллюстрировать, как четыре топологии могут быть применены для идентификации ARTs и команд, будет использован пример финансовых услуг. Этот пример состоит из двух потоков создания ценности, которые вместе поддерживают операционный поток создания ценности потребительских банковских кредитов, как показано на рисунке 5. Первый поток создания ценности, «Заявка на получение кредита», фокусируется на процессе подачи заявки на получение кредита, а второй поток создания ценности, «Основная банковская деятельность», фокусируется на основных банковских системах, которые управляют обслуживанием кредитов.