Карта Внедрения Фиче-Команд

Карта внедрения фиче-команд является хорошим инструментом при переходе к фиче-командам.

Диаграмма Масштаба и Специализации

Что такое компонент? Что такое фича? Что такое функциональная специализация? До сих пор мы рассматривали их как бинарные понятия, но ответ существует скорее в виде континуума. Допустим, одна группа владеет одним классом в коде, тогда как другая группа владеет целой подсистемой. Несмотря на масштаб, обе они являются компонентными командами. Существует похожее измерение, относящееся к функциональной специализации, так некоторые продуктовые группы имеют пять уровней тестирования, для которых фраза “включение тестирования в команду” имеет очень неясное и сомнительное значение! Изображение этих измерений на графике даёт некоторое понимание во внедрении фиче-команд и о характере организационных изменений, которые вам следует ожидать.

График показывает четыре области:

• Компонентные команды — Любая команда, которая (1) фокусируется на части продукта, а не фичах, ориентированных на клиента, или (2) фокусируется на завершении задачи, а не поставке инкремента продукта, является компонентной командой. Заметьте!… Чем меньше масштаб владения и строже специализация, тем крупнее проблемы компонентных команд.
• Фиче-команды — Любая команда, которая имеет фокус на всём продукте целиком и вовлечена в процесс начиная от прояснения фич, ориентированных на клиента, до их тестирования, является фиче-командой. Фиче-команды также существуют в неком измерении и могут иметь разный масштаб. Они могут быть ограничены в реализации предопределённой функциональности или вовлечены в выявление и решение реальных проблем клиентов.
• Функциональная узкоспециализированная команда — Любая команда, которая выполняет ограниченную задачу в рамках общего масштаба работ, вероятно, является узкоспециализированной. Это ведёт к большому объему потерь, обусловленных передачами. Такого следует избегать.
• Расширенные компонентные команды — Любая команда, которая ещё владеет ограниченным набором компонент, но уже несёт ответственность за проверку своей части работы в большем продукте, является расширенной компонентной командой. В такой команде есть внутренний конфликт, так как она отвечает и за “компонент(ы)” и за “весь продукт целиком”. Этот конфликт ведёт либо (1) к дублированию работы, такому как написанию одних и тех же тестов несколькими командами, или (2) дополнительным усилиям на координацию, такую как тестирование “с фокусом на продукте”. Такой же конфликт возникает и при прояснении требований. Эти команды, возможно, являются улучшением по сравнению с обычными компонентными командами, но далеко не в полной мере обеспечивают преимущества функциональных команд.

Карта внедрения фиче-команд

“Идеальная фиче-команда” работает на уровне всей системы и участвует в создании продукта вместе с настоящими пользователями. Это очень хорошая труднодостижимая цель для совершенствования.

Принимая во внимание эту цель, мы можем использовать предыдущую диаграмму в качестве карты внедрения фиче-команд. Вот пример:

С этой карты внедрения фиче-команд началось внедрение LeSS Huge (в этом абзаце речь идёт об одной из телекоммуникационных компаний [прим. переводчика]). Когда они начали внедрение, у них были обычные компонентные команды. Они выбрали стратегию внедрения в постепенном увеличении масштаба функционального владения команд и переходе их в расширенные компонентные команды. Их целью на несколько следующих лет было движение к полноценным продуктовым фиче-командам. Однако у них есть несколько общих с другой продуктовой группой компонент, что затрудняет их полное включение, так как требовалось бы значительно большее количество организационных изменений. Поэтому они исключили эти компоненты из своей текущей цели.

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