Agile Команда

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

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Agile Команда в SAFe организации

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

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

• Бюджетные направляющие и другие бизнес-параметры
• Инфраструктура
• Контракты и поставщики
• Обучение конечных пользователей
• Юридическое сопровождение
• Маркетинг
• Экспертиза в области безопасности и соответствия требованиям
• Пригодность для использования
• Знание о решении

Оба типа команд стремятся к быстрому обучению, выполняя работу небольшими партиями, оценивая результаты и внося соответствующие корректировки. Все Agile команды в SAFe включают в себя две ключевые роли: Скрам Мастер и Владелец Продукта. Ни один поезд не может существовать без Agile-команд. Они обеспечивают работу Релизного Поезда Agile (Agile Release Train, ART) и, в конечном счете, всего предприятия.

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

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

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

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

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

Командность и высокоэффективные команды

Для создания великих команд недостаточно иметь талантливых людей: ключевую роль здесь играют организация и динамика команды. На самом деле, то, кто персонально находится в команде, оказывает меньшее влияние на производительность команды, чем то, как команда работает вместе [2].

Высокоэффективные команды имеют много общих характеристик «командности»:

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

Для того, чтобы глубже разобраться, как люди с Бережливым мышлением и Agile команды достигают лучших бизнес-результатов, можно рекомендовать обратиться к описанию компетенции SAFe «Организационная Гибкость» (Organizational Agility).

Agile команда является кросс-функциональной

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

Agile команды:

• Определяют – Команды независимо разрабатывают и проектируют фичи и истории, чтобы выполнить свою миссию
• Разрабатывают/Создают – Команды имеют все необходимые навыки для создания артефактов, чтобы соответствовать своей миссии
• Тестируют – Команды несут ответственность за качество и работоспособность разработанных артефактов
• Развертывают – Команды развертывают инкременты ценности, где это применимо

Рисунок 1. Agile команды являются кросс-функциональными

Две специальные роли в Agile команде

Гибкие команды имеют две специальные роли.

Владелец продукта:

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

Скрам мастер:

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

Четко определенные обязанности Agile команд

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

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

Все команды:

• Взаимодействуют с Владельцем Продукта для создания и уточнения пользовательских историй и критериев приемки
• Участвуют в PI Планировании, определяют Планы на итерации и Цели команды на Инкремент Программы
• Разрабатывают и берут на себя обязательства за выполнение Целей Итерации и Целей команды на Инкремент Программы
• Оценивают размер и сложность своей работы
• Используют парную работу и другие практики для частой проверки (review) выполненной работы
• Определяют технический дизайн в областях, за которые они отвечают, в соответствии с архитектурными рекомендациями
• Проводят исследования, проектирование, прототипирование и другие исследовательские работы
• Реализуют и интегрируют изменения небольшими партиями
• Создают работающие продукты, которые определены с помощью набора Фич
• Тестируют работающие продукты, определенные в соответствии с набором Фич
• Развертывают работающие продукты в промежуточной и производственной средах
• Поддерживают эксплуатируемые бизнес-решения
• Поддерживают и/или автоматизируют процесс, необходимый для построения конвейера непрерывной доставки (Continuous Delivery Pipeline, CDP)
• Постоянно улучшают процессы работы команды

Команды, ориентированные на технологии (программное обеспечение, оборудование, ИТ, операционная деятельность и др.):

• Применяют практики раннего тестирования, включая Разработку на основе тестирования (Test-Driven Development, TDD) для модульных тестов и Разработку на основе поведения (Behavior-Driven Development, BDD) для автоматизации приёмочных тестов
• Взаимодействуют с архитекторами, используя Agile архитектурные подходы
• Применяют лучшие практики проектирования и разработки для создания высококачественных компонентов и решений
• Управляют изменениями в едином репозитории
• Выполняют приёмочные тесты и управляют сценариями тестирования в едином репозитории

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

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

Agile команды организованы вокруг ценности

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

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

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

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

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

Скелтон и Паи определяют «потоковую» команду следующим образом:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя все решения могут быть декомпозированы на подсистемы, не все подсистемы требуют наличие команд сложной подсистемы. Уровень экспертизы, сложность и риск должны быть единственными решающими факторами для создания таких команд. В качестве общего правила можно ориентироваться на то, что в одном Agile Release Train не должно быть больше 1-3 команд сложных подсистем.

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

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

Команда платформы (Platform Team)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile команды обычно смешивают Agile методы

Наиболее популярные Agile методы, которые используют команды для повышения своей производительности в SAFe организации — это, прежде всего, Скрам (Scrum), Канбан (Kanban) и Экстремальное Программирование (Extreme Programming, XP). Чтобы убедиться, что команды работают над правильной задачей, применяется Дизайн-мышление. Чтобы упорядочить разработку контента и обеспечить качество, команды используют практики встроенного качества. Коллективное владение, парная работа, стандарты, раннее тестирование (test-first) и непрерывная интеграция (Continuous Integration, CI) помогают сохранить бережливость, внедряя качество и операционную эффективность непосредственно в процесс.

Однако, поскольку SAFe является системой, основанной на потоке, большинство команд также применяют Канбан для визуализации своей работы, устанавливают ограничения незавершенной работы (НЗР, Work in Process, WIP) и используют кумулятивные диаграммы потока (Cumulative Flow Diagrams, CFD) для иллюстрации узких мест и основных возможностей для повышения пропускной способности. Некоторые команды выбирают Канбан в качестве основной практики. Это связано с тем, что организация элементов планирования и обязательства в Scrum не могут эффективно применяться для работ, основанных на производимых действиях и спросе, где приоритеты меняются значительно чаще (например, команды поддержки).

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

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

Рисунок 4. Agile команды планируют, демонстрируют и учатся вместе

Планировать вместе

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

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

Демонстрировать вместе

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

Команды применяют практики встроенного качества и участвуют в непрерывных исследованиях, непрерывной интеграции и непрерывном развертывании. Это происходит внутри команды и в рамках всего поезда в процессе подготовки к агрегированной демонстрации системы (System Demo), которая происходит регулярно для закрытия каждой итерации.

Учиться вместе

Сегодняшние реалии требуют от организаций работать в условиях неопределенности и быстро реагировать на потенциальные возможности. В связи с этим Культура Непрерывного Обучения (Continuous Learning Culture, CLC) в SAFe призывает организации создавать культуру быстрого и эффективного обучения на всех уровнях. Команды и люди являются сердцем Обучающейся Организации (измерение CLC), которая стимулирует инновации для предприятия. SAFe способствует развитию инновационных людей (еще одно измерение CLC) с помощью многих практик, включая время и пространство для инноваций, эксперименты и обратную связь, а также «инновационные быстрины-водовороты» (innovation riptides).

Все Agile команды в SAFe организации участвуют в неустанных улучшениях. В дополнение к Ретроспективам Итераций и усовершенствованиям в процессе работы команды также участвуют в мероприятии Инспект-Адапт (Inspect and Adapt, I&A). На этом мероприятии они определяют и приоритизируют в беклоге элементы улучшений, которые включаются в ближайшие сессии планирования Инкремента Программы. Agile команды и Agile Release Train продвигаются вперед по одной Итерации и одному Инкременту Программы (Program Increment, PI) за раз. Обучение не ограничивается ретроспективами. Это происходит постоянно и стимулируется Сообществами Практик (Communities of Practice, CoP). CoP создаются, чтобы помогать отдельным сотрудникам и целым командам развивать свои функциональные и кросс-функциональные навыки.

Исследовать, интегрироваться, развертывать и выпускать отдельно

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

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

Сотрудничество и культура

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

Постоянное общение и сотрудничество, наряду с полномочиями для принятия быстрых решений, позволяет командам выполнять свои обязанности. Организации стремятся к размещению команд в одной физической локации, хотя это не всегда практично. Существует целая инфраструктура виртуального пространства и технологии, обеспечивающие связь и возможность совместно работать для распределенных членов команд за пределами «основной» площадки. Стандартные мероприятия команд в некоторой степени зависят от выбранного для этой команды Agile метода, но они обычно включают в себя Eжедневный стендап (Daily Stand-Up, DSU), Планирование Итерации (Iteration Planning), Обзор Итерации (Iteration Reviw), Уточнение Беклога (Backlog Refinement) и Ретроспективу Итерации (Iteration Retrospective).

Читать дополнительно:
[1] Manifesto for Agile Software Development. http://AgileManifesto.org/
[2] Guide: Understand team effectiveness. https://rework.withgoogle.com/print/guides/5721312655835136/
[3] Skelton, Mathew, and Manuel Pais. Team Topologies. IT Revolution Press, 2019.
[4] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[5] Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass, 2002.
[6] McChrystal, Stanley (Retired General), et al. Team of Teams: New Rules of Engagement for a Complex World. Penguin Publishing Group, 2015.
[7] Marquet, David. Turn the Ship Around. Penguin Group, 2013.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом. Оригинал статьи: https://www.scaledagileframework.com/agile-teams/