Component Team, или компонентная команда, — традиционный способ организовать разработку по техническим компонентам. До распространения Agile это было нормой во многих компаниях, встречается и сейчас.
Примеры компонентных команд
- Команда интерфейса — только веб- и мобильные экраны.
- Команда серверной части — только API.
- Команда базы данных — только схема и миграции.
- Мобильная команда — только iOS и Android.
- Команда инфраструктуры — DevOps.
Плюсы
- Глубокая экспертиза в своей технологии.
- Простое управление: понятная иерархия.
- Меньше дублирования кода.
Минусы
- Каждая функция требует согласования многих команд. Простая пользовательская история «добавить кнопку» превращается в задачу для интерфейса, серверной части и базы данных — минимум два спринта вместо одного.
- Медленный вывод продукта на рынок.
- «Переброс через стену»: команда не видит итоговой ценности для пользователя.
- Очереди задач: одна команда блокирует остальные.
В Agile-литературе компонентная команда считается антипаттерном продуктовой разработки. SAFe и LeSS прямо рекомендуют продуктовые команды. Компонентные команды оправданы только для инфраструктуры, общих платформ и узкоспециализированных областей.
- Платформенная команда, которая развивает общую инфраструктуру
- Очень узкая предметная область
- Поддержка устаревшего стека технологий
- Продуктовая разработка, где важна скорость вывода на рынок
- Любая разработка того, что видит пользователь, — лучше продуктовые команды
Команда серверной части поддерживает API, команда интерфейса делает экраны. Чтобы выпустить функцию «фильтр по дате», владелец продукта ставит задачу в бэклог серверной команды и ждёт спринт, затем ставит задачу в бэклог команды интерфейса и ждёт ещё спринт. Итого 4 недели вместо 2 в продуктовой команде.
Если команды устроены по компонентам и функции едут месяцами, это сигнал к перестройке. В Shtab держите портфель проектов и диаграмму Ганта: на них видно, сколько задач одной команды ждёт другую. Когда таких связок больше половины, пора собирать продуктовые команды.