Component Team
Component Team — традиционная организация команд по техническим компонентам. До-Agile норма во многих компаниях, до сих пор встречается.
Примеры Component Team
- Frontend-команда (только web/mobile UI).
- Backend-команда (только API).
- Database-команда (только схема и миграции).
- Mobile-команда (только iOS/Android).
- Infrastructure-команда (DevOps).
Плюсы
- Глубокая экспертиза по технологии.
- Удобство менеджмента (понятная иерархия).
- Меньше дубликатов кода.
Минусы
- Каждая фича = координация многих команд. Простая user story «добавить кнопку» = задача frontend + backend + БД, минимум 2 спринта вместо одного.
- Медленный time-to-market.
- «Бросание через стену» — каждая команда не видит конечной ценности.
- Очереди задач: одна команда блокирует другие.
В Agile-литературе Component Team считается антипаттерном для продуктовой разработки. SAFe и LeSS явно рекомендуют Feature Teams. Component Teams оправданы только для инфраструктуры, общих платформ и сильно специализированных областей.
Когда применять и когда нет
Применять
- Платформенная команда (общая инфраструктура)
- Очень узкоспециализированный домен
- Команда поддержки legacy-стека
Не применять
- Продуктовая разработка с фокусом на time-to-market
- Любая user-facing-разработка — лучше Feature Teams
Примеры применения
Backend-команда (Component) поддерживает API. Frontend-команда (Component) делает UI. Чтобы выкатить новую фичу «фильтр по дате», PO ставит задачу в backend-бэклог, ждёт спринт, потом ставит в frontend-бэклог, ждёт ещё спринт. Total: 4 недели вместо 2 в Feature Team.
Часто задаваемые вопросы
Для инфраструктурных команд (DevOps, общие сервисы), сильно специализированных доменов (ML-research) и legacy-стеков. Для продуктовой разработки — антипаттерн.
Постепенно: расформируйте крупные функциональные отделы, перенесите людей в продуктовые команды. Выделите Chapter Lead-ов для линейного управления. Это болезненный процесс, обычно занимает 6–12 месяцев.