Agile

Кросс-функциональные команды и самоорганизация в основе Agile. Part 2.

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

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

Кросс-функциональные команды

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

Термин “кросс-функциональная команда” берет корни из фреймворка Scrum. В то же время, опыт множества проектов показывает, что такой подход к формированию команд является оптимальным как с точки зрения скорости внедрения изменений, так и в плане оптимизации процесса разработки и снижения издержек — ключевых принципов подходов Kanban и Lean. Это позволяет применить данную концепцию и в рамках других Agile фреймворков.

В поисках определения данного термина, логичным будет обратиться к Scrum Guide (здесь и далее приводятся цитаты из официальной русскоязычной версии Scrum Guide):

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

Прежде всего стоит обозначить, что сама сущность кросс-функциональной команды подразумевает активное участие в ней не только технических специалистов (Back-end, Front-end разработчиков и QA специалистов). Такая команда может и по возможности должна включать в себя бизнес-аналитиков, маркетологов, UX-дизайнеров и других специалистов, принимающих активное участие в проекте. Все это делается для достижения следующего немаловажного пункта из Scrum Guide:

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

Роли в рамках кросс-функциональной команды

Какие же роли есть в кросс-функциональной команде? Раз уж мы начали рассмотрение данной концепции на примере Scrum, предлагаю продолжить и взять за пример состав стандартной Scrum Команды:

• Product Owner — отвечает за продукт: формирование требований, работа с roadmap и backlog продукта, планирование релизов, анализ обратной связи, общение со стейкхолдерами;
• Scrum Master — помогает команде и PO с развитием Agile культуры: следит за следованием Scrum, фасилитирует активности, помогает устранить конфликты и препятствия;
• Команда Разработки — специалисты в области Back-end, Front-end, Mobile dev, UX/UI, QA, BA и другие.

При этом в рамках Команды Разработки отсутствует формальное деление по “зонам ответственности” и грейдам — все являются равноценными членами команды и несут равную степень ответственности как за успехи, так и за провалы.

В некоторых командах это приводит, например, к отсутствию выделенного QA специалиста, ведь итоговое качество продукта и его соответствие ожиданиям бизнеса является ответственностью и критерием качественной работы всей команды, а не отдельно взятого специалиста. В связи с этим, широкое распространение получили такие технические практики как Test-Driven Development и Pair Programming, являющиеся частью фреймворка Extreme Programming(XP). Возможность применения практик из различных фреймворков, дополняющих базис основного — одно из главных свойств и преимуществ Agile.

Кросс-функциональный подход к формированию команды может применяться и в рамках любого другого фреймворка. Главное ограничение — размер команды. При этом оно не носит формального характера. Вы не обязаны укладываться в рекомендованный Scrum Guide размер “3–9 человек”, но всегда стоит помнить про формулу, предлагаемую нам Project Management Body of Knowledge (PMBOK):

Общее количество каналов коммуникации равно n(n-1)/2, где n — количество участников проекта.

Таким образом, для команды из 10 участников, число потенциальных каналов коммуникации будет равно 45, для 9 человек — 36, и так далее. В справедливости данной формулы не трудно убедиться. Возьмите стандартный набор инструментов коммуникации внутри команды:

1. Вербальная коммуникация;
2. E-mail;
3. Мессенджер (Slack, Telegram, Skype и др.);
4. Система управления проектом (Jira, Redmine, Asana и др.).

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

На мой взгляд, оптимальный размер команды равен 5+/-2 человека.Стоит учитывать, что в рамках Scrum роли Scrum Master’а и Product Owner’а вынесены за пределы команды разработки и не учитываются при определении размера команды.

Преимущества кросс-функционального подхода

Каковые же преимущества кросс-функциональных команд над классическими?

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

• Быстрая проверка гипотез — имея в составе команды людей, способных реализовать стадии анализа, дизайна, разработки, тестирования и релиза отдельной фичи или всего инкремента за короткий промежуток времени (например, в течение одного Scrum спринта), мы можем быстро проверить любую гипотезу. Автоматизация стадий тестирования и деплоя (CI/CD), а также сбора ключевых метрик являются существенным подспорьем;
• Частая поставка продукта — сбалансированный состав команды позволяет нам сделать вышеописанные этапы работы над продуктом прогнозируемыми и оперативными. То же самое относится и к перечисленным выше техническим практикам;
• Открытость — наличие потребности в регулярном общении внутри команды способствует развитию открытости. Активности в рамках того или иного фреймворка, делающие “сеансы” такого общения обязательными и регулярными существенно ускоряют этот процесс. Главная задача Scrum Master’а или менеджера в данной ситуации — помочь членам команды избавиться от лишней скованности, развивая культуру сотрудничества и полной прозрачности, а также выступая фасилитатором встреч;
• Равенство участников — регулярно находясь в рамках одной команды, участвуя в командных активностях, особенно таких как ретроспектива или планирование спринта в Scrum, мы развиваем культуру, в которой каждый член команды имеет право голоса, право быть услышанным. Безусловно, при обсуждении вопросов архитектуры мнение Senior разработчика и Junior’а не будут иметь равный вес, но сам факт наличия культуры, при которой Junior имеет возможность высказаться и быть услышанным, очень позитивно сказывается на эффективности команды и командной “химии”.

Собираем кросс-функциональную “команду мечты”

Конечно я не смогу дать Вам универсальный рецепт состава команды на все случаи жизни. Вместо этого я предлагаю кое-что получше — перечень инструментов и факторов, которые стоит подготовить и/или принять во внимание при формировании кросс-функциональной команды для Вашего продукта или проекта.

Следующие факторы должны помочь убедиться что все, кто нужен для работы над проектом, на борту:

• Roadmap продукта — наличие четких целей и миссии, а также плана развития продукта на несколько месяцев/кварталов вперед является ключевым фактором для сплочения команды вокруг продукта и его Пользователей. Формирование roadmap’а, его донесение до команды, определение целей и ключевых метрик, а также внесение корректив на основе полученных данных является обязанностью Product Owner’а (в Scrum) или любого другого специалиста, занимающегося развитием продукта;
• Backlog команды — представляет собой ближайший отрезок roadmap’a, конвертированный в пользовательские истории (user story) или технические задачи. Его приоритизация, оценка, формирование релизов и поддержание бэклога в актуальном виде также является зоной ответственности PO, однако активное участие команды в этой работе крайне приветствуется;
• Минимум внешних зависимостей достигается за счет кросс-функционального состава команды. Чем меньше зависимостей, блокирующих команду извне, тем меньше будет случаев несвоевременной поставки продукта и проблем с “протуханием” кода или его написанием “в стол”, вызванных, например, нехваткой QA-специалистов, задержкой со стороны дизайнеров или проблемой с процедурой релиза кода в “боевое” окружение;
• Сбалансированный состав команды соблюдение баланса является вполне логичным требованием. Команде из 3 разработчиков нет необходимости иметь в своем составе 3 аналитиков или 2 тестировщиков. Точно так же не стоит формировать команду исключительно из Junior разработчиков. Даже при достижении полноценной кросс-функциональности, такая команда рано или поздно рискует допустить критическую для продукта ошибку, вызванную неверным выбором технологий или плохой архитектурой;
• Общий уровень Agile культуры и осведомленности о практиках критичен для успеха команды — даже самая лучшая кросс-функциональная команда не сможет быть эффективной долгое время при постоянное смене приоритетов и скоупа работ менеджментом компании. Точно так же команда не сможет реализоваться полностью, если со стороны менеджмента будет активное препятствование любым экспериментам и ошибкам. Фактор культуры также может играть решающую роль при ротации людей между командами. Подключая в команду какого-либо специалиста, незнакомого с ключевыми практиками и ценностями Agile, мы рискуем потратить большую часть времени на его обучение, что скажется негативно не только на его личной производительности, но и на эффективности всей команды;
• Здравый смысл — куда же без него. Прежде всего он пригодится нам, чтобы не брать в команду заведомо невостребованных специалистов или не давать полную свободу действий и решений команде, не достигшей достаточного уровня “зрелости”.

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

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

Источник