Feature Teams

16 октября, 2017 Технические статьи

Что такое Feature Team

Представленная на Рисунке 1 Feature Team — это достаточно долго существующая вместе кросс-функциональная кросс-компонентная команда, которая самостоятельно, в одиночку, реализует множество пользовательских фич.

Рисунок 1 Feature Team

Пояснения к Рисунку 1

Ниже перечислены характеристики Feature Team команды:

достаточно долго существующая вместе команда, которая не расформировывается, с целью достижения высокого перфоманса (высокой производительности); спустя какое-то время она берет на себя новые функции, принимая вызовы и наращивая собственные компетенции
кросс-функциональная кросс-компонентная команда
в идеале команда территориально размещается в одном месте — офисе или кабинете
работа, которую выполняет команда для реализации фич, сквозная для всех компонентов и затрагивает разные сферы компетенций (аналитика, программирование, тестирование и далее)
команда, состоящая из специалистов широкого спектра — имеющих много компетенций и знающих продукт не только в какой-то одной достаточно узкой области, то есть не узко специализированные
согласно scrum-у состав такой команды не превышает 7 человек, идеальный состав по численности обозначен как 7 ± 2 человека (другое название two pizza team).

Применение современных инженерных практик и особенно CI (continuous integration) — это достаточно важный, существенный и неотъемлемый момент в адаптации, “сбивании” Feature Team.

Ведь именно применение CI дает возможность совместного использования кода, что крайне необходимо в случае когда множество команд работают одновременно с одними и теми же компонентами.

Существует всеобщее заблуждение. Оно связано с представлением о том, что каждый член такой команды должен обладать знаниями обо всей системе. В реальности это не так потому что:

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

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

Важный момент

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

Feature Team показывает высокий перфоманс в случае, если требования по работе с фичей соответствуют знаниям и навыкам команды.

Однако когда эти требования перестают соответствовать знаниям и навыкам команды, обучение усиливается и ограничения по специализации таким образом разрушаются.

Компонентная команда vs. Feature Team

В таблице ниже рассмотрим основные отличия и особенности каждого из форматов — компонентной команды и Feature Team.

Рисунок 2. Взаимодействие с владельцем продукта и внутри командное взаимодействие в компонентных командах и в Feature teams

Пояснения к Рисунку 2

В таблице выше мы рассмотрели основные отличия и особенности компонентной команды и Feature Team.

В таблице ниже рассмотрим отличия между традиционными проектными командами (фича группами) и Feature Team командами.

Еще больше минусов по работе в формате компонентной команды вы можете найти в разделе Scaling Lean & Agile Development. Ниже на Рисунке 3 мы приводим лишь некоторые из них.

Рисунок 3. Недостатки работы в формате компонентной команды

Пояснения к Рисунку 3

Хочется отметить еще один момент в компонентном подходе. Компонентная команда поддерживает подход последовательной разработки при водопадной модели, с меняющимися приоритетами и объемом работ, ориентацией на WIP (work in process), происходит множество переключений контекстов, происходит рост многозадачности и некоторое распыление, “размазанность”, расфокусировка.

Компонентная команда или Feature Team, что же выбрать?

Feature team в чистом виде — это идеальное и перспективное решение с точки зрения стоимости и гибкости.

Однако стоимость и гибкость не является единственным определяющим критерием при организации работ на проекте. Поэтому многие организации скорее используют гибридную модель — особенно во время перехода с компонентной модели к Feature Team.

Обратите внимание на то, что гибридные модели имеют недостатки обеих сторон и могут оказаться весьма болезненными.

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

Однако все эти активности спокойно могут делаться и в Feature team формате — без создания временных компонентных команд.
Как? Путем добавления инфраструктуры, переиспользуемых компонентов или проведения работ по очистке бэклога продукта — и передача всего этого существующей Feature team, как если бы это было клиент ориентированной фичей.

В этом случае Feature team — явление временное, она существует так долго, как это потребуется Product Owner-у. То есть Feature team какое-то время работает так, а в дальнейшем возвращается к созданию клиент-ориентированных фич.

Переход на Feature Team формат

Различные организации требуют различных транзитных стратегий по переходу с компонентной модели на Feature Team формат.

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