Agile team что это: Agile команда 🦸‍♂️ — роли и организация работы в команде

Как создать лучшую agile-команду | Atlassian

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

Просмотр тем

Создание своей команды

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

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

ЧИТАЙТЕ НИЖЕ

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

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

Закладка прочного фундамента

Создав команду, не забывайте, что agile-команды похожи на людей: для их роста нужно время. Теоретики методологии agile часто ссылаются на стадии развития группы по Такмену. По мере своего развития agile-команда проходит через четыре основные стадии.

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

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

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

Подсказка

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

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

Сотрудничество agile-команд между отделами

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

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

Здесь кроется ловушка: если состав команды часто меняется, выйти на стадию функционирования становится невозможно.

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

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

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Управление Agile-проектами: роли и обязанности

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

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

Философия Agile ориентирована на самоорганизующиеся команды, сотрудничество и разделение ответственности за успех проекта между всеми участниками. И здесь возникают закономерные вопросы: А нужны ли в этом случае менеджеры проектов? Какую роль они играют в Agile-командах? 

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

‍

История Agile

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

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

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

Вот четыре фундаментальные ценности Agile-философии:

• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану. 
  

Как же именно эти принципы изменили управление проектами? 

‍

Каким образом осуществляется управление проектами в Agile?

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

Согласно 15-му отчёту State of Agile, среди наиболее веских причин для внедрения гибкого подхода участники опроса указывали следующее:

• Больше возможностей для управления меняющимися приоритетами.
• Сокращение времени на разработку программного обеспечения.
• Повышение производительности команды.
• Улучшение согласованности между бизнес-требованиями и ИТ-решениями.
• Повышение качества программного обеспечения.
  

Для реализации философии Agile команды могут использовать разные методы. Ниже приведен краткий обзор пяти популярных фреймворков.

‍

Scrum.

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

‍

Канбан.

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

‍

Экстремальное программирование или XP.

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

‍

Функционально-ориентированная разработка (FDD).

Фреймворк FDD разбивает проект на двухнедельные отрезки времени, в течение которых команда работает над определённой функцией продукта. Процесс разработки включает в себя пять видов деятельности: 

• Разработка общей модели
• Составление списка функций
• Планирование работы над каждой функцией
• Проектирование функции
• Реализация функции.

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

‍

Метод разработки динамических систем (DSDM)

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

Среди всех Agile-методологий самой популярной является Scrum. По данным отчёта State of Agile, по этому фреймворку работают 66% опрошенных и ещё 15% респондентов используют производные Scrum, такие как ScrumBan и Scrum/XP.   

Давайте подробнее рассмотрим основные принципы Scrum. 

‍

Scrum и Agile

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

‍

Scrum-команда. 

Фундаментальным компонентом в Scrum является кросс-функциональная, способная к самоорганизации команда. Она состоит из одного владельца продукта (Product Owner), одного Scrum-мастера и нескольких специалистов с различными навыками. Например, в Scrum-команду могут входить разработчики, тестировщики, дизайнеры и UX-специалисты. 

‍

Владелец продукта (Product Owner).

Владелец продукта отвечает за то, чтобы конечный продукт приносил максимальную пользу заказчику. Он анализирует требования, разъясняет бизнес-цели клиента команде и определяет приоритеты задач. 

‍

Scrum-мастер.

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

‍

Спринты.

Спринты — это повторяющиеся этапы, обычно продолжительностью от одной до четырех недель, во время которых команда работает над определенными задачами. На каждом из таких этап проводится планирование спринта, ежедневные Scrum-совещания, обзор итогов спринта и ретроспективы спринта.    

‍

Бэклоги продукта и спринта.

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

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

‍

Обязанности проджект-менеджеров в Аgile-проектах. 

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

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

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

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

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

‍

Ключевые навыки руководителя Agile-проектов.

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

‍

Коммуникационные навыки. 

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

‍

Организационные навыки. 

Менеджеры Agile-проектов должны обладать хорошими организационными навыками и уметь расстанавливать приоритеты. 

‍

Способность управлять рисками. 

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

‍

Адаптивность. 

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

Что касается технических навыков, то от проджект-менеджеров ожидается глубокое понимание принципов Agile, знание Agile-фреймворков (Scrum, Kanban и т.д.) и опыт работы с инструментами для управления задачами (Trello, JIRA и т.п.).

‍

Ресурсы для менеджеров Agile-проектов.

Существует множество книг, блогов и веб-сайтов для проджект-менеджеров, которые хотят углубить свои знания в области управления Agile-проектами. Ниже представлен краткий обзор нескольких полезных ресурсов:

• На сайте AgileAlliance есть обширный раздел со статьями, видео и презентациями. 
• Project Management Institute предлагает публикации и руководства по различным подходам к управлению проектами, включая Agile. 
• Множество статей, видеоматериалов и тематических исследований для изучения концепции Scrum можно найти на сайте ScrumAlliance.
• На платформе LeadingAgile есть статьи, подкасты и видеоролики по различным аспектам управления Agile-проектами.
• На сайте Scrum. org есть отличная подборка статей и видео по темам, связанным со Scrum. 
• ‍

Курсы по управлению Agile-проектами. 

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

• edX
• PMI
• Coursera
• LinkedIn Learning
• Scrum.org
• ScrumAlliance

Сертификаты для менеджеров Agile-проектов.

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

• PMI Agile Certified Practitioner (PMI-ACP). Этот сертификат выдаёт Институт управления проектами. Он подтверждает знание основных принципов Agile и различных Agile-фреймворков, таких как Scrum, Kanban, Lean, экстремальное программирование (XP) или разработка на основе тестирования (TDD).
• Certified Scrum Master (CSM) от ScrumAlliance — это всемирно признанный сертификат, который демонстрирует глубокое понимание Scrum-подхода и умение применять его на практике. 
• Международная ассоциация менеджеров проектов (International Association of Project Managers) предлагает три уровня сертификации в области Agile: Certified Junior Agile Project Manager (IAPM), Certified Agile Project Manager (IAPM) и Certified Senior Agile Project Manager (IAPM).
• ICP Certified Professional — это сертификат, который выдаёт Международный Agile-консорциум (International Consortium for Agile). Программа не ориентируется на конкретную методологию, а фокусируется на основополагающих концепциях Agile-философии.
• Широко признаваемый в отрасли сертификат Professional Scrum Master I выдаёт Scrum.org. Его наличие подтверждает экспертное знание основополагающих принципов фреймворка Scrum и способность применять в управлении проектами.  
  

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

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

‍

Запись на курс Manual QA

Agile Teams — Масштабируемая Agile Framework

Ничто не сравнится с Agile Team.

— Мантра SAFe

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

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

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

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

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

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

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

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

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

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

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

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

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

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, улучшающие реализацию модели

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

Большинство команд начинают свое путешествие по 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-команды

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

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

Сервисно-ориентированная программа

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

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

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

В центре внимания клиент

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

Помимо качества (функционального и нефункционального), он обычно представляет такие показатели предоставления услуг, как скорость доставки (сквозная продолжительность), предсказуемость, количество и т. д. Для их измерения можно использовать такие показатели, как количество потенциальных клиентов. и время цикла, незавершенное производство (Work In Progress), производительность и т. д., а также диаграммы, которые помогут вам визуализировать и проанализировать, как вы создаете ценность.

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

Управляйте работой, а не людьми

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

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

Развитие политик для улучшения бизнес-результатов

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

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

Как управлять услугами с помощью Канбана на практике?

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

Давайте посмотрим, как вы можете добиться этого на практике ниже.

Определение различных типов работ и управление ими на доске Канбан

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

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

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

Введение классов обслуживания для повышения предсказуемости

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

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

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

Визуализация межгрупповых зависимостей для упрощения совместной работы

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

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

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

В итоге

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

Как создать лучшую agile-команду | Atlassian

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

Просмотр тем

Создание своей команды

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

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

ЧИТАЙТЕ НИЖЕ

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

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

Закладка прочного фундамента

Создав команду, не забывайте, что agile-команды похожи на людей: для их роста нужно время. Теоретики методологии agile часто ссылаются на стадии развития группы по Такмену. По мере своего развития agile-команда проходит через четыре основные стадии.

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

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

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

Подсказка

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

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

Сотрудничество agile-команд между отделами

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

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

Здесь кроется ловушка: если состав команды часто меняется, выйти на стадию функционирования становится невозможно.

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

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

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Моя шпаргалка по Скраму для подготовки к интервью. Часть 1 / Хабр

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

Данная шпаргалка не исключает чтение Скрам-гайда 2020 года. Скачать гайд можно по ссылке.

Почитать про Скрам и посмотреть полезные видео можно в базе знаний Atlassian. Ссылка тут.

Что такое Скрам

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

Определение из гайда:

“Скрам — это легкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем.”

В чем же заключается отличие фреймворка от методологии? В целом, вещи достаточно похожие, обе определяют правила и церемонии, которым необходимо следовать. Но в самом определении фреймворка кроется ответ — слово “адаптивность”, и оно и является главным различием. Для того, чтобы понять это различие, нужно просмотреть таблицу ниже:

Таблица 1. Методология VS Фреймворк

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

Как работает Скрам

Многие, кто не работал со Скрамом, часто рассказывают на интервью роли, артефакты и церемонии, но сыпятся на самых простых вопросах, которые требуют понимания работы Скрам. 

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

Если отбросить детали, то для работы по фреймворку Скрам нам понадобится Скрам-команда (или Scrum team), которая обычно достаточно маленькая. Эта команда работает над созданием маленьких работающих (приносящих ценность) кусочков продукта через определенные отрезки времени.

Мне нравится пример с выпечкой тортика, он немного глупый, но зато дает хорошее наглядное представление.

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

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

Для того, чтобы в определенный отрезок времени (Sprint) получить кусочек торта (Increment), у команды должен быть список задач для того, чтобы испечь торт полностью (Product backlog), разделенный на списки задач поменьше для создания каждого кусочка торта (Sprint backlog). Для координации действий команды выпечки, необходимо проводить специальные церемонии (можно еще назвать их Scrum events или событиями). 

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

Роли в Скрам

Для того, что Скрам заработал создается Scrum team:

Внутри каждой Scrum team можно выделить роли, у каждой есть своя собственная зона ответственности: 

Таблица 2. Роли в Скрам

События Скрам

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

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

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

После прочтения таблицы, намного легче понять, почему три столпа: Прозрачность, Инспекция, Адаптация, так важны в Скраме:

• Прозрачность делает возможной инспекцию. Инспекция без прозрачности вводит в заблуждение и является потерями. 

• Инспекция делает возможной адаптацию. Инспекция без адаптации считается бессмысленной. События Scrum спроектированы так, чтобы провоцировать изменения.

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

Артефакты в Скрам

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

К артефактам Скрама относятся следующие элементы, каждый из которых имеет свое собственное конечное состояние, к которому стремится вся команда:

Организация 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 — релизному поезду.
• Как организовать команды внутри поезда.
• Как топологии помогают описывать отношения поездов в рамках крупного решения.

Кажется, что от типа поезда или команды должны зависеть не только состав участников, но и цели, способы взаимодействия, ответственность, фокус, продукт или оказываемый сервис команды (или поезда). А “карта” команд в поезде или поездов в решении способна привнести дополнительный уровень прозрачности в организацию зависимостей и ожиданий.

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



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

Agile Teams — Масштабируемая Agile Framework

Ничто не сравнится с Agile Team.

— Мантра SAFe

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

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

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

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

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

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

Создавая и поддерживая решения, которые приносят пользу клиентам, Agile-команды питают предприятие. Как описано в статье SAFe о компетенции Team and Technical Agility, движение Agile [1] стало важным поворотным моментом в разработке программного обеспечения и систем. Он породил целостный набор ценностей, принципов и практик, которые привели к созданию высокоэффективных команд. В SAFe Agile-команды являются строительными блоками для создания и предоставления ценности.

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

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

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

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

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

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

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

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

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

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

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

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

Agile-команды имеют две специальные роли. Владелец продукта определяет истории (вместе с другими членами команды) и расставляет приоритеты в невыполненной работе команды, чтобы упростить выполнение приоритетов программы. В то же время они также поддерживают концептуальную и техническую целостность работы, за которую отвечает команда. Scrum Master — лидер-слуга и тренер команды. Эта роль прививает согласованный процесс Agile, помогает устранить препятствия на пути прогресса и способствует созданию среды для высокой производительности, непрерывного потока и неустанного улучшения.

Рисунок 2. Agile-команды включают две специальные роли

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

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

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

Все команды:

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

Команды, занимающиеся программным обеспечением, оборудованием, ИТ, операциями и другими технологиями:

• Применение методов, ориентированных на тестирование, включая разработку через тестирование (TDD) для модульных тестов и разработку через поведение (BDD) для автоматизированных приемочных тестов
• Сотрудничайте с архитекторами, используя Agile Architecture
• Используйте лучшие практики проектирования и реализации для создания высококачественных компонентов и решений
• Управление изменениями в общем репозитории
• Выполнение приемочных тестов и сохранение тестовых случаев в общем репозитории

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

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

Дополнительные рекомендации по применению Agile в конкретных областях бизнеса и техники можно найти в статье Бизнес и технологии.

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

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

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

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

Команды, ориентированные на поток

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

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

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

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

• Конкретное решение или набор решений
• Набор функций
• Конкретный образ клиента
• Конкретные этапы пути клиента
• Конкретный бизнес-домен
• Соответствие и нормативные требования
• Инновационный продукт

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

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

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

Команда сложной подсистемы

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

Скелтон и Паис признают это, определяя цель группы сложной подсистемы:

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

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

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

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

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

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

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

Команды платформы

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

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

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

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

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

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

Включение групп

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

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

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

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

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

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

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

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

Agile-команды обычно сочетают Agile-методы

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

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

Agile-команды в процессе обучения

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

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

Планируйте вместе

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

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

Демонстрация вместе

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

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

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

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

Все команды SAFe вовлечены в  неустанное улучшение (дополнительную информацию см. в опоре 4 в статье Lean-Agile Mindset и в третьем измерении CLC). В дополнение к ретроспективам итераций и специальным усовершенствованиям процессов команды также участвуют в мероприятиях ART Inspect and Adapt (I&A), где они выявляют и приоритизируют элементы незавершенной работы по улучшению, которые включаются в следующие сеансы планирования PI. Команды и ART продвигаются вперед по одной итерации и PI за раз. Обучение не ограничивается ретроспективами. Это происходит постоянно, и ему также способствуют сообщества практиков (CoPs), созданные для того, чтобы помочь отдельным лицам и командам развивать свои функциональные и кросс-функциональные навыки.

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

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

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

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

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

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

---

Узнать больше

[1] Манифест гибкой разработки программного обеспечения. http://AgileManifesto.org/ [2] Руководство: Понимание эффективности команды. https://rework.withgoogle.com/print/guides/5721312655835136/ [3] Скелтон, Мэтью и Мануэль Паис. Командные топологии. IT Revolution Press, 2019. [4] Леффингуэлл, Дин. Масштабирование гибкости программного обеспечения: передовой опыт для крупных предприятий . Аддисон-Уэсли, 2007 г. [5] Ленсиони, Патрик. Пять пороков команды: басня о лидерстве. Джосси-Басс, 2002. [6] Маккристал, Стэнли (генерал в отставке) и др. Team of Teams: новые правила боя для сложного мира. Издательская группа Penguin, 2015. [7] Марке, Дэвид. Развернуть корабль . Группа пингвинов, 2013 г.

 

Последнее обновление: 27 сентября 2021 г.

 

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

Автор

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

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

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

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

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

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

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

ЧИТАЙТЕ НИЖЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.

Триада	Кто	Фокус
Создавать	Принципы управления продуктом как потребителем,	0533
	Design	Define the value proposition, product goals, and minimum viable product
	Development	Develop the product using sound, sustainable engineering practices
Sell	Product Management	Понимать конкурентную среду продукта и эволюцию рынка
	Дизайн	Создавайте сообщения, которые подчеркивают ценностные предложения продукта для каждого сегмента клиентов
	Разработка	Реагирование на вопросы клиентов
	Поддержка и эксплуатация	Передача отзывов клиентов триаде производителя (Разработка, Проектирование, Дизайн) в качестве исходной информации для будущей разработки продукта

Клэр Драмонд

Клэр Драмон – маркетолог, спикер и писатель Atlassian. Она является автором многочисленных статей, опубликованных в блогах Trello и Atlassian, и регулярно публикует различные публикации на Medium, включая HackerNoon, Art+Marketing и PoetsUnlimited. На технических конференциях по всему миру она рассказывает об agile, преодолении разрозненности и развитии эмпатии.

Что такое Agile-команда? Структура и принципы

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

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

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

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

Эволюционный подход к построению структуры Agile-команды

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

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

Сервисно-ориентированная программа

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

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

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

В центре внимания клиент

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

Помимо качества (функционального и нефункционального), он обычно представляет показатели предоставления услуг, такие как скорость доставки (длительность от начала до конца), предсказуемость, количество и т. д. Чтобы измерить их, вы можете использовать такие показатели, как опережение и цикл. время, незавершенное производство (Work In Progress), пропускная способность и т. д., а также диаграммы, которые помогут вам визуализировать и проанализировать, как вы создаете ценность.

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

Управляйте работой, а не людьми

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

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

Развитие политик для улучшения бизнес-результатов

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

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

Как управлять услугами с помощью Канбана на практике?

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

Давайте посмотрим, как вы можете добиться этого на практике ниже.

Определение и управление различными типами работ на доске Канбан

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

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

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

Введение классов обслуживания для повышения предсказуемости

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

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

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

Визуализация межгрупповых зависимостей для упрощения совместной работы

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

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

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

В итоге

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

No related posts.