Поток Команды

Поток Команды — это состояние, когда Agile команды обеспечивают непрерывный поток доставки ценности для клиента.

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

При этом сама работа, которую выполняют Agile команды, сложна и комплексна. К ее выполнению привлекается большое количество работников интеллектуального труда. Совокупность всех этих факторов приводит к дополнительным сложностям в рабочем процессе. Для решения этих проблем SAFe разработал рекомендации и специальные практики для Agile команд, при правильном применении которых заказчик будет получать результаты работ настолько плавно, насколько позволяет процесс.

Большая часть этих рекомендаций содержится в 6-м Принципе SAFe «Обеспечить непрерывный поток ценности». Этот принцип выделяет восемь свойств системы потока. Эти свойства помогают рассмотреть поток с разных точек зрения для того, чтобы определить, где могут содержаться проблемы. Решение конкретной проблемы заключается в использовании одного из 8 ускорителей потока, предлагаемых SAFe. Несмотря на то, что набор свойств и ускорителей потока одинаков для всех систем потока, их применение для каждого уровня SAFe (Команда, Релизный Поезд Agile, Поезд Решения, Портфель) будет отличаться.

Далее в этой статье мы расскажем, как применять ускорители к Потоку Команды.

#1 Визуализация и ограничение незавершенной работы (WIP)

Почему это важно?

Большое количество одновременно выполняемой незавершенной работы (НЗР, WIP) снижает производительность команды и препятствует непрерывной доставки ценности для клиента (рис. 1). Это путает приоритеты, вызывает частое переключение контекста, увеличивает потери и накладные расходы. Ситуация с повышенной загруженностью потока напоминает скоростное шоссе в час-пик: нет никаких преимуществ в том, чтобы брать в систему больше работы, чем сама она может выдержать.

Рисунок 1. Чрезмерное количество незавершенной работы замедляет доставку ценности

Что делать?

• Сделать текущий объем работ видимым. Визуализируйте все виды работ, включая работу над новой функциональностью, обслуживание, архитектуру, инфраструктуру и сокращение технического долга. Часто простая визуализация помогает участникам уже начать решать системные проблемы «слишком большого объема работ» и «слишком малой скорости потока».
• Уравновесить WIP с доступной ёмкостью. Установите ограничения на количество незавершенной работы, чтобы уравновесить спрос и имеющуюся ёмкость разработки. Когда какое-либо состояние рабочего процесса достигает установленного лимита незавершенной работы (НЗР, WIP), новая работа не начинается. Это помогает сбалансировать спрос и ёмкость, одновременно увеличивая поток.

#2 Устранение узких мест

Почему это важно?

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

Что делать?

Главная задача – выявить узкие места.

Примеры «бутылочных горлышек»:

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

Многие узкие места возникают, когда работа переходит от одного этапа рабочего процесса к другому. Большой объем работы, накапливающийся перед одним из шагов в Канбан системе Команды (Team Kanban), может указывать на узкое место (Рисунок 2).

Рисунок 2. Работа накапливается перед узким местом

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

После обнаружения «бутылочных горлышек», как правило, есть два способа справиться с узким местом в команде:

1. Увеличить ёмкость в узких местах. Во многих случаях достаточно просто выделить дополнительных людей. Но есть и другие способы. Встраивание качества и другие Agile практики предоставляют много полезных техник для увеличения ёмкости в узких местах, в том числе:

• Коллективное владение (Collective Ownership). Коллективное владение подразумевает, что любой член команды может исправить дефект, внести обновление в рабочий продукт или решить проблему. Однако для того, чтобы избежать непредвиденных последствий от таких изменений, необходимы определенные компетенции от членов команды и локальное управление рабочим продуктом.
• Развитие Т-shaped навыков (T-shaped skills). Agile команды развивают специалистов с Т-shaped навыками. Это люди с глубокими навыками в отдельной области и широкими, но необязательно глубокими навыками в других сферах. Т-shaped навыки расширяют круг вопросов и возможностей, которые может решать каждый член команды.
• Парная работа (Pairing). Парная работа удваивает ёмкость для решения вопроса и помогает лучше разобраться в конкретной проблеме, которая может блокировать прогресс. Это также помогает в развитии Т-shaped навыков.
• «Роение» (Swarming). При «роении» несколько членов команды взаимодействуют друг с другом для выполнения работы, которую каждому из них будет сложно выполнить самостоятельно.

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

Также важно отметить, что некоторые корневые причины узких мест в команде могут находиться вне контроля команды. В этом случае эту проблему необходимо поднять на мероприятии Inspect & Adapt.

#3 Минимизация передач и зависимостей

Почему это важно?

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

Что делать?

• Организуйтесь вокруг ценности. Принцип №10 в SAFe «Организуйтесь вокруг ценности» закладывает основы для минимизации передач и зависимостей. Эффективно выстроенные топологии команд помогают снизить когнитивную нагрузку на отдельную команду.
• Сделайте передачи и зависимости видимыми. Команды должны понимать, какие передачи и зависимости у них существуют, в каких условиях они возникают и какое влияние они оказывают.
• Примите корректирующие меры. Корректирующие действия могут быть очевидны из контекста зависимости. Такие действия часто требуют изменений в процессе, дизайне разрабатывающейся системы, конкретном рабочем продукте, организации или навыках самих команд.

#4 Ускорение получения обратной связи

Почему это важно?

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

Рисунок 3. Цикл PDCA обеспечивает два различных вида обратной связи

Что делать?

• Определите, какие типы обратной связи отсутствуют или непродуктивны. Различные формы обратной связи дают четкие ответы на различные вопросы. Правильно ли расставлены приоритеты? Будет ли архитектура поддерживать функциональность? Сможет ли клиент использовать продукт?
• Сдвиг «обзора со стороны коллег» (peer review) влево. Все результаты работы одного члена команды должны быть просмотрены другим коллегой как можно раньше в цикле. Тем не менее, у многих может быть естественное желание сначала полностью завершить свою работу, а уже потом показывать ее другим. Однако такой подход может привести к чрезмерным инвестициям в непроверенные дизайны и вызвать оборонительную позицию автора в дальнейшем. Примените прозрачность. Сдвиньте влево «обзоры со стороны коллег» (peer reviews) для всей оставшейся незавершенной работы.
• Демонстрируйте работающие системы. В SAFe есть мероприятия для получения быстрой обратной связи. Самым простым примером является Демонстрация Системы (System Demo), которая проводится каждые две недели. Таким образом, в организации устанавливаются правила для проверки основных предположений.
• Частая интеграция и взаимодействие с клиентом. Частая интеграция дает важную обратную связь в отношении текущего подхода к реализации. Кроме того, предоставление клиенту доступа к текущему инкременту продукта в промежуточной среде позволит на ранней стадии получить важную обратную связь.

#5 Работа с малыми партиями

Почему это важно?

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

В системе потока команды можно выделить несколько типов партий:

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

Что делать?

• Используйте рекомендуемую SAFe каденцию и размер команды. Рекомендации SAFe по структуре помогают сохранить размеры партий небольшими. Соблюдение коротких Интервалов Планирования (PI) и итераций способствует еще большему уменьшению размеров партий. Кроме того, рекомендуемый размер Поезда и команд автоматически накладывает ограничение на объем работы, который может быть запланирован и выполнен за период.
• Скорректируйте процесс для поддержки небольших партий. Если какая-то партия остается слишком большой, то для ее сокращения потребуется скорректировать планирование и выполнение (пример: определение гипотезы выгоды и критериев приёмки для Фичи). Также в зависимости от контекста могут быть необходимы и другие изменения (пример: доступность заинтересованных лиц для общения с командой).
• Обеспечьте надлежащую поддержку. Уменьшение размера партии часто приводит к увеличению количества транзакций меньшего размера. Оптимизация и уменьшение размера партии обычно влечет за собой появление и работу над Энейблерами для рефакторинга архитектуры и инфраструктуры.

#6 Уменьшение длины очереди

Почему это важно?

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

Что делать?

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

• Показатели потока, такие как пропускная способность и загрузка (см. ниже), помогают команде использовать только свою доступную ёмкость и брать на себя обязательства в соответствии с этим. Цели на Интервал Планирования (PI Objectives) помогают командам ограничивать обязательства, выходящие за рамки ёмкости. Таким образом, очередь для новых элементов укладывается в Интервал Планирования.
• Короткие временные рамки итерации и четкие цели итерации позволяют сосредоточиться на краткосрочной работе и концентрации на достижении понятного команде практического результата.
• Неофициальные или официальные запросы на дополнительные работы должны направляться в беклог, чтобы не нарушать длину очереди (а не немедленно браться в работу, увеличивая тем самым очередь.

#7 Оптимизация времени «в потоке»

Почему это важно?

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

Человеку может потребоваться до 15-20 минут, чтобы полностью погрузиться в контекст своей работы, и простой внешний фактор может моментально прервать это состояние.

Что делать?

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

Важной задачей для каждого лидера и коуча является устранение этих факторов. Что может помочь увеличить время нахождения «в потоке»:

• Оптимизация встреч и мероприятий. Команды должны измерять эффективность всех своих мероприятий. Например, команда может обнаружить, что она становится более продуктивной, проводя больше времени в неформальном общении, сокращая затраты времени на проведение регулярных мероприятий (например, существенно сокращая продолжительность ежедневной встрече команды по синхронизации). Другие считают, что регулярные более глубокие встречи по синхронизации создают определенный ритм для общения и сводят к минимуму последующие прерывания. Команды должны регулярно анализировать все свои встречи, чтобы понять, как их лучше организовать и кто должен на них присутствовать.
• Внесите еще больше ограничений на количество незавершенной работы. Переключение контекста часто является результатом слишком большого количества незавершенной работы. Чем меньше элементов в работе в любой момент времени, тем меньше прерываний в работе.
• Используйте инновационные шаблоны совместной работы. Нахождение «в потоке» не подразумевает работу в изоляции от других. Такие практики, как парная работа и моб-программирование, могут повысить глубину погружения и фокус внимания.
• Улучшение работоспособности используемого Клиентами продукта. Командам необходимо постоянно выделять ёмкость на поддержание основных активов и кода «в здоровом состоянии». В противном случае будет требоваться всё больше работы для дальнейшего развития и эффективного обслуживания системы.

#8 Исправление устаревших политик и практик

Почему это важно?

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

На что обратить внимание?

Во-первых, лидеры и агенты изменений должны признать, что устаревшие политики и практики, скорее всего, сохранятся, даже если высшее руководство поддержит Lean-Agile трансформацию. Ниже приведены некоторые примеры:

• Традиционное управление проектами и программами (например, управление освоенным объемом (EVM), график разбивки работ, интегрированный сводный график и учет затрат по проекту) помимо Agile практик, которые применяет команда.
• Сохранение отчетов для менеджмента о ходе работ после перехода системы к прозрачности и объективным результатам.
• Разработчики продолжают вести старый табель учетного времени и при этом фиксировать свою работу в инструментах гибкого управления жизненным циклом (ALM). Это приводит к дублированию отчетов.
• В новой организации работ отсутствуют требования по документированию дизайна, поддержанию прослеживаемости для некритичного кода и соблюдению других практик, поскольку «все и так это делают».
• Проведение анализа корневых причин и документирование каждого дефекта вместо поиска решений и устранения проблем.
• Производится разделение между разными командами работающих над одним функционалом программистов, тестировщиков, специалистов, проводящих верификацию и валидацию, для «разделения обязанностей по контролю качества», когда это на самом деле не требуется.
• Регламенты требуют от команд соблюдения водопадных этапов разработки
• Обязательный анализ артефактов со стороны менеджмента и микро-менеджмент по постановке задач.
• Политика вознаграждения и оценки результатов, которая поощряет неправильное поведение.
• Сбор и использование метрик команд для поощрения или наказания.

Что делать?

Лидеры, Скрам Мастера, коучи и SPC должны постоянно искать препятствия для потока. LACE должен устранять препятствия, которые были выявлены, в рамках дорожной карты трансформации. Следует немедленно избавляться от вновь обнаруженных устаревших практик и политик, которые создают препятствия или требуют выполнения дополнительных работ, не создающих ценность, от которых на практике можно отказаться.

Измерение Потока Команды

Трудно улучшить то, что не измеряется. SAFe выделяет три категории измерений — компетенция, поток и результаты. Эти категории помогают оценить текущее состояние и улучшить способность предприятия быстро доставлять инновационные бизнес-решения. Для измерения потока SAFe выделяет шесть показателей: распределение потока, пропускная способность (скорость), время, загрузка, эффективность и предсказуемость. «Пропускная Способность (Скорость) Потока» и «Распределение Потока» особенно важны для потока команды.

Пропускная Способность (Скорость) Потока

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

Решением в этой ситуации было введение более жестких требований в Определение Выполненности (Definition of Done, DoD), чтобы повысить качество выполняемой работы. Это привело к снижению скорости доставки, но каждая история стала более высокого качества. Со временем команда справилась с этой ситуацией и перешла на стадию более стабильного, качественного и продуктивного выполнения работ. Как отмечалось ранее, количественные данные должны сочетаться с качественными показателями, чтобы правильно интерпретировать информацию.

Рисунок 4. Пример скорости потока команды

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

Не менее важно и то, что эти показатели нельзя использовать для сравнения Agile-команд. Локальный контекст каждой команды может быть разным. Любая попытка установить конкретные цели или использовать скорость в качестве оценки производительности не приведет к улучшению и может даже иметь противоположный эффект.

Распределение потока

На рисунке 5 показан пример распределения потока команды: в системе присутствуют различные типы элементов работы, их количество измеряется на границе каждого PI.

Рисунок 5. Распределение потока одной команды с течением времени

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

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

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Team Flow».

Дополнительно почитать:

Статья «Как обеспечить непрерывное движение ценности?»

Статья «Метрики в SAFe»

Статья «Agile Команда»

Статья «Поток Поезда»