Фиче-команды

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

Характерные черты фиче-команды перечислены ниже:

  • долгоживущая — команда остаётся вместе, чтобы они могли ‘созреть’ для достижения высокой производительности; со временем они приобретают новые особенности
  • кросс-функциональная и кросс-компонентная
  • колоцированная
  • работает над задачей целиком, описанной клиентским языком, до её завершения, над всем затрагиваемыми компонентами и во всех дисциплинах (аналитика, программирование, тестирование, …)
  • состоит из специалистов широкого профиля
  • как и в Скраме обычно состоит из 7 ± 2 человек

Применение современных инженерных практик — особенно непрерывной интеграции — является самым важным при переходе к фиче-командам. Непрерывная интеграция способствует общему владению кодом, которое необходимо, когда несколько команд работают над одними и теми же компонентами в одно и то же время.

Типичное заблуждение: каждый член фиче-команды должен знать всю систему целиком. Но это не так, потому что

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

В организации, состоящей из фиче-команд, когда специализация становится ограничением… происходит обучение.

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

сравнение компонентных и фиче-команд

Таблица и иллюстрация ниже показывают отличия фиче-команд и более традиционных компонентных команд.

компонентная команда фиче-команда
оптимизирована для поставки максимального количества строк кода оптимизирована для поставки максимальной ценности для клиента
фокус на увеличении индивидуальной продуктивности, реализуя ‘простые’ функции с более низкой ценностью фокус на наиболее ценных для продукта функциях и на продуктивности системы (пропускной способности поставки ценности)
несёт ответственность только за свою часть общей функциональности, ориентированной на клиента несёт ответственность за всю целиком функциональность, ориентированную на клиента
традиционный подход организации команд — следует Закону Конвея ‘современный’ подход организации команд — избегает Закона Конвея
ведёт к ‘выдуманной’ работе и бесконечно растущей организации ведёт к фокусу не клиенте, прозрачности, и небольшим организациям
зависимости между командами ведут к дополнительному планированию минимизирует зависимости между командами, увеличивая гибкость
фокус на одной специализации фокус на нескольких специализациях
индивидуальное/командное владение кодом общее владение кодом продукта
чёткие индивидуальные обязанности общая командная ответственность
приводит к ‘каскадной’ разработке поддерживает итеративную разработку
использует существующую экспертизу; низкий уровень изучения новых навыков использует гибкость; непрерывное и широкопрофильное обучение
использует небрежные инженерные практики — результаты имеют локальный эффект требует развитых инженерных практик — их результаты широко заметны
вопреки убеждению часто ведёт к низкому качеству кода в компоненте мотивирует писать легко поддерживаемый и тестируемый код
внедрить, по-видимому, легко внедрить, по-видимому, тяжело

Таблица ниже подводит итоги в сравнении фиче-команд и традиционных проектных или специализированных групп.

фиче-команда специализированная группа или проект
стабильная команда, члены которой остаются вместе на долгие годы и реализуют совместно большое количество функциональности временный состав людей, созданный для работы над одной задачей или проектом
общая ответственность за всю работу индивидуальная ответственность за ‘их’ часть работы, основанной на их специализации
самоуправляемая команда контролируется руководителем проекта
приводит к простой плоской организации (без матриц!) приводит к матричной организации с пулами ресурсов
члены команды выделены — на 100% — в команду члены выделены частично на несколько проектов на основе их специализации

Большинство недостатков компонентных команд описаны в разделе “Feature Teams” книги “Scaling Lean & Agile Development”, на иллюстрации ниже можно увидеть некоторые из них.

component_teams_waterfall.png
Некоторые Недостатки Компонентных Команд.

Иногда этого не видно, но структура компонентных команд усиливает модель последовательной разработки (‘водопад’ или V-модель), с большим количеством очередей с разноразмерными пакетами работ, высоким уровнем НЗР, множественными передачами, повышением многозадачности и частичным выделением людей на проекты.

Что выбрать: Компонентные Команды или Фиче-команды?

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

Часто используемый аргумент в пользу гибридной организации — это необходимость создания инфраструктуры, создания повторно используемых компонентов или улучшения кода — работа, традиционно выполняемая в компонентных командах. Но эти задачи могут быть сделаны в организации, состоящей только из фиче-команд - без создания постоянных компонентных команд. Как? Путём добавления задач по инфраструктуре, повторно используемым компонентам или улучшению кода в Бэклог Продукта и передачи их существующим фиче-командам — так, как если бы они были бы задачами, ориентированным на клиента. Фиче-команда временно — на столько долго, на сколько Владелец Продукта захочет — выполняет такую работу и затем возвращается к работе над задачами, ориентированными на клиента.

Переход к Фиче-командам

Разные организации требует разной стратегии по переходу от компонентных к фиче-командам. Мы имеем опыт во многих стратегиях, которые работали… и проваливались в зависимости от контекста. Безопасная — но долгая — стратегия перехода состоит в запуске одной фиче-команды среди других компонентных команд. После того, как она будет чувствовать себя хорошо, можно приступать к запуску второй фиче-команды. Это продолжается постепенно со скоростью, устраивающей организацию. Это изображено на иллюстрации ниже.

Рекомендуем к Прочтению

  • Feature Team Primer
    Текущая статья изначально была опубликована в Feature Team Primer
  • Раздел Feature Teams в книге Scaling Agile & Lean Development
    Этот 60-страничный анализ компонентных и фиче-команд также доступен онлайн
  • Dynamics of Software Development Джима Маккарти.
    Изначально опубликована в 1995 году, переиздана в 2008 году. Книга Джима является настоящей классикой в области разработки программного обеспечения. Уже в 1995 году она уделяла особое внимание фиче-командам. Оставшаяся часть книги наполнена полезными советами, связанными с разработкой программного обеспечения.
  • “XP and Large Distributed Software Projects” Эвена-Андре Карлссона и Ларса-Йорана Андерссона.
    Эта ранняя статья о масштабировании гибкой разработки приводится с точки зрения Экстремального Программирования. Это проницательная и недооцененная статья, описывающая тесную взаимосвязь между фиче-командами и непрерывной интеграцией.
  • “How Do Committees Invent?” Мелвина Конвея.
    Эта 40-летняя статья столь же познавательна на сегодняшний день, как и 40 лет назад. Она доступна на сайте авторов по адресу www.melconway.com.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.