Кросс-функциональные, самоорганизующиеся, функциональные и компонентные команды в Agile

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

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

« Кросс-функциональные команды обладают всеми компетенциями, необходимыми для выполнения работы, не завися от других, не являющихся   частью команды » — Руководство по Scrum .

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

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

Традиционная команда против Agile-команды

«Команда  самоорганизации  состоит из группы работников умственного труда, которые должны управлять собой. У них должна быть автономия», —  Питер Друкер.

В Руководстве по Scrum указано: «Scrum-команда состоит из владельца продукта, команды разработчиков и Scrum-мастера. Они есть:

« Scrum-команды  самоорганизуются  и  кросс  -функциональны » —  Руководство по Scrum:

Компонентная команда против функциональной группы

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

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

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