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

Подходы к организации команд

Принцип SAFe N10 «Организоваться вокруг ценности» стимулирует предприятия организовывать людей и команды вокруг одной цели — непрерывной доставки ценности клиенту. А для этого организациям необходимо прежде всего продумать, как наиболее эффективно сформировать свои Agile команды и Релизные Поезда (Agile Release Train, ART).

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

1. Ценностная перспектива: Фичи определяют ценность, которую они доставляют клиентам и конечным пользователям.
2. Техническая (технологическая) перспектива: как взаимодействуют архитектурные компоненты системы, чтобы обеспечить реализацию этой функциональности.

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

Организация команд вокруг функций (создание фича-команд, feature-team) и компонентов (создание компонентных команд, component-team) чаще всего использовалась в Agile подходах и в SAFe, в частности. [2] Такая конфигурация определяет фокус работы для каждой Agile команды и сужает область ответственности до выполнения какого-то одного вида задач. Другими словами, командам в результате такой организации не нужно понимать всё о системе в целом, что позволяет им сосредоточиться на той части системы, за которую они отвечают.

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

Подход «Топология команд» Мэтью Скелтона и Мануэля Паи

В своей книге «Топология команд» Скелтон и Паи предлагают альтернативный подход (рис.1), основанный на четырёх основных топологиях команд, каждая из которых характеризуется определённым поведением и обязанностями.

Рисунок 1. Четыре основные топологии команды

1. Команда, организованная вокруг потока (Stream-aligned team) – Люди организованы вокруг потока работы (рабочего процесса) в целом и могут доставлять ценность непосредственно клиенту или конечному пользователю.
2. Команда сложной подсистемы (The complicated subsystem team) – Люди организованы вокруг конкретных подсистем (систем, решений), требующих глубоких профессиональных навыков и знаний.
3. Команда платформы (Platform team) – Люди организованы вокруг разработки и поддержки платформ, предоставляющих услуги или инструментарий другим командам.
4. Помогающая команда (Enabling team) – Люди, обладающие специализированными навыками и знаниями, которые организованы в единую команду и делятся своей экспертизой с другими, а также помогают другим командам осваивать новые знания и технологии. Альтернативными названиями такой команды могут быть «команда трансформации» или «команда внедрения».

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

Команда включает в себя 2 специализированные роли:

• Владелец Продукта, который управляет тем, что команда будет разрабатывать и в какой последовательности (расставление приоритетов в беклоге команды)
• Скрам Мастер / Коуч Команды, который выступает в качестве лидера-слуги

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

Команда, организованная вокруг потока (Stream-Aligned Team)

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

Команда, организованная вокруг потока, со-направлена с единым потоком работы, позволяющим создавать и доставлять ценность для клиентов или пользователей как можно быстрее, безопаснее и автономнее, без необходимости передавать какие-то элементы своей работы для выполнения другим командам. [1]

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

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

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

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

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

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

Команда Сложной Подсистемы (Complicated Subsystem Team)

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

Скелтон и Паи определяют цели для команд сложных подсистем следующим образом:

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

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

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

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

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

Таким образом, создание команд сложной подсистемы не соответствует «старому» правилу формирования компонентных команд, когда повторное использование или архитектурная целостность могут служить единственным и достаточным основанием для создания компонентных команд. В качестве общего правила можно ориентироваться на то, что в одном поезде (Agile Release Train) не должно быть больше 1-3 команд сложных подсистем.

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

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

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

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

Команды платформы определяются следующим образом:

Команда(ы) платформы предоставляют базовые внутренние сервисы, которые необходимы командам, организованным вокруг потока, для доставки сервисов или функций более высокого уровня, тем самым снижая их когнитивную нагрузку. [1]

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

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

• Взаимодействовать с командами, ориентированными на поток – обеспечить разработку необходимых платформ в соответствии с требованиями заказчика.
• Разрабатывать платформу инкрементально – создавать и развёртывать инкрементально, а также обеспечивать постоянное получение обратной связи и подтверждений (валидации) от клиентов.
• Фокусироваться на удобстве использования – предоставлять платформы, которые просты в использовании благодаря возможностям самообслуживания и вспомогательной документации.
• Брать на себя ответственность за поддержку и обслуживание – обеспечить устойчивость и долговечность платформы, а также взять на себя обязательства по соответствующему обслуживанию в рамках SLA.
• Подавать пример – сохранять платформы «тонкими» и развивать их поверх других платформ, где это применимо.

Помогающая Команда (Enabling Team)

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

Помогающие Команды определяются следующим образом:

Помогающие команды помогают командам, ориентированным на поток, в приобретении недостающих компетенций, как правило, в конкретной технической области или области управления продуктом. [1]

Одним из примеров Помогающей команды в SAFe является Команда Системы, которая помогает командам Agile Release Train, в том числе создавать и поддерживать Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP).

Помогающие команды могут также предоставить экспертные знания и поддержку в следующих областях:

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

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

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

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

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

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

Agile Команды в Поезде (ART)

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

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

Рисунок 2. Визуализация Agile команд поезда (ART) с учетом топологии

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

Рисунок 3. Применение топологии к Поездам (ART) внутри Поезда Решения

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

Далее в статье мы рассмотрим масштабирование топологии для формирования Поездов (ART).

Поезд, организованный вокруг потока (Stream-aligned ART)

Релизный Поезд (Agile Release Train, ART), организованный вокруг потока, так же, как и команда, организованная вокруг потока, будет обладать необходимым персоналом, навыками и полномочиями для доставки ценности, будь то целый продукт, услуга, подсистема или какая-то часть решения, за которую поезд отвечает. Зоны ответственности Поездов, организованных вокруг потока, в целом такие же, как и для «потоковых» команд. К ним также применяются и те же варианты выравнивания (обеспечения со-направленности) вокруг определенного аспекта, о которых говорилось ранее.

Поезд сложной подсистемы (Complicated subsystem ART)

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

Платформенный Поезд (Platform ART)

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

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

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

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

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

Помогающий Поезд (Enabling ART)

Этот тип Поезда не показан на рисунке 3 и не так часто встречается по сравнению с другими топологиями Поездов. При этом Помогающие Поезда могут предоставлять специализированные инструменты, услуги или экспертные знания другим поездам и командам. Некоторые помогающие ART могут функционировать внутри Поезда Решения (Solution Train), выступая в роли внутренних поставщиков для других ART или внешних потребителей крупного решения Solution Train.

Резюме

В этой статье представлены новые способы организации Agile команд и Релизных Поездов (ART) для крупномасштабной разработки систем и программного обеспечения. Применение четырех основных топологий может упростить эту сложную задачу. При этом важно постоянно отслеживать эффективность текущей организационной модели. Для этого организации должны регулярно проводить мероприятие Инспект-Адапт (Inspect & Adapt, I&A) и, при необходимости, реорганизовываться, чтобы соответствовать требованиям рынка. Обеспечение Организационной гибкости не может быть достигнуто простым набором действий, выполняемых однократно.

Пример Топологии Команд в масштабе

На примере Банка мы рассмотрим, как топологии команд могут быть применены при формировании Релизных Поездов (ART) и Agile команд. В частности, в этом примере основное внимание будет уделено розничным кредитам.

Банк определил два разработческих потока ценности (DVS), которые взаимодействуют друг с другом для поддержки операционного потока ценности «Розничные Кредиты» (OVS), показанного на рисунке 5.

Рисунок 5. Два разработческих потока ценности на примере Банка

1. Разработческий поток ценности «Розничные кредиты» – специализируется на разработке решений для выдачи розничных кредитов, таких как ипотека, потребительские кредиты, автокредиты и многое другое.
2. Разработческий поток ценности «АБС» – специализируется на разработке решений для обслуживания розничных кредитов и предоставляет другие решения (такие как коммерческий банкинг, бизнес-кредиты и инвестиционный банкинг).

Разработческий Поток Ценности «Розничные Кредиты»

Разработческий поток ценности «Розничные кредиты» включает 340 человек (80 в США, 230 в Индии и 30 в Эстонии), которым требуется несколько Релизных Поездов (их количество превышает 125 человек). Изначально рассматривалось три варианта организации поездов внутри этого потока ценности:

1. Организовать Поезда вокруг каналов: онлайн, мобильный и физические отделения банка.
2. Организовать Поезда вокруг клиентских сегментов: существующие клиенты, новые клиенты, студенты и домовладельцы.
3. Организовать Поезда вокруг кредитных продуктов: ипотека, потребительские кредиты, автокредиты и др.

После анализа вариантов был выбран третий вариант, как показано на рисунке 6. Каждый кредитный продукт будет представлять собой Релизный Поезд (ART) внутри Разработческого потока ценности «Розничные кредиты». Организационно Релизные Поезда (ART) будут объединены в Поезд Решения / Solution Train, как показано ниже.

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

Рисунок 6. Применение топологии команд к Разработческому потоку ценности «Розничные кредиты»

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

Разработческий поток ценности «Автоматизированная Банковская Система (АБС)»

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

Рисунок 7. Разработческий поток «АБС» и топологии Поездов

1. Платформенный Поезд «АБС» – предоставляет основные банковские сервисы для этого потока создания ценности и других в случае более крупной организации, поэтому имеет смысл выделить отдельный платформенный ART.
2. Поезд «Кредитование в АБС», организованный вокруг потока – развивает функционал розничных кредитов, необходимый для поддержки операционного потока розничного кредитования.
3. Поезд сложной подсистемы «Шина» — развивает сервис для обмена сообщениями и информацией между подсистемами и отдельными сервисами внутри банка.

Организация Agile Команд внутри Релизных Поездов (ART)

Следующим шагом является организация Agile команд внутри каждого ART. Чтобы упростить пример, мы будем декомпозировать только некоторые поезда (ART) наших двух разработческих потоков ценности, каждый из которых организован в виде отдельного Поезда Решения (Solution Train).

Поезд «Ипотека», организованный вокруг потока

С учетом структуры команд для ART «Ипотека», организованного вокруг потока, применяются топологии команд, упомянутые ранее в статье, как показано на рисунке 8 ниже.

Рисунок 8. Топологии команд, применяемые к поезду «Ипотека», организованному вокруг потока

1. Было решено, что три команды, организованные вокруг потока, сосредоточатся на разных клиентских сегментах: 1) клиенты, которые рефинансируют ипотечные кредиты, 2) новые покупатели и 3) существующие клиенты.
2. Для управления клиентскими каналами были сформированы еще две команды, организованные вокруг потока: онлайн-каналы (например, сайт, мобильное приложение) и физические каналы (например, отделения банков).
3. Были также сформированы две дополнительные команды, организованные вокруг потока, для внутренних бизнес-процессов: комплаенс и инноваций в новых продуктах.
4. Также формируется команда по выдаче кредитов – команда сложной подсистемы. Несмотря на то, что другие команды могут использовать интерфейс через API для добавления и изменения различных кредитных продуктов, для реализации этого на практике необходимо иметь глубокие знания в области выдачи кредитов и навыки языка программирования C.

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

Поезд сложной подсистемы «Кредитный скоринг»

Поезд сложной подсистемы «Кредитный скоринг» разбит на четыре команды, как показано на рисунке 9 ниже.

Рисунок 9. Применение топологии команд к Поезду сложной подсистемы «Кредитный скоринг»

Этот поезд состоит из одной команды, организованной вокруг потока, двух команд сложных подсистем и одной помогающей команды:

1. Система кредитного скоринга (организована вокруг потока) – Эта команда тесно сотрудничает с двумя другими Поездами сложной подсистемы, которые должны интегрироваться с этой системой. В этом примере показано, насколько топологии являются гибкими. В этом случае команда, организованная вокруг потока внутри ART сложной подсистемы, признает, что эта команда может независимо доставлять ценность для розничных кредитов.
2. Алгоритм кредитного скоринга (сложная подсистема) – разрабатывает и поддерживает очень сложные алгоритмы кредитного скоринга для розничных кредитов.
3. Исключения из кредитного скоринга (сложная подсистема) – Создает функциональные возможности, которые разрешают исключения в процессе подачи заявки на кредит.
4. Облачные технологии (помогающая команда) – Помимо своей разработческой деятельности поток «Розничные Кредиты» вкладывает значительные средства в миграцию в облако. Сложная подсистема кредитного скоринга является одной из первых систем, предназначенных для перехода в облако. Для реализации этого помогающая команда поможет всем командам этого ART перейти в облако во время предстоящего Интервала Планирования.

Платформенный Поезд «АБС»

Платформенный Поезд «АБС» (рисунок 10) состоит из четырех платформенных команд, четырех команд сложных подсистем и одной поддерживающей команды:

Рисунок 10. Структура команд для Платформенного Поезда «АБС»

1. Четыре платформенные команды формируются для разных этапов пути клиента: создание нового аккаунта, закрытие аккаунта и обработка платежей (две Agile команды).
2. Четыре команды сложных подсистем формируются для общих компонентов АБС, которые являются очень сложными и комплексными.
3. Одна помогающая команда, поддерживающая автоматизированное тестирование, будет помогать командам поезда «АБС» на предстоящем Интервале Планирования в рамках инициативы организации по улучшению непрерывной доставки.

Поезд «Кредитование в АБС», организованный вокруг потока

Второй ART внутри разработческого потока «АБС» организован вокруг потока и сфокусирован на поддержке операционного потока ценности «Розничные кредиты» (Рисунок 11).

Рисунок 11. Структура команд для Поезда «Кредитование в АБС», организованного вокруг потока

1. Поезд «Кредитование в АБС», организованный вокруг потока, разбивается на четыре команды, организованные вокруг потока, для конкретных этапов пути клиента: неуплата задолженности по кредиту, обслуживание кредита, создание нового кредита и платежи по кредиту.
2. Одна команда сложной подсистемы рассчитывает проценты по кредиту.

В итоге декомпозиция этого ART позволяет командам доставлять ценность независимо или с небольшим количеством зависимостей.

Узнать больше:
[1] Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Organizing Agile Teams and ARTs: Team Topologies at Scale».

Дополнительно почитать по теме:

Самодизайн. Как организовать команды в Поезд с помощью мастерской «Формирование команд»

Тактика построения организационной гибкости: техника выявления и улучшения потоков ценности. CITSO.

Как организовать работу потоков ценности при разработке Крупного Решения?