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

Статью подготовил
Андрей Барсуков
Тренер, Методолог, Agile коуч
Статью подготовил
Артем Вегнер
Тренер, Методолог, Agile коуч
“Ограничение на эти четыре типа команд действует как мощный шаблон для эффективного организационного дизайна.”

Matthew Skelton & Manuel Pais
Вступление
Топологии команд - относительно свежий взгляд на то, как можно описывать, классифицировать и формировать дизайн команд. Этот подход описан в книге 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. Четыре фундаментальные командные топологи
    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Т помогает сравнить и подчеркнуть достоинства конкурирующих дизайнов, а также дает представление о том, насколько хорошо любой конкретный дизайн соотносится с потоком ценностей.
            Рисунок 2. Применение командных топологий к Agile командам в ART
            Применение командных топологий в масштабе
            До сих пор мы обсуждали, как командные топологии могут помочь в создании команд, составляющих ARTs. Но многим компаниям также необходимо организовывать ARTs, которые являются частью более крупных Solution Trains (“Поездах” крупных решений). К счастью, эти топологии могут быть легко расширены, чтобы помочь найти правильные компромиссы в дизайне ART (рис. 3).
            Рисунок 3. Смесь топологий, применяемых к ARTs внутри Solution Train

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

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

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

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

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

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

            Конечно, все это связано с необходимостью постоянно размышлять о том, хорошо ли служат нам наши нынешние организационные модели. Таким образом, организации должны постоянно проверять и адаптировать и, при необходимости, реорганизовываться, чтобы следовать ценностям, определяющим рынок. Организационная гибкость требует не меньшего.
            Приложение: Топологии команд в масштабе – действующий пример
            Чтобы проиллюстрировать, как четыре топологии могут быть применены для идентификации ARTs и команд, будет использован пример финансовых услуг. Этот пример состоит из двух потоков создания ценности, которые вместе поддерживают операционный поток создания ценности потребительских банковских кредитов, как показано на рисунке 5. Первый поток создания ценности, "Заявка на получение кредита", фокусируется на процессе подачи заявки на получение кредита, а второй поток создания ценности, ‘Основная банковская деятельность", фокусируется на основных банковских системах, которые управляют обслуживанием кредитов.
            Рисунок 5. Пример финансовых услуг, показывающий два развивающих потока создания ценности
            Поток создания ценности "Заявка на получение кредита"
            Начиная с потока создания ценности для разработки кредитных заявок, в него входят 340 человек, поэтому потребуется несколько ARTs. Один из вариантов заключается в создании поточно-ориентированных ARTs по различным каналам сбыта, таким как онлайн, мобильный, отраслевой и т.д. Другой вариант - организовать вокруг групп клиентов, таких как существующие клиенты, новые клиенты, студенты, домовладельцы и т. Д. Третий вариант - организовать вокруг продуктов, которыми в данном случае являются ипотечные кредиты, личные займы, автокредиты и реструктуризация кредитов.

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

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

            Полная декомпозиция потока создания ценности для разработки кредитной заявки выглядит следующим образом, рисунок 6.
            Рисунок 6: Топологии ART, применяемые к потоку создания ценности "Заявка на получение кредита"
            Поток создания ценности "Основной банковской деятельности"
            Рассмотрение второго потока создания добавленной стоимости, ориентированного на основные банковские системы, которые поддерживают обслуживание кредитов. После тщательного рассмотрения было решено создать два ARTs.

            Первый ART - это поточно-ориентированный ART, который разработает конкретную функциональность потребительских кредитов, необходимую для поддержки рассматриваемого операционного потока создания ценности, в дополнение к набору услуг, предоставляемых вторым ART, который является основным банковским платформенным ART (рисунок 7). Действительно, эта базовая банковская платформа ART предоставляет эти услуги не только для этого потока создания ценности, но и для всей организации в целом, поэтому выделенная платформа ART имеет смысл.
            Рисунок 7. Поток создания ценности "Основной банковской системы" и топологии ART
            Декомпозиция ARTs на команды
            Как только эти определения ART будут приняты, следующим шагом будет организация Agile команд в рамках каждого ART. Это, как правило, происходит на этапе подготовки к запуску АРТ в рамках дорожной карты внедрения. (В этом примере мы рассмотрим только один из поточно-ориентированных ARTs из потока создания ценности "Заявка на получение кредита" как и другие поточно-ориентированные ARTs в том же потоке создания ценности разработки будут следовать аналогичной схеме декомпозиции.
            Поточно-ориентированный ART “Ипотека”
            Принимая во внимание структуру команд, для поточно-ориентированного ART «Ипотека» применяются четыре упомянутых ранее поточно-ориентированных шаблона декомпозиции, как показано на рисунке 8 ниже.
            Рисунок 8. Командные топологии, примененные к поточно-ориентированному ART "Ипотека"
            Организация по группам клиентов создает три команды: новые, существующие и перезакладывающие клиенты (те, кто не справляются с ежемесячными платежами по кредитам и повторно используют недвижимость для залога к другой финансовой организации). Организация по шагам в клиентском пути приводит к созданию групп, ориентированных на поток, ориентированных на онлайн и на физические каналы. Наконец, создается команда по соблюдению и регулированию и команда по разработке новых продуктов. Каждая из этих поточно-ориентированных команд обладает способностью приносить реальную пользу с минимальными зависимостями от других команд, и когда им действительно нужно сотрудничать, становится ясно, какие команды должны работать друг с другом, поскольку их обязанности четко определены.

            Наряду с этими поточно-ориентированными командами формируется команда сложных подсистем, специально предназначенная для работы с системой выдачи кредитов. Хотя другие команды способны взаимодействовать с этой системой для добавления и модификации различных ипотечных продуктов, фундаментальные изменения в работе системы, хотя и редкие, требуют глубоких знаний и навыков, которых не хватает.
            ART сложной подсистемы “Кредитный Скоринг”
            ART "кредитного скоринга" это ART сложной подсистемы и он разделен на две команды сложных подсистем и одну поточно-ориентированную команду, как показано на рисунке 9 ниже.
            Рисунок 9. Структура команды для сложной подсистемы "Кредитный скоринг".
            Первая команда сложной подсистемы назначена для разработки алгоритмов, требуемых системой кредитного скоринга для определения предоставления кредита, а вторая - команда сложной подсистемы, которая разрешает исключения в процессе подачи заявки на получение кредита, что требуется для пограничных результатов. Единая поточно-ориентированная команда разрабатывает систему оценки кредитоспособности, тесно сотрудничая со своими клиентами в других областях, которым необходимо интегрироваться с этой системой. (Этот пример помогает проиллюстрировать, как топологии являются фактическими по своей природе – в данном случае существует поточно-ориентированная команда в рамках ART сложной подсистемы , который признает, что эта команда может независимо предоставлять ценность для решения, которое им было поручено разработать.)

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

            Первый ART, который представляет собой поточно-ориентированный ART, сфокусированный на поддержке операционного потока создания ценности потребительских банковских кредитов, разделен на четыре поточно-ориентированные команды, сгруппированные вокруг конкретных этапов клиентского пути, а также команду сложной подсистемы, управляющую компонентом "расчет процентов" (рисунок 10). Этот шаблон декомпозиции хорошо работает, поскольку он согласуется с независимыми потоками ценности с ограниченным распределением работы между несколькими командами.
            Рисунок 10. Командная структура для поточно-ориентированного ART потребительских кредитов
            Платформенный ART "Основная банковская деятельность"
            Второй ART - это платформенный ART перекрестного потока создания ценности, включающий в себя четыре платформенных команды, организованный вокруг конкретных услуг, которые будут потреблять поточно-ориентированные команды в ART "Потребительские кредиты" (а также другие команды и ARTs по всей организации), и четыре команды сложных подсистем, которые работают непосредственно над разработкой системы основной банковская деятельности, как показано ниже на рисунке 11.
            Рисунок 11. Командная структура для платформенного ART основной банковской деятельности
            Дополнительная вспомогательная команда, поддерживающая автоматизированное тестирование в среде мэйнфреймов, будет работать с платформенным ART основной банковской деятельности для предстоящего PI в рамках инициативы по непрерывной доставке, к которой приступает организация.
            Заключение
            В статье рассмотрено:
            • На что может быть похоже применение топологий команд к основной единице SAFe - релизному поезду.
            • Как организовать команды внутри поезда.
            • Как топологии помогают описывать отношения поездов в рамках крупного решения.
            Кажется, что от типа поезда или команды должны зависеть не только состав участников, но и цели, способы взаимодействия, ответственность, фокус, продукт или оказываемый сервис команды (или поезда). А “карта” команд в поезде или поездов в решении способна привнести дополнительный уровень прозрачности в организацию зависимостей и ожиданий.

            А что вы думаете о применении топологий команд? Полезен ли этот подход в контексте ваших организаций? Насколько справедливо использовать терминологию командного уровня в применении к “командам команд”?

            
            Возможно будет интересно