Перевод оригинальной статьи “Feature Team Adoption Map Explained” Сезарио Рамоса, которая появилась в нашем англоязычном блоге в сентябре 2018 года.
Когда заходит речь про внедрение LeSS, инструмент Feature Team Adoption Map (FTAM, «карта внедрения фиче-команд») часто используется как один из самых мощных инструментов. Это ценный инструмент, который можно использовать для различных целей.
Что это такое?
Мне не удалось найти официальное определение в литературе по LeSS, но, на мой взгляд, следующее определение хорошо отражает суть: «Feature Team Adoption Map — это визуальный график, отражающий способность команды поставить готовый продукт. Эта способность выражается как потенциальный объем работы для команды и степень кросс-функциональности команды».
Критерии Готовности (DoD) показывают возможности команды с точки зрения активностей, необходимых для поставки потенциально готового к релизу продукта, а это то же самое, что и степень кросс-функциональности команды. FTAM дополняет их знанием предметной сферы продукта, а это то же самое, что и степень кросс-компонентных возможностей команды. Другими словами, FTAM — это расширение DoD, добавляющее к этой концепции второе измерение: продукт.
Изображение FTAM, представленное ниже, взято из книги по LeSS.
Мне не удалось найти официальное определение в литературе по LeSS, но, на мой взгляд, следующее определение хорошо отражает суть: «Feature Team Adoption Map — это визуальный график, отражающий способность команды поставить готовый продукт. Эта способность выражается как потенциальный объем работы для команды и степень кросс-функциональности команды».
Критерии Готовности (DoD) показывают возможности команды с точки зрения активностей, необходимых для поставки потенциально готового к релизу продукта, а это то же самое, что и степень кросс-функциональности команды. FTAM дополняет их знанием предметной сферы продукта, а это то же самое, что и степень кросс-компонентных возможностей команды. Другими словами, FTAM — это расширение DoD, добавляющее к этой концепции второе измерение: продукт.
Изображение FTAM, представленное ниже, взято из книги по LeSS.
Feature Team Adoption Map в LeSS и LeSS Huge
Хотя инструмент FTAM подробно описан в литературе по LeSS, он не используется при внедрении LeSS и очень редко используется при внедрении LeSS Huge. Сейчас поясню.
В книге по LeSS (1) использование Feature Team Adoption Map описано в двух разделах:
FTAM описывается не в правилах LeSS, а в руководствах. Руководства в книге по LeSS определяются следующим образом: «Небольшой набор руководств для эффективного применения правил и проведения экспериментов. Руководства достойны внимания, так как основаны на многолетнем опыте использования LeSS. Руководства содержат в себе советы и подсказки. Обычно они полезны и представляют собой область для непрерывного совершенствования, см., например, Три принципа внедрения».
Это подразумевает, что использование FTAM может принести пользу, но не является обязательным при внедрении LeSS.
Легковесный фреймворк LeSS
Как сказано в руководствах, FTAM можно применять при внедрении фиче-команд. Внедрение фиче-команд — обычная практика при внедрении LeSS, так как Правила LeSS гласят, что «большинство команд — это ориентированные на клиентов фиче-команды». В таком случае создание FTAM:
На практике обычно FTAM не применяют при внедрении легковесного фреймворка LeSS до 8 команд (в противовес фреймворку LeSS Huge), потому что внедрения LeSS обычно относительно небольшие по размеру. Разнообразие продуктов относительно невелико, и все понимают готовность продукта как в части кросс-функциональности, так и в части предметной сферы продукта.
LeSS Huge
При внедрении фреймворка LeSS Huge FTAM можно использовать следующим образом:
Когда можно использовать Feature Team Adoption Map?
Инструмент создает огромную ценность в следующих ситуациях:
Внедрение фиче-команд
Ваша организация хочет перейти от компонентных или функциональных команд к фиче-командам. В крупных организациях количество несовпадений между возможностями команд и программными компонентами может быть просто огромным. Карты помогут наглядно изобразить, как можно сгруппировать компоненты в фичи. Таким образом станет ясно, какое обучение необходимо командам и как подобный переход отразится на организации.
Подготовка к внедрению LeSS Huge
При формулировании первоначальной области или нескольких областей требований анализ по FTAM будет полезным упражнением и позволит наилучшим образом подготовиться к внедрению. Данный инструмент поможет нам извлечь максимум пользы из отображенных потребностей, необходимых для перехода к LeSS. Без структурированного подхода к анализу подготовительной стадии мы точно упустим какие-то очевидные моменты, что затруднит переход.
Движение к совершенству
Если ваша организация работает с фиче-командами, ваши текущие DoD наверняка несовершенны, как и (почти) все в этой жизни. Всегда есть новые активности, которые можно добавить к способностям фиче-команды поставлять практически готовый продукт. Этот инструмент можно использовать в качестве маяка, чтобы направлять совершенствование команды. В компании, с которой я работал, мы определили «создание руководства пользователя» и «создание видеоролика с инструкциями» как будущие активности кросс-функциональной команды.
Создание Feature Team Adoption Map
FTAM можно создавать, когда мы хотим перейти к фиче-командам или отследить динамику совершенствования команды. На вертикальной оси FTAM мы отображаем продукт, а на горизонтальной DoD. В книге по LeSS в главе «Начало работы» описаны шаг 1 (определить продукт) и шаг 2 (определить Критерии Готовности). Объединяя результаты этих двух шагов в Feature Team Adoption Map, мы можем увидеть широкий контекст.
Вертикальная ось: Продукт
При создании FTAM мы начинаем с оси продукта, потому что на горизонтальной оси описываются действия, необходимые для статуса «готово», а это требует понимания всего продукта. И Люй (Yi lv) объясняет в своем блоге (2): «Определение фичи зависит от определения продукта. Продукт формирует границы фичи, и фича является законченной в рамках продукта». Часто бывает сложно прийти к согласию в части определения продукта. Во многих случаях определение продукта привязано к компонентам, определяемым как продукт, что приводит к фейковым FTAM и запутанным настройкам.
В книге по LeSS (1) рекомендуется задавать вопросы для установления границ и расширения параметров, чтобы четко определить элементы продукта. Вопросы для расширения являются вариантами вопроса, «Что выходит за рамки нашего текущего продукта и может удовлетворить потребности клиентов?» Ответы на этот вопрос будут соответствовать стратегии продукта и расширят текущий объем работ по созданию продукта. Распространенное заблуждение заключается в том, что тут подразумевается продукт LeSS, хотя люди думают, что это продукт клиента. Продукт LeSS — это продукт, как он воспринимается разработчиками программного обеспечения. Возьмем для примера страхование. Документ, который хранится у вас дома и подтверждает, что вы застрахованы, — это материализация страхового продукта. Программное обеспечение, необходимое для предоставления страховой услуги, — это продукт LeSS, который включает в себя приложение, веб-сайт, администрирование страховой программы, ПО для расчетов и т. д.
Ограничивающие вопросы помогают лучше понять фичи нашего продукта. Фичи нужно знать для того, чтобы определить, какие знания необходимы каждой будущей фиче-команде. Поэтому мы должны задать себе вопрос: «В чем заключается фича, которую клиент хочет видеть в нашем продукте, и из каких компонентов состоит эта фича?» Для ответа нам нужен Бэклог Продукта. Анализируя фичи в Бэклоге Продукта, мы можем отследить, из каких компонентов нашего программного ландшафта состоит эта фича, и сгруппировать их так, чтобы в случае изменения фичи изменять их совместно. Это отобразит логическую группировку компонентов в фичи и, таким образом, покажет будущий состав команды. Задавая ограничивающие вопросы, мы также узнаем, какие компоненты не войдут в фичу из-за организационных ограничений или как не имеющие к ней отношения.
Горизонтальная ось: Активность
Для построения горизонтальной оси мы перечисляем все активности, которые должна выполнить команда, чтобы выпустить потенциально готовый к релизу продукт, то есть описываем DoD. При перечислении активностей особое внимание нужно уделить тестированию. Тестирование как активность является слишком широким понятием. Его нужно уточнить, перечислив различные типы и уровни тестирования (модульное, интеграционное, на проникновение, производительность, регрессионное и т. д.). Расположите активности от меньшего объема работ к большему в том порядке, в каком команды обычно выполняют свою работу. Перечислите все активности, необходимые для того, чтобы передать клиенту готовый продукт. Если ваши команды еще не достигли совершенства, это будет охватывать несколько команд и, возможно, несколько подразделений.
Пример
Изображение FTAM, приведенное в книге по LeSS, помогает понять, что такое FTAM, но в нем недостаточно конкретики, чтобы понять, как применять этот инструмент.
Пример ниже — это FTAM вымышленной компании, которая разрабатывает CMS (систему управления контентом). Компания разработала стратегию расширения своего продукта, чтобы созданный продукт отвечал финансовым потребностям клиента. Существующие компонентные команды могут изменить какой-либо один компонент, например, фронтенд портала (FE портала). Другие компонентные команды работают над бэкендом портала (BE портала).
Хотя инструмент FTAM подробно описан в литературе по LeSS, он не используется при внедрении LeSS и очень редко используется при внедрении LeSS Huge. Сейчас поясню.
В книге по LeSS (1) использование Feature Team Adoption Map описано в двух разделах:
- «Руководство: Feature Team Adoption Map» (стр. 90)
- «Руководство: переход к фиче-командам» (стр. 106)
FTAM описывается не в правилах LeSS, а в руководствах. Руководства в книге по LeSS определяются следующим образом: «Небольшой набор руководств для эффективного применения правил и проведения экспериментов. Руководства достойны внимания, так как основаны на многолетнем опыте использования LeSS. Руководства содержат в себе советы и подсказки. Обычно они полезны и представляют собой область для непрерывного совершенствования, см., например, Три принципа внедрения».
Это подразумевает, что использование FTAM может принести пользу, но не является обязательным при внедрении LeSS.
Легковесный фреймворк LeSS
Как сказано в руководствах, FTAM можно применять при внедрении фиче-команд. Внедрение фиче-команд — обычная практика при внедрении LeSS, так как Правила LeSS гласят, что «большинство команд — это ориентированные на клиентов фиче-команды». В таком случае создание FTAM:
- помогает определить объем работ фиче-команд;
- помогает определить масштабы внедрения LeSS;
- ставит цели для дальнейшего совершенствования.
На практике обычно FTAM не применяют при внедрении легковесного фреймворка LeSS до 8 команд (в противовес фреймворку LeSS Huge), потому что внедрения LeSS обычно относительно небольшие по размеру. Разнообразие продуктов относительно невелико, и все понимают готовность продукта как в части кросс-функциональности, так и в части предметной сферы продукта.
LeSS Huge
При внедрении фреймворка LeSS Huge FTAM можно использовать следующим образом:
- чтобы определить контекст внедрения и прояснить текущую степень специализации команды;
- чтобы поддержать стратегию «постепенно нарастающего объема работ» для инкрементального внедрения LeSS Huge, когда с помощью FTAM отмечают цели по дальнейшему увеличению объема работ. Однако принципы внедрения LeSS предполагают, что предпочтение отдается узкому и глубокому подходу, а подход «постепенно нарастающего объема работ» таковым не является.
Когда можно использовать Feature Team Adoption Map?
Инструмент создает огромную ценность в следующих ситуациях:
Внедрение фиче-команд
Ваша организация хочет перейти от компонентных или функциональных команд к фиче-командам. В крупных организациях количество несовпадений между возможностями команд и программными компонентами может быть просто огромным. Карты помогут наглядно изобразить, как можно сгруппировать компоненты в фичи. Таким образом станет ясно, какое обучение необходимо командам и как подобный переход отразится на организации.
Подготовка к внедрению LeSS Huge
При формулировании первоначальной области или нескольких областей требований анализ по FTAM будет полезным упражнением и позволит наилучшим образом подготовиться к внедрению. Данный инструмент поможет нам извлечь максимум пользы из отображенных потребностей, необходимых для перехода к LeSS. Без структурированного подхода к анализу подготовительной стадии мы точно упустим какие-то очевидные моменты, что затруднит переход.
Движение к совершенству
Если ваша организация работает с фиче-командами, ваши текущие DoD наверняка несовершенны, как и (почти) все в этой жизни. Всегда есть новые активности, которые можно добавить к способностям фиче-команды поставлять практически готовый продукт. Этот инструмент можно использовать в качестве маяка, чтобы направлять совершенствование команды. В компании, с которой я работал, мы определили «создание руководства пользователя» и «создание видеоролика с инструкциями» как будущие активности кросс-функциональной команды.
Создание Feature Team Adoption Map
FTAM можно создавать, когда мы хотим перейти к фиче-командам или отследить динамику совершенствования команды. На вертикальной оси FTAM мы отображаем продукт, а на горизонтальной DoD. В книге по LeSS в главе «Начало работы» описаны шаг 1 (определить продукт) и шаг 2 (определить Критерии Готовности). Объединяя результаты этих двух шагов в Feature Team Adoption Map, мы можем увидеть широкий контекст.
Вертикальная ось: Продукт
При создании FTAM мы начинаем с оси продукта, потому что на горизонтальной оси описываются действия, необходимые для статуса «готово», а это требует понимания всего продукта. И Люй (Yi lv) объясняет в своем блоге (2): «Определение фичи зависит от определения продукта. Продукт формирует границы фичи, и фича является законченной в рамках продукта». Часто бывает сложно прийти к согласию в части определения продукта. Во многих случаях определение продукта привязано к компонентам, определяемым как продукт, что приводит к фейковым FTAM и запутанным настройкам.
В книге по LeSS (1) рекомендуется задавать вопросы для установления границ и расширения параметров, чтобы четко определить элементы продукта. Вопросы для расширения являются вариантами вопроса, «Что выходит за рамки нашего текущего продукта и может удовлетворить потребности клиентов?» Ответы на этот вопрос будут соответствовать стратегии продукта и расширят текущий объем работ по созданию продукта. Распространенное заблуждение заключается в том, что тут подразумевается продукт LeSS, хотя люди думают, что это продукт клиента. Продукт LeSS — это продукт, как он воспринимается разработчиками программного обеспечения. Возьмем для примера страхование. Документ, который хранится у вас дома и подтверждает, что вы застрахованы, — это материализация страхового продукта. Программное обеспечение, необходимое для предоставления страховой услуги, — это продукт LeSS, который включает в себя приложение, веб-сайт, администрирование страховой программы, ПО для расчетов и т. д.
Ограничивающие вопросы помогают лучше понять фичи нашего продукта. Фичи нужно знать для того, чтобы определить, какие знания необходимы каждой будущей фиче-команде. Поэтому мы должны задать себе вопрос: «В чем заключается фича, которую клиент хочет видеть в нашем продукте, и из каких компонентов состоит эта фича?» Для ответа нам нужен Бэклог Продукта. Анализируя фичи в Бэклоге Продукта, мы можем отследить, из каких компонентов нашего программного ландшафта состоит эта фича, и сгруппировать их так, чтобы в случае изменения фичи изменять их совместно. Это отобразит логическую группировку компонентов в фичи и, таким образом, покажет будущий состав команды. Задавая ограничивающие вопросы, мы также узнаем, какие компоненты не войдут в фичу из-за организационных ограничений или как не имеющие к ней отношения.
Горизонтальная ось: Активность
Для построения горизонтальной оси мы перечисляем все активности, которые должна выполнить команда, чтобы выпустить потенциально готовый к релизу продукт, то есть описываем DoD. При перечислении активностей особое внимание нужно уделить тестированию. Тестирование как активность является слишком широким понятием. Его нужно уточнить, перечислив различные типы и уровни тестирования (модульное, интеграционное, на проникновение, производительность, регрессионное и т. д.). Расположите активности от меньшего объема работ к большему в том порядке, в каком команды обычно выполняют свою работу. Перечислите все активности, необходимые для того, чтобы передать клиенту готовый продукт. Если ваши команды еще не достигли совершенства, это будет охватывать несколько команд и, возможно, несколько подразделений.
Пример
Изображение FTAM, приведенное в книге по LeSS, помогает понять, что такое FTAM, но в нем недостаточно конкретики, чтобы понять, как применять этот инструмент.
Пример ниже — это FTAM вымышленной компании, которая разрабатывает CMS (систему управления контентом). Компания разработала стратегию расширения своего продукта, чтобы созданный продукт отвечал финансовым потребностям клиента. Существующие компонентные команды могут изменить какой-либо один компонент, например, фронтенд портала (FE портала). Другие компонентные команды работают над бэкендом портала (BE портала).
Синий прямоугольник отражает текущие возможности команд. Эти компонентные команды тестируют свое решение на предмет наличия проблем с интеграцией, затем передают свой код в отдел интеграции, отвечающий за подготовку, интеграцию и пользовательское тестирование (UAT). После этого программное обеспечение передается отделу выпуска, сотрудники которого выполняют оставшиеся тесты и организуют развертывание в продакшн.
Чтобы эта организация могла перейти к фиче-командам, в идеале будущим командам необходимо специализироваться в предметной области клиентов. Тогда они смогут на уровне продукта решать проблемы клиентов с CMS, то есть править код фронтенда и бэкенда портала, компонентов менеджера и платформы. К сожалению, это пока невозможно, так как компания работает с партнером, который в настоящее время самостоятельно заботится обо всех изменениях компонентов портала. Для создания совершенных фиче-команд необходимо сосредоточить все знания в одном месте, а это в ближайшей перспективе невозможно. Новые фиче-команды смогут осуществлять все изменения программного обеспечения на уровне системы: портал, менеджер и команда платформы.
Это не идеал, но хороший шаг в сторону совершенства. Владелец Продукта проверил фичи в Бэклоге Продукта, чтобы убедиться, что только небольшое количество фич нуждаются в одновременном изменении различных систем (портал, менеджер, платформа). Соответственно, уровень зависимости низкий.
В DoD для новых фиче-команд (оранжевый блок) пользовательское тестирование не входит. Уровень кросс-функциональности новых фиче-команд был установлен на минимальный набор возможностей (до тестирования системы), так как это тот уровень готовности, который могут обеспечить все новые фиче-команды. Некоторые будущие фиче-команды уже могли включать пользовательское тестирование в состав активностей, но, к сожалению, не все, так как пока не во всех командах хватает сотрудников с необходимыми навыками.
На оси активностей есть организационное ограничение: после пользовательского тестирования программное обеспечение передается в отдел техподдержки, отвечающий за защиту от проникновений, производительность и развертывание. На данной стадии разработчикам не предоставляется физический доступ к этим средам из-за применяемых политик безопасности.
Feature Team Adoption Map наглядно отражает текущую и будущую способность фиче-команд поставлять готовый продукт. Может быть трудно создать команды, полностью охватывающие разработку продукта и все активности, так как это потребует слишком больших организационных изменений, которые могут повлечь за собой бизнес-риски. В таком случае эти способности исключаются из текущего объема работ команд, и FTAM служит для визуализации целей совершенствования.
Примечание
В данной статье я попытался описать, что такое Feature Team Adoption Map и как этот инструмент можно использовать. Несмотря на то, что статья, полагаю, помогла вам лучше понять этот инструмент, лучший способ освоить его — это создать собственную карту. Я приглашаю вас попробовать описанный мною подход на практике и попытаться создать FTAM для команд в вашей организации. И не стесняйтесь делиться своими выводами.
Чтобы эта организация могла перейти к фиче-командам, в идеале будущим командам необходимо специализироваться в предметной области клиентов. Тогда они смогут на уровне продукта решать проблемы клиентов с CMS, то есть править код фронтенда и бэкенда портала, компонентов менеджера и платформы. К сожалению, это пока невозможно, так как компания работает с партнером, который в настоящее время самостоятельно заботится обо всех изменениях компонентов портала. Для создания совершенных фиче-команд необходимо сосредоточить все знания в одном месте, а это в ближайшей перспективе невозможно. Новые фиче-команды смогут осуществлять все изменения программного обеспечения на уровне системы: портал, менеджер и команда платформы.
Это не идеал, но хороший шаг в сторону совершенства. Владелец Продукта проверил фичи в Бэклоге Продукта, чтобы убедиться, что только небольшое количество фич нуждаются в одновременном изменении различных систем (портал, менеджер, платформа). Соответственно, уровень зависимости низкий.
В DoD для новых фиче-команд (оранжевый блок) пользовательское тестирование не входит. Уровень кросс-функциональности новых фиче-команд был установлен на минимальный набор возможностей (до тестирования системы), так как это тот уровень готовности, который могут обеспечить все новые фиче-команды. Некоторые будущие фиче-команды уже могли включать пользовательское тестирование в состав активностей, но, к сожалению, не все, так как пока не во всех командах хватает сотрудников с необходимыми навыками.
На оси активностей есть организационное ограничение: после пользовательского тестирования программное обеспечение передается в отдел техподдержки, отвечающий за защиту от проникновений, производительность и развертывание. На данной стадии разработчикам не предоставляется физический доступ к этим средам из-за применяемых политик безопасности.
Feature Team Adoption Map наглядно отражает текущую и будущую способность фиче-команд поставлять готовый продукт. Может быть трудно создать команды, полностью охватывающие разработку продукта и все активности, так как это потребует слишком больших организационных изменений, которые могут повлечь за собой бизнес-риски. В таком случае эти способности исключаются из текущего объема работ команд, и FTAM служит для визуализации целей совершенствования.
Примечание
В данной статье я попытался описать, что такое Feature Team Adoption Map и как этот инструмент можно использовать. Несмотря на то, что статья, полагаю, помогла вам лучше понять этот инструмент, лучший способ освоить его — это создать собственную карту. Я приглашаю вас попробовать описанный мною подход на практике и попытаться создать FTAM для команд в вашей организации. И не стесняйтесь делиться своими выводами.
