Feature Team Model (Модель продуктовых команд, К. Ларман, Б. Водде)

Компания вырастает с двух до двенадцати команд разработки и делит их «по-человечески понятно»: команда интерфейса, команда серверной части, команда базы данных, команда интеграций. Каждая отвечает за свой слой, и каждая по отдельности выглядит загруженной и эффективной. Но любая новая функция для клиента — от выбора тарифа до нового отчёта — проходит через три-четыре команды, у каждой своя очередь, своё планирование и свой релиз. Клиент видит не двенадцать эффективных команд, а месяцы ожидания. Feature-команда (feature team) — организационный принцип из LeSS (Large-Scale Scrum), который меняет само правило деления: команда отвечает не за часть системы, а за законченную клиентскую функцию «от и до» и умеет работать во всех компонентах, которые для этого нужны. Ларман и Водде определяют её как долгоживущую, кросс-функциональную и кросс-компонентную команду, которая одну за другой завершает много сквозных клиентских функций. В этой статье — что именно сказано в материалах LeSS и в первоисточнике о связи структуры организации и системы (статье Мелвина Конвея 1968 года), чем feature-команда отличается от component-команды, как переходить на модель и где она ограничена, а также как использовать фрейм OrgDevTools для оценки команд.

Что такое модель feature-команд и когда она нужна

Feature-команда — это команда, которая обладает знаниями и навыками, необходимыми для завершения сквозной клиентской функции. Вот определение с сайта LeSS: долгоживущая, кросс-функциональная, кросс-компонентная команда, которая завершает много клиентских функций от начала до конца — одну за другой. «Долгоживущая» означает, что команда остаётся вместе, чтобы «притереться» и работать лучше, а новые функции получает со временем. «Кросс-функциональная и кросс-компонентная» — что она работает над целой клиентской функцией во всех компонентах и во всех дисциплинах: анализ, программирование, тестирование и другие. Если необходимых знаний не хватает, команда должна их освоить или получить.

Противоположность — component-команда, которая отвечает лишь за часть клиентской функции: за отдельный компонент, слой или технологию. В таких структурах готовая функция возникает только тогда, когда работу закончили все причастные команды, поэтому между командами появляются зависимости, согласования, ожидание и дополнительное планирование. Именно на этом сравнении построена вся аргументация LeSS в пользу feature-команд.

Модель нужна, когда организация масштабирует разработку продукта на несколько команд и замечает, что время от идеи до клиента определяется не скоростью работы команд, а очередями между ними; когда одна функция требует изменений в нескольких компонентах; когда много времени уходит на межкомандные встречи и согласование планов. Она менее применима, когда продукт очень мал и достаточно одной команды, когда в системе есть объективно узкая область, требующая редкой экспертизы, и когда организация не готова менять ни состав команд, ни архитектуру. Смежные методы и рамки: LeSS (Large-Scale Scrum), Scrum, Scrum of Scrums, Nexus, SAFe, самоуправляемые команды, командная организация Катценбаха и Смита, картирование потока создания ценности (VSM) и расчёт Lead Time.

Происхождение и исследовательская база

Модель описали Крэйг Ларман и Бас Водде в рамках LeSS — рамки масштабирования Scrum на многие команды, с сайтом less.works и книгой «Large-Scale Scrum: More with LeSS» (2016). Тема feature-команд подробно разобрана на сайте LeSS и в главе «Feature Teams» их более ранней книги «Scaling Lean & Agile Development»; о ней сказано, что это разбор объёмом около 60 страниц, доступный и онлайн. Оговорка: этот текст в работе полностью не читался; ниже используется страница LeSS о feature-командах.

Идея не возникла из пустоты. Страница LeSS прямо указывает на предшественников. Это книга Джима Маккарти «Dynamics of Software Development» (впервые издана в 1995 году, переиздана в 2008-м), которая, как отмечают авторы LeSS, ещё в 1995 году делала акцент на feature-командах. Это статья Карлссона и Андерссона «XP and Large Distributed Software Projects», описывающая тесную связь между feature-командами и непрерывной интеграцией. И это статья Мелвина Конвея, которой около сорока лет, — она размещена на сайте автора (melconway.com). Именно последняя даёт теоретический фундамент: почему деление команд по компонентам неизбежно превращается в деление самой системы по тем же границам.

Конвей опубликовал статью «How Do Committees Invent?» в журнале Datamation в апреле 1968 года; ключевое наблюдение из неё вошло в историю как «закон Конвея». Позднее его подтверждали эмпирически: по сведениям справочного обзора, исследователи MIT и Гарвардской школы бизнеса изучали «гипотезу зеркального отражения» (так они назвали закон Конвея) и нашли «убедительные свидетельства» в её пользу — продукт, созданный слабо связанной организацией, оказывался значительно более модульным, чем продукт тесно связанной. Есть и другие исследования, о которых упоминает тот же обзор: работа Нагаппана, Мерфи и Базили (Мэрилендский университет, совместно с Microsoft) и финских исследователей Сида и Хаммуды. Ниже — рерайт первоисточников. Оговорка: эти исследования пересказаны по справочному обзору, сами публикации не читались, и точные показатели в статье не приводятся.

Организации, проектирующие системы, вынуждены создавать проекты, являющиеся копиями коммуникационных структур этих организаций (М. Конвей, 1968; перевод цитаты из статьи).

Академическая теория: что известно о feature-командах и о структуре организации

Определение и пять признаков

Страница LeSS перечисляет свойства feature-команды. Первое — долгоживущая: команда сохраняет состав, чтобы «притереться», а новые функции получает со временем. Второе — работает над законченной клиентской функцией во всех компонентах и дисциплинах. Третье — располагает необходимыми знаниями и навыками для сквозной клиентской функции, а если их не хватает, обязана научиться. Кроме того, в LeSS подчёркивают, что навыки нужны команде в целом, а не каждому её участнику: необходимы и знание компонентов, и функциональные навыки — тестирование, проектирование взаимодействия, программирование, но внутри команды люди по-прежнему специализируются, желательно сразу в нескольких областях. Здесь и возникает то, что в отечественной практике часто называют «Т-образными» специалистами: глубина в одной области и широта в нескольких. Оговорка: термины «T-shaped» и «generalizing specialist» на использованной странице LeSS не приведены; в описании фрейма они относятся к пятому и четвёртому критериям чек-листа.

Как распределяются функции между командами

Feature-команды не получают функции случайно. Как сказано на странице LeSS, при решении, какая команда какую функцию берёт, учитывают текущие знания и навыки команды. Это важное уточнение: модель не требует, чтобы каждая команда одинаково хорошо знала все компоненты сразу. Она допускает использование существующей экспертизы, пока требования соответствуют навыкам команд, а когда они не соответствуют — обучение становится вынужденным, и это ломает перекос специализации. Формулировка LeSS: «когда специализация становится ограничением… происходит обучение». Компонентная структура, напротив, закрепляет специализацию навсегда: команда по определению не выходит за пределы своего компонента.

Сравнение feature- и component-команд по LeSS

На странице LeSS приведена сравнительная таблица. Component-команда оптимизирована на максимум строк кода, feature-команда — на максимум ценности для клиента. Первая отвечает лишь за часть клиентской функции, вторая — за всю функцию. Компонентная организация следует закону Конвея и считается традиционной, а feature-организация — «современной» и закона Конвея избегает. Зависимости между component-командами требуют дополнительного планирования, а feature-команды минимизируют зависимости и повышают гибкость. Компонентная структура использует имеющуюся экспертизу и мало учит новому, feature-структура — гибкость и постоянное широкое обучение. Кроме того, по замечанию авторов, при компонентной структуре можно работать с небрежными инженерными практиками, потому что последствия локальны; при feature-структуре нужны сильные практики, поскольку последствия видны широко. И ещё: в компонентных структурах участники часто заняты в нескольких местах частично, а в feature-командах — целиком в одной. Оговорка: эти формулировки — позиция авторов LeSS, а не результат независимого сравнительного исследования.

Компонентные команды закрепляют последовательную разработку

Отдельное наблюдение с той же страницы: структура из component-команд усиливает последовательную разработку — «водопад» или V-модель — с множеством очередей и пакетов работы разного размера, высоким объёмом незавершённой работы, многочисленными передачами и повышенной многозадачностью и частичной занятостью. Это сближает модель с идеями потока: картирование потока создания ценности и Kanban показывают именно очереди и ожидание как основные потери, а не медленную работу исполнителей. Модель feature-команд атакует потери на уровне организации: убирает передачи, вместо того чтобы ускорять каждую из них.

Закон Конвея: почему структура команд становится структурой системы

Первоисточник — статья Конвея 1968 года. Её главный аргумент: пока проектная организация не выбрана, часть решений о системе уже принята неявно. По Конвею, сам акт организации команды означает, что некоторые проектные решения уже приняты, явно или неявно: для любой организации существует класс проектных альтернатив, которые она не может эффективно реализовать, потому что нужных каналов коммуникации нет. Поэтому «не существует проектной группы, которая была бы одновременно организована и беспристрастна». Кроме того, каждый раз, когда работу делегируют и сужают чью-то область рассмотрения, сужается и класс проектных альтернатив, которые можно эффективно реализовать.

Затем Конвей показывает соответствие между структурой системы и структурой организации. В обычном случае, когда каждой подсистемой занимается отдельная группа, структуры (линейные графы) группы и системы идентичны; если одна группа проектирует несколько подсистем, структура организации представляет собой «свёрнутую» версию структуры системы. Это структурно сохраняющее соответствие Конвей называет гомоморфизмом. Отсюда вывод: в той мере, в какой организация не полностью гибка в своей коммуникационной структуре, она «штампует свой образ» в каждом проекте, который создаёт, и чем больше организация, тем меньше гибкости и тем сильнее эффект. Важная оговорка самого Конвея, сохранённая справочным обзором: закон строго говоря описывает соответствие, а не причинность; разные комментаторы по-разному определяют направление причинности.

Практический вывод для feature-команд. Если команды делятся по компонентам, границы между компонентами будут повторять границы между командами, а любое изменение, пересекающее границы, потребует межкомандной коммуникации — то есть передач, согласования и очередей. Формулировка LeSS в таблице («следует закону Конвея» для компонентных команд и «избегает закона Конвея» для feature-команд) означает не то, что закон перестаёт действовать, а то, что организация перестаёт закреплять в архитектуре границы, которые мешают клиентским функциям. Оговорка: это интерпретация, а не цитата первоисточника; сам Конвей в разбираемой статье не предлагал feature-команды.

Непрерывная интеграция и общее владение кодом

LeSS называет современные инженерные практики, прежде всего непрерывную интеграцию, необходимым условием перехода. Логика простая: когда несколько команд одновременно работают в одних и тех же компонентах, необходимо общее владение кодом, а его облегчает непрерывная интеграция. Без неё feature-команды начинают мешать друг другу: конфликтующие изменения, длинные ветки, ручные согласования. Это отражено и в перечне предшественников: статья Карлссона и Андерссона, как отмечено на странице LeSS, описывает тесную связь между feature-командами и непрерывной интеграцией.

Инфраструктура, общие компоненты и «уборка кода» без component-команд

Частый довод в пользу гибридной организации: кому-то нужно строить инфраструктуру, писать переиспользуемые компоненты и наводить порядок в коде — традиционные задачи component-команд. LeSS возражает: эту работу можно выполнять и в чистой feature-организации без постоянных component-команд — достаточно добавить её в бэклог продукта и отдать существующей feature-команде так, как если бы это была клиентская функция. Команда временно, столько, сколько сочтёт нужным владелец продукта, занимается такой работой и возвращается к клиентским функциям. Авторы предупреждают, что гибридные модели наследуют недостатки обоих миров и могут быть болезненными, но признают: многие организации приходят именно к гибриду, особенно на переходе.

Как переходить

По странице LeSS, разным организациям нужны разные стратегии перехода; авторы знают много стратегий, которые в одном контексте работали, а в другом провалились. Безопасная, но медленная стратегия — создать одну feature-команду внутри существующей компонентной организации; когда она работает хорошо, сформировать вторую, и так постепенно, с той скоростью, которая комфортна организации. Это удобно проверять метрикой из фрейма — долей функций, завершённых без зависимости от других команд (подробнее ниже).

Учебный расчёт независимости команды

Условная команда за квартал завершила 40 клиентских функций. Для 14 из них ей не потребовалось ничего от других команд: ни изменений в чужих компонентах, ни согласования, ни ожидания чужого релиза. Независимость: 14 ÷ 40 = 35 %. По порогам фрейма это ниже 50 %: сигнал, что команда фактически ближе к component-команде. Через два квартала после архитектурных изменений и обучения команда завершила 45 функций, из них 36 самостоятельно: 36 ÷ 45 = 80 %. Это уже граница, с которой фрейм считает независимость достаточной. Числа условные и иллюстрируют расчёт; пороги 50 % и 80 % заданы во фрейме OrgDevTools и не взяты из первоисточников LeSS.

Обратите внимание, что метрика чувствительна к определению «зависимости». Если считать зависимостью любое обращение к чужому компоненту, пусть и согласованное за пять минут, команда покажет низкий результат даже при удачном устройстве; если считать зависимостью только блокировку релиза, результат завысится. Заранее договоритесь о формулировке: например, «зависимость — ситуация, когда функцию нельзя считать завершённой без изменений или решения другой команды» — и применяйте её одинаково ко всем командам.

Ключевые идеи и принципы модели feature-команд

1. Принцип: команда отвечает за клиентскую функцию, а не за часть системы

   Единица работы команды — законченная функция, которую клиент может использовать. Это меняет вопрос планирования: не «что должен сделать наш компонент», а «что должно быть готово, чтобы функция заработала», и команда сама идёт по всем компонентам, которые для этого нужны.

2. Принцип: долгоживущая команда, а не проектная группа

   Команда сохраняет состав, чтобы «притереться»; задачи приходят к команде, а не команда собирается под задачу. Регулярные перетасовки людей под проекты разрушают накопленную совместную работу и возвращают зависимости.

3. Принцип: навыки нужны команде, а не каждому участнику

   Не требуется, чтобы каждый человек умел всё. Команда в целом должна покрывать нужные компоненты и функциональные навыки, а участники специализируются, желательно в нескольких областях. Так сохраняется глубина и уходит узкое место «единственного эксперта».

4. Принцип: специализацию заменяют обучением там, где она становится ограничением

   Если требования не совпадают с навыками команды, обучение вынужденное; в этом и состоит механизм ухода от чрезмерной специализации. Распределяя функции по командам, учитывайте текущие навыки, но не превращайте их в постоянное ограничение.

5. Принцип: технические практики — условие, а не украшение

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

6. Принцип: не оставлять component-команд «на всякий случай»

   Инфраструктуру, общие компоненты и рефакторинг предлагается вести через общий бэклог, как обычные функции; гибриды допустимы на переходе, но обходятся дорого и должны быть осознанным решением, а не результатом нерешительности.

Как перейти к feature-командам: пошаговая инструкция

Практическая последовательность, основанная на описании LeSS и здравом смысле; конкретный порядок и сроки всегда зависят от организации. Сначала измерьте исходное состояние: возьмите список функций, завершённых за последние два-три месяца, и для каждой отметьте, потребовались ли изменения в чужих компонентах или решения других команд. Получится базовая доля независимости — точка отсчёта. Затем нарисуйте карту зависимостей: какие команды и компоненты чаще всего блокируют друг друга и какие функции проходят через наибольшее число команд. Оцените архитектуру: где границы между компонентами жёсткие и требуют отдельной команды, а где они лишь повторяют историческую организацию, и насколько эти границы мешают сквозной работе.

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

Пример из практики: как в LeSS предлагают выйти из гибрида

Документированная рекомендация авторов LeSS: организации, боящиеся терять инфраструктурную экспертизу, не создают постоянную команду инфраструктуры, а кладут инфраструктурную работу в бэклог продукта и отдают её любой feature-команде на срок, который определяет владелец продукта; после этого команда возвращается к клиентским функциям. Это практический ответ на самое частое возражение против модели. Оговорка: это рекомендация авторов, а не результат оценки конкретной компании; данных о том, насколько она работает в разных организациях, в использованных источниках нет.

Ограничения, слепые зоны и критика модели

Типовые ошибки при внедрении feature-команд

1. Ошибка 1: переименовали component-команды в feature-команды.

   Состав, навыки и архитектура остались прежними; названия поменялись, а функции по-прежнему проходят через несколько команд.

   Как избежать

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

2. Ошибка 2: меняют оргструктуру, не трогая архитектуру и практики.

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

   Как избежать

   параллельно развивать инженерные практики и уменьшать связанность компонентов.

3. Ошибка 3: собирают команду под проект и расформировывают.

   Команда не успевает «притереться», знания уходят вместе с людьми, зависимости возвращаются.

   Как избежать

   сохранять состав команды и подавать в неё новые функции.

4. Ошибка 4: требуют, чтобы каждый умел всё.

   Универсальность как обязанность каждого вызывает сопротивление и снижает качество; глубокие специалисты чувствуют обесценивание.

   Как избежать

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

5. Ошибка 5: оставляют постоянные component-команды «на всякий случай».

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

   Как избежать

   проверять, нельзя ли вести инфраструктуру и общие компоненты через общий бэклог; сохранять component-команду только как осознанное решение.

6. Ошибка 6: ждут быстрого результата.

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

   Как избежать

   закладывать переходный период, вводить модель постепенно и отслеживать промежуточные метрики.

7. Ошибка 7: измеряют независимость по-разному в разных командах.

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

   Как избежать

   зафиксировать единое определение зависимости и применять его одинаково.

Метрики: как оценивать переход

Универсальных нормативов нет; фиксируйте по своим данным:

• Доля независимых функций: функции, завершённые без зависимости от других команд, делённые на все завершённые функции за период (во фрейме пороги 50 % и 80 %).

• Соответствие критериям: сколько из пяти критериев чек-листа выполнено для каждой команды.

• Время поставки: от принятия функции в работу до готовности клиенту; удобно считать по методике расчёта Lead Time.

• Число команд, вовлечённых в функцию: среднее по функциям за период; должно снижаться.

• Доля времени в ожидании: сколько времени функция ждёт другую команду или согласование.

• Текучесть состава команд: сколько людей перешло между командами за квартал.

• Дефекты после интеграции: показатель зрелости практик непрерывной интеграции.

Feature-команда — не название, а свойство: функции доходят до клиента без передач между командами.

План внедрения по месяцам

1. Месяцы 1–2: измерение

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

2. Месяцы 3–4: оценка архитектуры и практик

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

3. Месяцы 5–6: пилот

   Сформируйте одну feature-команду из людей с комплементарными навыками, отдайте ей функции, затрагивающие несколько компонентов, и следите за метриками.

4. Месяцы 7–12: расширение

   Формируйте следующие команды в темпе, комфортном для организации; переведите инфраструктурную работу в общий бэклог; обновляйте оценку критериев по каждой команде.

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

Как реализовать план с помощью фрейма «Модель продуктовых команд» в OrgDevTools

Фрейм — специальный экран с двумя вкладками: «Критерии» и «Итоги». На вкладке «Критерии» два блока. Первый — чек-лист из пяти критериев feature-команды: кросс-функциональность (все фазы разработки), кросс-компонентность (все затронутые части системы), долгоживучесть, состав из обобщённых специалистов и работа над фичей «от клиентского запроса до полного завершения». Второй — калькулятор: два числовых поля, «Всего фич завершено» и «Без зависимости от других команд», и плитка «Независимость команды» с процентом, окрашенным по порогам: от 80 % — зелёный, от 50 % — оранжевый, ниже — красный. Данные хранятся в самом документе фрейма; фрейм рассчитан на одну команду за раз.

• Месяцы 1–2 — базовая линия: введите число завершённых функций и число тех, что обошлись без других команд; зафиксируйте процент.

• Месяцы 3–6 — оценка команды: отметьте выполненные критерии для команды-пилота и посмотрите, каких не хватает.

• Месяцы 7–12 — динамика: обновляйте оба блока и сравнивайте с базовой линией.

Вкладка «Итоги» показывает вердикт и кнопку создания задачи «Устранить недостающий критерий feature-команды». Вердикт строится по ступеням. Если ни один критерий не отмечен и метрика не заполнена — предложение отметить критерии и заполнить метрику. Если выполнены не все критерии, а независимость не измерена или ниже 50 % — предупреждение, что команда скорее component-, чем feature-команда. Если выполнены все пять критериев и независимость не ниже 80 % — подтверждение полноценной feature-команды. Во всех остальных случаях — нейтральная сводка «выполнено N из 5 критериев, независимость такая-то».

Чего фрейм не делает. Он не знает ни команд, ни функций: это один чек-лист и одна пара чисел, а не реестр команд или функций; сравнить несколько команд можно только созданием отдельных документов. Он не определяет, что считать зависимостью, и не проверяет введённые числа: значение «без зависимости» может превышать «всего», тогда процент выйдет больше 100 %. Критерии отмечаются вручную — фрейм не проверяет, действительно ли команда кросс-компонентна, и не оценивает архитектуру, навыки и практики непрерывной интеграции. Вердикт «полноценная feature-команда» означает только то, что введённые числа и отметки удовлетворяют порогам 80 % и 5 из 5; сами пороги заданы во фрейме и не приведены в первоисточниках LeSS. Если выполнены все критерии, но независимость не измерена, вердикт будет нейтральным. Кнопка создания задачи доступна независимо от вердикта: её текст всегда описывает недостающий критерий, даже если все критерии отмечены.

Книги и материалы по теме feature-команд

К. Ларман, Б. Водде — «Large-Scale Scrum: More with LeSS» (2016). Полное изложение LeSS, включая модель feature-команд.

К. Ларман, Б. Водде — «Scaling Lean & Agile Development». Глава «Feature Teams» разбирает недостатки component-команд подробно (на сайте LeSS указано, что этот 60-страничный анализ доступен и онлайн).

Страница «Feature Teams» на less.works. Определение, сравнительная таблица feature- и component-команд, переход и гибриды.

М. Конвей — «How Do Committees Invent?» (Datamation, апрель 1968). Первоисточник закона Конвея; доступен на сайте автора melconway.com.

Дж. Маккарти — «Dynamics of Software Development» (1995, переиздание 2008). Одна из ранних книг с акцентом на feature-команды (по указанию авторов LeSS).