Team agile: Agile Teams — Agile-команды — Глоссарий SAFe®

Характеристики Agile-команд

Все Agile-команды имеют определенные определяющие характеристики, как описано в следующих разделах.

Команды составляют ART

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

В этой статье описываются общие характеристики и обязанности для всех типов команд SAFe Agile.

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

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

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

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

Принцип SAFe № 10. Организация вокруг ценности. Он помогает предприятиям объединять людей и команды вокруг одной цели: непрерывного предоставления ценности клиенту. Но для этого они должны подумать о том, как лучше спроектировать свои Agile-команды. Как описано в книге Team Topologies [1], SAFe рекомендует четыре основных способа организации Agile-команд (рис. 2).

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

Дальнейшие указания по этому важному аспекту организации Agile-команд можно найти в статье расширенного руководства «Организация Agile-команд и ART: топологии команд в масштабе».

Высокая производительность

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

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

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

Активируется критическими ролями

Agile Teams дополнительно активируются двумя специальными ролями (рис. 3).

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

2. Scrum Master / Team Coach (SM/TC) помогает внедрять и поддерживать методы Agile, оптимизировать и улучшать работу команды, сотрудничает с RTE, чтобы направлять улучшения всего ART, а также помогает оптимизировать поток ценности.

Когда Agile-команда применяет SAFe Scrum, SM/TC обладает специальными навыками, способствующими эффективному внедрению SAFe Scrum. Когда команда применяет SAFe Team Kanban, SM/TC обладает специальными навыками, которые способствуют эффективному внедрению Kanban.

Создание потока с помощью Scrum и Kanban

Каждая Agile-команда отвечает за создание быстрого и надежного потока ценности для клиента. Они достигают этого, осваивая два основных аспекта (рис. 4):

1. Модель работы команды — SAFe Scrum или SAFe Team Kanban
2. Ускорители SAFe Team Flow, улучшающие реализацию модели

SAFe Scrum и SAFe Team Kanban предоставляют набор практик, которыми руководствуется команда. Сюда входят события, коммуникационные стратегии и особые правила, определяющие ход работы. Но эти методы лучше всего работают с базовой парадигмой, которая помогает команде максимизировать поток ценности для клиента. Ускорители потока SAFe (принцип SAFe № 6) обеспечивают эту руководящую парадигму. В рамках этого команд:

• Работа небольшими партиями
• Держите незавершенное производство под контролем
• Адресация узких мест
• Периодически проводить ретроспективный анализ продукта и процесса

Большинство команд начинают свое путешествие по Agile с принятия SAFe Scrum.

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

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

Обязанности

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

Каждый описан в разделах ниже.

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

Связь с клиентом

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

• Развивали сочувствие к клиенту — Чтобы создать отличный продукт для клиента, команда должна думать как клиент.
  Однако часто из-за нескольких степеней оторванности от клиента командам может быть трудно понять реальные потребности клиентов и то, что представляет для них ценность. Таким образом, важно увеличить контакт команды с контекстом клиента. Есть много способов сделать это, в том числе:
• Использование навыков, знаний и обязанностей владельцев продукта
• Установление прямой связи с клиентом
• Участие в поддержке решения
• Прямое наблюдение за покупателем в действии
• Внедрение телеметрии решения для мониторинга использования

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

• Участие в определении продукта — Члены Agile-команды используют свои знания о клиентах для создания пользовательских историй и критериев приемлемости. В то время как за видение решения и определение функций отвечает Управление продуктом, именно команды создают истории, соответствующие этому видению, под руководством владельца продукта (PO).
• Разработка и проведение экспериментов — В рамках исследования клиентов и решений Agile-команды планируют, выполняют и анализируют результаты различных экспериментов. Они внедряют всплески исследований, модели с низкой точностью и прототипы, чтобы получить быструю обратную связь.

Планирование работы

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

• Планирование ART — Планирование PI — это мероприятие, на котором каждая Agile-команда согласовывает свои действия с остальными участниками поезда и создает свой отставание для предстоящего PI. PI Planning обеспечивает более широкое системное представление, необходимое для достижения общей цели. В результате планирования PI команда создает набор целей PI и план на уровне истории запланированного хода работы по итерациям. Это посеет бэклог команды для предстоящего PI.
• Планирование команды – После согласования АРВТ команды регулярно проводят краткосрочное планирование во время PI. Целью этого планирования является использование новых знаний и планирование следующего краткого приращения ценности. Подход к планированию различается в зависимости от того, применяет ли команда SAFe Scrum или SAFe Team Kanban.
• Уточнение бэклога команды – По мере появления новых знаний команды постоянно обновляют и совершенствуют свой бэклог. Бэклог используется для определения и приоритизации предстоящей работы, которую им необходимо выполнить, чтобы добиться поставленной цели.

Создание ценности

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

• Частая интеграция и тестирование — Быстрый ритм разработки требует частой интеграции и тестирования. Это помогает выявлять технологии и проблемы внедрения на раннем этапе и дает командам достаточно времени, чтобы отреагировать на обнаруженные недостатки. В статьях о встроенном качестве, а также о командной и технической гибкости содержится более подробное руководство по этим практикам.
• Регулярная синхронизация с остальной частью поезда — При выполнении PI у команды есть несколько контрольных точек с остальной частью поезда. Это может происходить в форме ART Sync, которая включает в себя Coaches Sync и PO Sync. Эти события создают видимость прогресса в достижении текущих целей PI и помогают ART своевременно вносить коррективы.
• Создание конвейера непрерывной доставки . Эффективный процесс гибкой разработки также зависит от конвейера непрерывной доставки, который имеет механизмы непрерывного исследования, непрерывной интеграции и непрерывного развертывания. Обычно для этого требуется картирование потока создания ценности для выявления источников задержек и чрезмерной изменчивости.

• Частые выпуски — Некоторые команды могут выпускать выпуски непосредственно для клиента. Эти группы могут — обычно в сотрудничестве с некоторыми специализированными группами или общими службами — устанавливать собственный процесс выпуска. Решения о том, когда выпустить ценность, обычно принимаются на разных уровнях: основные выпуски могут приниматься во время планирования PI; рутинные развертывания регулируются на уровне итерации. Другие могут даже управляться событиями.

Получение отзыва

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

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

Неустанное совершенствование

Неустанное совершенствование — основная ценность SAFe. Agile-команды постоянно ищут способы улучшить свои процессы и результаты, за которые они несут ответственность.

SAFe предлагает комплексный подход к измерению компетентности, потока и результатов — трех основных показателей, прогнозирующих бизнес-результаты (рис. 6).

В рамках усилий по улучшению команды делают следующее:

• Проводят плановые мероприятия по улучшению — Многие команды регулярно проводят ретроспективы на уровне команды во время итераций. Кроме того, все команды АРТ участвуют в совместном мероприятии «Проверка и адаптация» с руководителями, чья помощь может иметь решающее значение для разработки и реализации необходимых корректирующих действий.
• Немедленно улучшите некоторые вещи — Некоторые проблемы следует решать по мере их возникновения, не дожидаясь следующего события улучшения. Решение проблем по мере их возникновения является неотъемлемой частью культуры постоянного совершенствования.

Подробнее

[1] Скелтон, Мэтью и Мануэль Паис. Team Topologies: Организация бизнес- и технологических групп для Fast Flow. IT Revolution Press, 2019.

Последнее обновление: 14 марта 2023 г.

Информация на этой странице © Scaled Agile, Inc., 2010-2023 и защищена законами США и международными законами об авторских правах. Ни изображения, ни текст не могут быть скопированы с этого сайта без письменного разрешения правообладателя. Scaled Agile Framework и SAFe являются зарегистрированными товарными знаками Scaled Agile, Inc. Посетите раздел часто задаваемых вопросов о разрешениях и свяжитесь с нами для получения разрешений.

Автор

• Дин Леффингуэлл —

Как создать крутую agile-команду

Узнайте о динамике, культуре и сотрудничестве agile-команды и создайте отличную agile-команду.

Просмотреть темы

Создайте свою команду

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

Несмотря на общие ценности, формулы идеальной agile-команды не существует. Одни внедряют скрам, другие используют канбан. Сторонники Agile предпочитают совместные команды, но реалии бизнеса иногда требуют распределения agile-команды по географическим регионам. Большинство agile-команд обладают всеми необходимыми навыками, но иногда приходится вызывать специалистов для конкретной работы. Итак, как узнать, находится ли ваша команда на пути к величию? Читай дальше.

ЧИТАЙТЕ НИЖЕ

Статьи о Agile-командах

[ПРОДОЛЖЕНИЕ]

Построение на прочном фундаменте

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

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

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

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

Совет от профессионала:

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

Есть еще два столпа отличных agile-команд: постоянное наставничество и общие наборы навыков. Одним из больших преимуществ работы в команде является то, что коллеги учатся друг у друга и наставляют друг друга. Наставничество — это не просто деятельность младших членов, позволяющая им учиться у старших членов. Все в команде учатся друг у друга, так что влияние команды в целом больше, чем сумма влияния отдельных ее членов. Между тем, общие наборы навыков открывают возможности команды для решения разнородной работы. Для инженеров всегда важно приобретать новые навыки, потому что это делает нас более ценными для организации и лучше подготовленными для поддержки друг друга в работе. Это также защищает от того, чтобы кто-то стал критическим путем, что снимает нагрузку с ума каждого.

Как agile-команды сотрудничают между отделами

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

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

Вот в чем загвоздка: достижение стадии «выступления» невозможно, если состав команды сильно меняется.

Независимо от того, в какой триаде работает ваша команда, Agile может помочь вашей команде работать быстрее и получать больше удовольствия. Изучите этот раздел и узнайте, как сфокусировать и оптимизировать agile-команды.

Triad	WHO	FOCUS
MAKE	Управление продуктом	Понимает рынок.0362
	Дизайн	Определение ценностного предложения, целей продукта и минимально жизнеспособного продукта
	Разработка		Продажа	Управление продуктами	Понимание конкурентной среды продукта и эволюции рынка
	Дизайн	Создание сообщений, которые подчеркивают ценностные предложения продукта для каждого сегмента клиентов
	Маркетинг	Создание вспомогательных материалов для поддержки запуска продукта: веб-страницы, объявления по электронной почте, блоги, видео и т. No related posts. alexxlab Автор записи Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт