Дисциплина «Командная и Техническая Гибкость»

Дисциплина «Командная и техническая гибкость» (Team and Technical Agility, TTA) описывает, как кросс-функциональные Agile команды могут ускорить доставку ценности. В ней рассматриваются ключевые навыки, роли и практики, которые используют высокоэффективные команды и Поезда (Agile Release Train, ART) для создания высококачественных продуктов и решений для клиентов. Все Agile команды и Поезда несут ответственность за встраивание качества на всех этапах — от разработки до доставки.

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

На рисунке 1 показаны ключевые элементы, процессы и результаты дисциплины SAFe «Командная и Техническая Гибкость».

Рисунок 1. Ключевые элементы, процессы и результаты, создаваемые дисциплиной «Командная и Техническая Гибкость».

Релизный Поезд (Agile Release Train, ART)

Когда продукт или решение слишком масштабны, чтобы одна Agile команда могла их реализовать, на помощь приходит Agile Release Train (ART) — Релизный Поезд Agile. Он объединяет несколько команд, помогает со-направить их работу и выстроить единые для всех способы организации работы, как показано на рисунке 1.

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

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

Основные роли в Agile Release Train

• Менеджмент Продукта — отвечает за создание востребованных, жизнеспособных, осуществимых и устойчивых продуктов, удовлетворяющих потребности клиентов на протяжении всего жизненного цикла продукта или решения.
• Архитектор Систем — отдельный человек или небольшая команда, покрывающая разные направления архитектуры, которая определяет архитектурные намерения на уровне системы в целом, идентифицирует ключевые элементы и подсистемы, помогает разработать дизайн интерфейсов и взаимодействия между ними, а также определить нефункциональные требования (НФТ/NFR).
• Инженер Релизного Поезда (Release Train Engineer, RTE) — лидер-слуга и главный Скрам Мастер / Коуч команды команд для Поезда. RTE помогает оптимизировать поток ценности, следя за тем, что мероприятия уровня Поезда корректно проводятся, а артефакты правильно используются. В частности, работа RTE включает в себя организацию Канбан системы Поезда (ART) и ведение таких мероприятий как: PI Планирование, Синхронизация Поезда (ART Sync), Инспект-Адапт (Inspect & Adapt) и др.
• Владельцы Бизнеса — небольшая группа заинтересованных лиц, которые несут бизнес- и техническую ответственность за: пригодность продукта или решения для использования, управление и соответствие регуляторным требованиям, возврат инвестиций (ROI). Они являются основными заинтересованными лицами Agile Release Train и принимают активное участие во всех ключевых мероприятиях поезда.

Мероприятия Agile Release Train

Интервалы Планирования (Planning Interval, PI) задают ритм работы Релизного Поезда (ART). Интервал Планирования — фиксированный отрезок времени, в течение которого поезд непрерывно доставляет ценность своим клиентам.

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

В течение всего Интервала Планирования регулярно проводятся Демонстрации Системы (System Demo). На System Demo, в конце каждой Итерации, команды показывают новые интегрированные фичи. Это позволяет заинтересованным лицам отслеживать прогресс в работе и понимать, как реализуются цели Интервала Планирования.

В конце каждого PI проходит мероприятие Инспект-Адапт (Inspect & Adapt, I&A). На нём команды оценивают результаты своей работы и текущее решение, анализируют свои процессы и определяют области для улучшения с помощью Мастерской решения проблем.

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

Завершается Интервал Планирования Итерацией Инноваций и Планирования (IP Iteration). Это время предназначено для исследований и экспериментов, обучения, подготовки к следующему PI и инновациям. Итерация Инноваций и Планирования способствует развитию культуры постоянного роста и непрерывного улучшения.

Agile Команды

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

Для организации своей работы большинство команд в SAFe используют SAFe Scrum — «легковесный» процесс, ориентированный на непрерывную доставку ценности. Команды в SAFe организациях также могут выбрать альтернативный способ организации работы – SAFe Team Kanban. Последний является Lean-Agile методом, который помогает визуализировать рабочий процесс, ограничивать количество незавершённой работы (НЗР / WIP) и измерять производительность (пропускную способность). Оба способа организации работы направлены на постоянную доставку ценности и непрерывное улучшение процессов.

Каждая Agile команда включает в себя две роли:

• Скрам Мастер / Коуч Команды (Scrum Master / Team Coach) — лидер-слуга и коуч Agile команды, который помогает команде устранять препятствия, фасилитирует мероприятия уровня команды и создаёт условия для высокоэффективной работы.
• Владелец Продукта (Product Owner) — управляет содержанием беклога команды, определяет Истории и расставляет приоритеты в беклоге команды.

Практики технической гибкости

Релизный Поезд (Agile Release Train, ART) использует или создаёт Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP). Конвейер доставки позволяет Agile командам регулярно и своевременно доставлять новую функциональность пользователям. Частота релизов может различаться — от нескольких раз в день до еженедельных или ежемесячных выпусков — в зависимости от потребностей рынка и целей бизнеса.

Чтобы поддержать такой ритм доставки, Релизный Поезд непрерывно развивает Архитектурное Русло (Architectural Runway): существующий код, компоненты и техническую инфраструктуру. Это позволяет реализовывать новые Фичи без задержек и серьёзных изменений в архитектуре.

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

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

Компетенции, входящие в Дисциплину «Командная и Техническая Гибкость»

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

На каких из приведённых ниже компетенций стоит сосредоточиться в данный момент — зависит от контекста организации, уровня знаний и опыта сотрудников, а также от текущих задач, возможностей и недостатков конкретного продукта.

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

1. Создание эффективных Agile команд
   Бизнес-проблема: Наши команды применяют Agile практики, но мы медленно доставляем ценность и сталкиваемся с низкой вовлечённостью сотрудников.
2. Разработка качественного программного обеспечения
   Бизнес-проблема: В нашем техническом процессе доставки ПО присутствуют узкие места, а также наблюдаются частые дефекты после релизов, что приводит к значительным затратам на сопровождение.
3. Запуск Agile бизнес-команд
   Бизнес-проблема: Наши операционные отделы не успевают адаптироваться к меняющимся потребностям клиентов и рынка.
4. Непрерывная доставка ценности
   Бизнес-проблема: Наши сквозные процессы доставки недостаточно прозрачны, а сами процессы медленные, часто сопровождаются ошибками и работают неэффективно.
5. Интеграция команд по разработке программного и аппаратного обеспечения
   Бизнес-проблема: Нашим командам по разработке ПО и аппаратного обеспечения сложно работать вместе, так как у них слишком разные подходы к работе.
6. Координация между командами
   Бизнес-проблема: У нас возникают сложности с управлением и приоритизацией работ между командами, что приводит к неэффективному взаимодействию и замедляет доставку ценности.
7. Гибкое управление требованиями
   Бизнес-проблема: Неясные и нечёткие требования и спецификации приводят к переделкам и задержкам в работе.
8. Развитие архитектурного русла
   Бизнес-проблема: Архитектура разрабатывается заранее и без взаимодействия с другими участниками, из-за чего сложно быстро реагировать на новые требования.
9. Эффективная дистанционная работа команд
   Бизнес-проблема: Нам сложно поддерживать вовлечённость и продуктивность дистанционно работающих команд и сотрудников.

Измерение дисциплины «Командная и Техническая Гибкость»

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

В статье Метрики SAFe (Measure and Grow) даны рекомендации по сбору и интерпретации данных для получения наилучших результатов.

Общий обзор Дисциплины «Командная и Техническая Гибкость»

Создание отличных продуктов с помощью Agile команд и Поездов (ART)

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

В Agile команде есть две ключевые роли:

• Владелец Продукта — отвечает за то, чтобы задачи в беклоге отражали потребности клиентов, а также помогает команде сосредоточиться на том, что приносит наибольшую бизнес-ценность для клиентов и организации.
• Скрам Мастер / Коуч Команды — лидер-слуга и коуч команды, который помогает команде эффективно следовать выбранному Agile процессу и создаёт условия для слаженной и быстрой работы.

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

При этом одна команда, как правило, не может создавать и доставлять сложные, комплексные системы в короткие сроки. Такие решения требуют разнообразных, часто узкоспециализированных навыков, которые не умещаются в рамки одной команды. В таких случаях несколько Agile команд объединяются в Релизный поезд (Agile Release Train, ART) — кросс-функциональную команду команд, которая работает над созданием одного или нескольких продуктов или решений, как показано на Рисунке 2.

Рисунок 2. Релизные Поезда (ART) создают, доставляют и поддерживают ценные для клиентов продукты и решения

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

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

Agile команды внутри Поезда используют SAFe Scrum, SAFe Team Kanban или их гибрид для синхронизации работы внутри Поезда и доставки ценности в едином ритме. Эти подходы помогают управлять общим беклогом, доставлять ценность инкрементально, развивать архитектурное русло и регулярно получать обратную связь от клиентов и заинтересованных лиц.

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

Рисунок 3. Цикл SAFe Scrum

У Agile команд, использующих SAFe Scrum (см. рисунок 3), есть регулярные мероприятия, которые помогают им двигаться к общим целям и доставлять ценность бизнесу и клиентам. Такие команды самостоятельно планируют, разрабатывают и управляют своей работой, а также гибко реагируют на изменения по мере необходимости.

Большинство Agile команд использует SAFe Scrum. Однако некоторые Agile команды сталкиваются с непредсказуемой загрузкой и постоянно меняющимися приоритетами. В таких условиях итерационное планирование становится менее эффективным. Такие команды, как правило, выбирают SAFe Team Kanban для организации своей работы.

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

Рисунок 4. Обзор метода SAFe Team Kanban

Kanban повышает прозрачность и ускоряет поток работы, поэтому его всё чаще применяют в разных областях организации. Многие компании используют Kanban для внедрения Lean-Agile принципов не только в Agile командах, но и в таких отделах, как маркетинг, финансы, HR, юридическая служба, безопасность, соответствие регуляторным требованиям и операционная деятельность.

Модернизация разработки программного и аппаратного обеспечения

Хотя принципы Lean и Agile применимы как к разработке программного обеспечения, так и к аппаратному обеспечению, каждая из этих сфер имеет свои особенности. Цель в обоих случаях — интерактивная разработка и инкрементальная доставка. Однако сами домены существенно отличаются друг от друга из-за природы доставляемых результатов:

• Осязаемость:
  Программное обеспечение — нематериально, «неосязаемо», его можно легко изменять и обновлять. Аппаратные решения — это физические объекты, и любые изменения требуют производства и перенастройки, что делает итерации более дорогими и долгими.
• Циклы разработки:
  У программного обеспечения обычно короткие циклы разработки — это позволяет работать короткими итерациями и быстро реагировать на обратную связь. Разработка «железа» требует больше времени из-за проектирования, прототипирования, тестирования и производства.
• Гибкость:
  Программное обеспечение можно изменить практически в любой момент. Для аппаратурного оборудования необходимо более тщательное проектирование на старте, потому что менять физические компоненты потом трудно и дорого. Это влияет на то, как применяется принцип Agile «изменения приветствуются…».
• Тестирование:
  Тестирование ПО легко автоматизировать и повторять. Аппаратное тестирование связано с созданием физических прототипов и испытаниями в реальных условиях, что сложнее и дороже.
• Стоимость изменений:
  Внесение изменений в программный код стоит недорого. Для аппаратных решений это может потребовать значительных затрат на оборудование, утилизацию материалов и вызвать задержки в производстве.

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

Agile разработка ПО

Компании выбирают Lean-Agile подход в двух случаях: 1) когда текущие процессы перестают приносить желаемые результаты или 2) когда есть предположение, что эти процессы не будут эффективны в будущем.

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

• Облачная разработка (cloud-native):
  Облачная разработка на основе микросервисов разбивает приложения на небольшие независимые компоненты. Это упрощает развёртывание, масштабирование и изоляцию сбоев. Технологии вроде Docker и Kubernetes управляют этими сервисами, а бессерверные решения (serverless) позволяют разработчикам сосредоточиться на коде, не отвлекаясь на инфраструктуру.
• Новые технологии:
  Искусственный интеллект, машинное обучение и блокчейн способствуют повышению уровня автоматизации и обеспечивают безопасное управление данными, особенно в финансовом секторе и IoT (Интернет вещей).
• Мастерство программирования:
  Мастерство программирования подразумевает высокое качество кода, разработку на основе тестирования (TDD) и фокус на надёжность и эффективность работы ПО.
• Безопасность и конфиденциальность:
  Включение вопросов безопасности на каждом этапе жизненного цикла разработки ПО является обязательным. Также важно применять методы защиты конфиденциальности, такие как анонимизация и дифференциальная приватность.

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

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

Agile разработка аппаратного обеспечения

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

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

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

Рисунок 5. Инноваторы в компаниях аппаратного обеспечения проходят тот же путь, что и инноваторы в компаниях ПО

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

Компетенции в области Agile инженерии аппаратного обеспечения требуют сосредоточенности на следующих областях, при этом новые направления стремительно появляются:

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

Непрерывная доставка ценности с помощью DevOps и встроенного качества

DevOps объединяет процессы разработки (Development) и эксплуатации (Operations), формируя мышление и культуру, направленные на эффективную разработку и поддержку продуктов. Это достигается за счёт интеграции, автоматизации и сотрудничества между командами. DevOps устраняет организационные барьеры и помогает создать Конвейер Непрерывной Доставки (CDP). Конвейер Непрерывной Доставки — высокоэффективный инструмент для внедрения инноваций, который обеспечивает доставку передовых решений с необходимой для бизнеса скоростью.

Конвейер Непрерывной Доставки включает в себя четыре ключевых элемента:

• Непрерывное исследование (Continious Exploration) — для генерации и проверки идей;
• Непрерывная интеграция (Continuous Integration) – для обеспечения качества;
• Непрерывное развёртывание (Continuous Deployment) – для управления выпуском;
• Выпуск по требованию (Release on Demand) – для доставки ценности клиентам в нужное время, в соответствии с потребностями рынка.

Для развития DevOps и оптимизации Конвейера Непрерывной Доставки компании применяют:

• Инфраструктуру как код — для автоматизации и контроля версий инфраструктуры;
• Системы мониторинга и телеметрии — чтобы заранее выявлять и устранять проблемы;
• Принципы Agile архитектуры — такие как совместная работа, развивающийся дизайн (emergent design) и простота дизайна.

Таким образом, Agile команды непрерывно доставляют ценные для клиентов решения, быстро адаптируясь к меняющимся требованиям рынка и потребностям клиентов.

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

Встроенное качество (Built-in Quality)

Принцип встроенного качества (Built-in Quality) предполагает использование практик, которые позволяют Agile командам и поездам (Agile Release Train, ART) обеспечивать высокое качество на всех уровнях — от соблюдения нормативных требований до удовлетворения потребностей клиентов. Главное — встраивать качество в процессе создания, а не только проверять его в конце, перед выпуском. Такой подход снижает затраты и усилия на исправление ошибок на поздних стадиях, что ускоряет доставку ценности.

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

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

Баланс гибкости и строгих требований

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

Прослеживаемость (трассируемость, traceability) играет ключевую роль — она обеспечивает возможность контроля соответствия поведения системы её изначальному замыслу, связывая намерение (интент) решения с его компонентами.

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

Измерение и повышение эффективности команд и Поездов

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

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

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

Рисунок 6. 6 метрик потока в SAFe

Agile команды постоянно стремятся улучшать свои процессы и достигать лучших результатов. Для этого они придерживаются следующих практик:

• Проводят регулярные мероприятия по улучшению — Agile команды регулярно проводят ретроспективы на уровне команды внутри Интервала Планирования, обычно в конце каждой итерации. Эти встречи помогают выявлять возможности для улучшения процессов, практик и взаимодействия. Такой подход способствует повышению эффективности каждой команды. Кроме того, все команды в составе Поезда (ART) участвуют в совместном мероприятии «Инспект-Адапт», где определяются улучшения, которые принесут пользу всему ART в предстоящем PI.
• Немедленно устраняют препятствия — Некоторые проблемы нужно решать сразу, не дожидаясь следующего мероприятия по улучшению. Быстрая реакция на возникающие проблемы является частью культуры постоянного совершенствования.
• Обмениваются опытом с другими Agile командами — Agile команды делятся опытом и знаниями, приобретёнными при улучшении рабочих процессов. Это способствует повышению прозрачности и формированию культуры постоянного обучения как внутри Поезда (ART), так и во всей компании.

Заключение

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

Техническая гибкость достигается с помощью таких практик, как Конвейер Непрерывной Доставки (Continuous Delivery Pipeline, CDP). Он позволяет командам регулярно выпускать обновления и новые фичи. Например, это могут быть как ежедневные, так и ежемесячные релизы. Такой подход помогает быстрее реагировать на потребности клиентов и оперативно вносить изменения на основе их обратной связи. Это повышает качество продукта и уровень удовлетворённости пользователей.

Акцент на встроенном качестве гарантирует соблюдение высоких стандартов на всех этапах разработки. Это позволяет снизить технический долг и объём доработок, обеспечивая стабильный рабочий процесс и устойчивый ритм выпусков.

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

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Team and Technical Agility Discipline». Статья подготовлена по последней версии статьи на сайте вендора от 01.04.2025.

Другие дисциплины:

Дисциплина «Поток разработки продуктов»

Дисциплины в SAFe