Фиче-команды
Фиче-команда, изображённая на иллюстрации ниже, является долгоживущей, кросс-функциональной и кросс-компонентной командой, которая выполняет от начала и до конца множество задач, описанных пользовательским языком — одну за другой.
Характерные черты фиче-команды перечислены ниже:
- долгоживущая — команда остаётся вместе, чтобы они могли ‘созреть’ для достижения высокой производительности; со временем они приобретают новые особенности
- кросс-функциональная и кросс-компонентная
- колоцированная
- работает над задачей целиком, описанной клиентским языком, до её завершения, над всем затрагиваемыми компонентами и во всех дисциплинах (аналитика, программирование, тестирование, …)
- состоит из специалистов широкого профиля
- как и в Скраме обычно состоит из 7 ± 2 человек
Применение современных инженерных практик — особенно непрерывной интеграции — является самым важным при переходе к фиче-командам. Непрерывная интеграция способствует общему владению кодом, которое необходимо, когда несколько команд работают над одними и теми же компонентами в одно и то же время.
Типичное заблуждение: каждый член фиче-команды должен знать всю систему целиком. Но это не так, потому что
- Команда целиком — а не каждый член в отдельности — требует всех навыков для реализации от начала и до конца функциональности, ориентированной на клиента. Они включают в себя знания и функциональные навыки, такие как тестирование, проектирование взаимодействия или программирование. Но внутри команды люди по-прежнему специализируются… желательно в нескольких областях.
- Элементы Бэклога Продукта не распределяются между командами произвольно. Текущие знания и навыки команды учитываются в принятии решения, какая команда будет работать над какими задачами.
В организации, состоящей из фиче-команд, когда специализация становится ограничением… происходит обучение.
Организация, состоящая из фиче-команд, использует преимущества в скорости от специализации, если требования покрываются навыками команд.
Требования, которые не соответствуют навыкам команд, ’форсируют’ обучение, разрушая ограничения чрезмерной специализации.
Фиче-команды сочетают в себе специализацию и гибкость.
сравнение компонентных и фиче-команд
Таблица и иллюстрация ниже показывают отличия фиче-команд и более традиционных компонентных команд.
компонентная команда | фиче-команда |
---|---|
оптимизирована для поставки максимального количества строк кода | оптимизирована для поставки максимальной ценности для клиента |
фокус на увеличении индивидуальной продуктивности, реализуя ‘простые’ функции с более низкой ценностью | фокус на наиболее ценных для продукта функциях и на продуктивности системы (пропускной способности поставки ценности) |
несёт ответственность только за свою часть общей функциональности, ориентированной на клиента | несёт ответственность за всю целиком функциональность, ориентированную на клиента |
традиционный подход организации команд — следует Закону Конвея | ‘современный’ подход организации команд — избегает Закона Конвея |
ведёт к ‘выдуманной’ работе и бесконечно растущей организации | ведёт к фокусу не клиенте, прозрачности, и небольшим организациям |
зависимости между командами ведут к дополнительному планированию | минимизирует зависимости между командами, увеличивая гибкость |
фокус на одной специализации | фокус на нескольких специализациях |
индивидуальное/командное владение кодом | общее владение кодом продукта |
чёткие индивидуальные обязанности | общая командная ответственность |
приводит к ‘каскадной’ разработке | поддерживает итеративную разработку |
использует существующую экспертизу; низкий уровень изучения новых навыков | использует гибкость; непрерывное и широкопрофильное обучение |
использует небрежные инженерные практики — результаты имеют локальный эффект | требует развитых инженерных практик — их результаты широко заметны |
вопреки убеждению часто ведёт к низкому качеству кода в компоненте | мотивирует писать легко поддерживаемый и тестируемый код |
внедрить, по-видимому, легко | внедрить, по-видимому, тяжело |
Таблица ниже подводит итоги в сравнении фиче-команд и традиционных проектных или специализированных групп.
фиче-команда | специализированная группа или проект |
---|---|
стабильная команда, члены которой остаются вместе на долгие годы и реализуют совместно большое количество функциональности | временный состав людей, созданный для работы над одной задачей или проектом |
общая ответственность за всю работу | индивидуальная ответственность за ‘их’ часть работы, основанной на их специализации |
самоуправляемая команда | контролируется руководителем проекта |
приводит к простой плоской организации (без матриц!) | приводит к матричной организации с пулами ресурсов |
члены команды выделены — на 100% — в команду | члены выделены частично на несколько проектов на основе их специализации |
Большинство недостатков компонентных команд описаны в разделе “Feature Teams” книги “Scaling Lean & Agile Development”, на иллюстрации ниже можно увидеть некоторые из них.
Иногда этого не видно, но структура компонентных команд усиливает модель последовательной разработки (‘водопад’ или 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.
Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.