Масштабирование AgileКонцепцияСтруктура команд

Component Team (компонентная команда)

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

КРАТКО
Component Team (компонентная команда) отвечает за один технический слой: интерфейс, серверную часть, базу данных или мобильное приложение. Это противоположность продуктовой команде. Специализация выглядит выгодной, но любая пользовательская функция требует согласования нескольких команд сразу, поэтому растут зависимости, появляются очереди задач и поставка заметно замедляется.
СИНОНИМЫ:Component Teamкомпонентная командакоманда по техническому компонентуфункциональная команда

Component Team, или компонентная команда, — традиционный способ организовать разработку по техническим компонентам. До распространения Agile это было нормой во многих компаниях, встречается и сейчас.

Примеры компонентных команд

  • Команда интерфейса — только веб- и мобильные экраны.
  • Команда серверной части — только API.
  • Команда базы данных — только схема и миграции.
  • Мобильная команда — только iOS и Android.
  • Команда инфраструктуры — DevOps.

Плюсы

  • Глубокая экспертиза в своей технологии.
  • Простое управление: понятная иерархия.
  • Меньше дублирования кода.

Минусы

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

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

КОГДА ПРИМЕНЯТЬ
  • Платформенная команда, которая развивает общую инфраструктуру
  • Очень узкая предметная область
  • Поддержка устаревшего стека технологий
КОГДА НЕ СТОИТ
  • Продуктовая разработка, где важна скорость вывода на рынок
  • Любая разработка того, что видит пользователь, — лучше продуктовые команды
ПРИМЕР

Команда серверной части поддерживает API, команда интерфейса делает экраны. Чтобы выпустить функцию «фильтр по дате», владелец продукта ставит задачу в бэклог серверной команды и ждёт спринт, затем ставит задачу в бэклог команды интерфейса и ждёт ещё спринт. Итого 4 недели вместо 2 в продуктовой команде.

КАК ИСПОЛЬЗОВАТЬ В SHTAB

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

Попробовать бесплатно

Вопросы про «Component Team (компонентная команда)»

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

Применяйте термины на практике

База знаний, задачи и цели — в одном сервисе. Бесплатно — без лимита по числу людей.