Координация Потоков Создания Ценности (Value Stream Coordination)

“Все, что нужно, чтобы играть в бейсбол: сила, хорошая скорость и координация, чтобы ударить по мячу. Не более того.”

RS

Ryne Sandberg

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

Хотя многие потоки ценности работают независимо, взаимодействие между несколькими Решениями может предоставить дополнительные возможности и преимущества на уровне Портфеля, которые будут недоступны для конкурентов. В связи с этим Lean-Agile лидеры внимательно относятся к вызовам и возможностям, которые демонстрируют потоки создания ценности. Они делают их максимально независимыми, одновременно объединяя и координируя их, преследуя более масштабную цель предприятия.

Потоки Ценности и Зависимости

По самой своей природе потоки создания ценности существуют достаточно долго и, как правило, не зависят друг от друга. Например, компания, занимающаяся системами или программным обеспечением, может продавать множество различных продуктов и услуг в сильно отличающихся друг от друга технологических областях. Однако, скорее всего, в реальности у этих продуктов и сервисов есть зависимости между собой. Хотя мы обычно думаем о зависимостях в негативном ключе, принцип #2 «Системное мышление» помогает нам понять, что ценность протекает через эти зависимости. Да, есть проблемы, которые необходимо решить, но есть и ценные возможности, которые можно использовать.

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

Координация Потоков Создания Ценности

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

1. Кто координирует Потоки Ценности? Роли и Обязанности

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

• Что разрабатывается? – Владелец Продукта > Менеджеры Продукта > Менеджеры Решения
• Как разрабатывается? – Agile Команда > Архитектор и Инженер Систем > Архитектор и Инженер Решения
• Управление процессом на основе лидерства-служения и обеспечение выполнения (производство, доставка…) – Scrum Мастер > Инженер Релизного Поезда (Release Train Engineer, RTE) > Инженер Поезда Решения (Solution Train Engineer, STE)

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

• Менеджеры Портфеля Решений (Solution Portfolio Management) – отвечают за направление портфеля в сторону нескольких интегрированных решений.
• Архитектор Предприятия (Enterprise Architect) – предоставляет техническое руководство по долгосрочной эволюции технологий и платформ и более крупным нефункциональным требованиям (например, безопасность, соответствие регуляторным требованиям, производительность и многое другое) для нескольких портфельных решений.
• Офис Управления Agile Программами (APMO) – Офис Управления Agile Программами вместе с Инженерами Релизных Поездов (Release Train Engineer, RTE) и Инженерами Поездов Решения (Solution Train Engineer, STE), как правило, отвечают за поддержку децентрализованного, но эффективного выполнения программ.

2. Применение Каденции и Синхронизации

На рисунке 3 показано, как принцип #7 «Применять каденцию и синхронизацию» так же актуален для уровня портфеля, как и для Релизных Поездов Agile (Agile Release Train, ART) и Поездов Решения (Solution Train). Преимущества этого принципа такие же:

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

Единая каденция также создает возможность движения в едином ритме для всего Решения с уровня Портфеля (через Эпики), с определенными точками планирования и интеграции. Каждая из этих точек позволяет объективно оценить разрабатываемое решение и поддерживает масштабную непрерывную интеграцию с внутренними и внешними поставщиками.

3. Добавление новой работы на уровне Портфеля

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

Во время каждого Инкремента Программы (PI) Релизные Поезда Agile (Agile Release Train, ART) и Поезда Решения (Solution Trains) сосредоточены на Целях Инкремента Программы (PI Objectives), за выполнение которых они взяли на себя обязательства. Любая новая работа, добавленная в течение уже начавшегося Инкремента Программы, вызывает существенные сбои, переключение задач, перестройку и реорганизацию людей в соответствии с новыми целями. Каденция портфеля должна обеспечивать надежный и стабильный ритм добавления новой работы в портфель, так как команды не могут одновременно выполнять уже взятые на себя обязательства на Инкремент Программы и, не отменяя их, брать новые объемы незапланированной работы. Только стабильная каденция обеспечит предсказуемое выполнение программ, которое так важно предприятию.

Через Канбан систему Портфеля эта каденция также устанавливает стандартные механизмы для Владельцев Эпика, Архитекторов Предприятия и других, кто управляет эпиками. Любой эпик, который не готов к PI Планированию, должен ждать следующего Инкремента Программы, даже при доступной ёмкости. Ограничение по времени, создаваемое каденцией, также устанавливает лимит Незавершенной Работы (WIP) для существующей и новой работы, которая будет введена в систему.

4. Гарантированные точки интеграции

При интеграции решений между потоками ценности может оказаться невозможным полностью интегрировать их каждую итерацию (рисунок 5).  Поэтому крайне важно выполнять частичную интеграцию на протяжении всего Инкремента Программы (PI), когда полная интеграция еще невозможна. Эти точки интеграции на основе каденции являются единственно верной оценкой пропускной способности (скорости) портфеля. Чем чаще мы интегрируемся, тем быстрее учимся.

Важно учитывать следующие экономические соображения при определении интеграционной каденции:

• Преимущества более быстрого обучения, что часто приводит к более высокому качеству и лучшим продуктам
• Стоимость отложенного обучения и возможная переделка
• Затраты и преимущества DevOps автоматизации
• Ожидаемая глубина интеграции
• Необходимая точность обратной связи
• Требуемый уровень удовлетворенности клиентов (от удовлетворения до восторга)

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

5. Дорожная Карта Портфеля

Как показано на рисунке 6, Дорожная Карта Портфеля является, с одной стороны, производной от Дорожных Карт Решений, а с другой стороны, вносит свой вклад в них. Это высокоуровневое представление дает возможность интегрировать в более высокоуровневый обзор соответствующие дорожные карты Решений и связанные с ними Вехи (Milestones).  Этот обзор уже в свою очередь демонстрирует комплексную масштабную картину портфеля заинтересованным лицам предприятия.

6. Развертывание и Выпуск новой работы

Из-за собственных особенностей потоков создания ценности и зависимостей развертывание и выпуск интегрированной ценности может зависеть от фактически доступных возможностей DevOps. В некоторых случаях Релизные Поезда независимо и самостоятельно организуют все необходимые DevOps возможности. В других случаях может возникнуть потребность участия выделенных или общих служб организации, а также Команд Системы со стороны отдельных Релизных Поездов (ART) и/или потоков ценности, которые помогают интегрировать решение в релиз (выпуск) на уровне Портфеля (рисунок 7).

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