Традиционно проект организуется вокруг групп компонентов (например, UX, разработчиков, бизнес-специалистов, тестировщиков и т. д.), любой выпуск, требующий широкого спектра компонентов, должен включать в себя несколько групп компонентов. Как правило, разные команды имеют разные наборы приоритетов, что неизбежно приводит к узким местам в цикле выпуска продукта.
Согласно Википедии, кросс-функциональная команда — это группа людей с разным функциональным опытом, работающих над достижением общей цели. Один из лучших способов улучшить качество вашей команды — сделать ее кросс-функциональной. Кросс-функциональная команда обладает всеми необходимыми навыками для превращения идеи в работающий продукт.
« Кросс-функциональные команды обладают всеми компетенциями, необходимыми для выполнения работы, не завися от других, не являющихся частью команды » — Руководство по Scrum .
В отличие от компонентно-командного подхода кросс-функциональные команды представляют собой группы, состоящие из людей из разных функциональных областей компании. — он должен состоять не только из технических специалистов (бэк-энд, фронтенд-разработчики, QA-инженеры и т. д.), но и состоять из таких участников, как бизнес-аналитики, маркетологи и UX-специалисты или кто-либо еще, принимающий активное участие в проекте.
Самоорганизующаяся команда — это команда, которая самостоятельно выбирает, как лучше всего выполнять свою работу, а не руководится другими людьми, не входящими в команду. В отличие от традиционных принципов управления, самоорганизующиеся уполномоченные команды не управляются и не контролируются сверху; скорее они развиваются из членов команды, активно и коллективно участвующих во всех практиках и мероприятиях Scrum.
Традиционная команда против Agile-команды
«Команда самоорганизации состоит из группы работников умственного труда, которые должны управлять собой. У них должна быть автономия», — Питер Друкер.
В Руководстве по Scrum указано: «Scrum-команда состоит из владельца продукта, команды разработчиков и Scrum-мастера. Они есть:
« Scrum-команды самоорганизуются и кросс -функциональны » — Руководство по Scrum:
Компонентная команда против функциональной группы
Традиционный подход состоит в том, чтобы разбить продукт более или менее логично и осмысленно на компоненты и присвоить им группы компонентов. Однако эти компоненты совершенно не имеют отношения к точке зрения клиента.
Подход функциональной группы в настоящее время является почти общепринятым способом организации своих команд, в отличие от команды технологического стека, особенно в подходе непрерывной доставки он делает упор на функции (т.е. вертикальный срез системы), которые решают потребности пользователей, которые обычно могут ускорить ценность доставки любых функций или работающего программного обеспечения и сокращение цикла обратной связи от реальных пользователей. Специализированная группа будет иметь все навыки для выполнения необходимой работы на уровне задачи, чтобы выполнить работу. В частности, предполагая трехуровневую архитектуру, члены команды будут работать над задачами, связанными с графическим интерфейсом, промежуточным уровнем и частями этой истории.
Большой недостаток компонентной организации очевиден: она замедляет поток ценности. Большинство системных функций создают зависимости, которые требуют сотрудничества между компонентными группами для создания, развертывания и, в конечном итоге, выпуска. Команды тратят большую часть своего времени на обсуждение взаимосвязей между командами и тестирование поведения компонентов, а не на обеспечение ценности для конечного пользователя.
Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文