Эпик

5 февраля 2025

Что такое Эпик?

«А что, если мы обнаружили, что мы создаём что-то, что никому не нужно? В этом случае, имеет ли значение, что мы делаем это в срок и в рамках бюджета?»

Эрик Рис, Lean Startup

Эпик — это крупная инициатива по разработке решения.

Эпики, как правило, требуют масштабных инвестиций и оказывают огромное влияние на бизнес организации. Поэтому для Эпика необходимо определить минимальный жизнеспособный продукт (MVP) [1] и получить от команды Бережливого Управления Портфелем (Lean Portfolio Management, LPM) одобрение на работу с ним.

Эпики Портфеля, как правило, являются сквозными и охватывают несколько потоков создания ценности и Интервалов Планирования (Planning Interval, PI). Чтобы ускорить процесс обучения и разработку, а также снизить риски, SAFe рекомендует применять для Эпиков цикл Бережливый Стартап (Lean Startup) «Разработка – Измерение/Оценка — Обучение».

В этой статье мы более подробно остановимся на том, как определять, утверждать и реализовывать Эпики уровня портфеля. Работа с Эпиками уровня Релизного Поезда (Agile Release Train, ART) и Поезда Решения (Solution Train) осуществляется по такому же принципу, как и с Эпиками портфеля. Эту тему мы кратко затронем в конце статьи.

Существует два типа Эпиков, и каждый из этих типов может возникнуть на разных уровнях фреймворка. Бизнес-Эпики напрямую доставляют бизнес-ценность, в то время как Эпики-Энейблеры совершенствуют Архитектурное Русло для удовлетворения бизнес или технических потребностей в будущем.

Важно отметить, что понятие «Эпик» ни в коем случае не является синонимом для «проект». Работа над Эпиками и проектами строится совершенно по-разному, как показано на рисунке 1.

Рисунок 1. Эпики – это не проекты!

SAFe в принципе не рекомендует использовать модель проектного финансирования (см. статью «Бережливое управление портфелем»). Вместо этого финансирование для реализации Эпиков распределяется непосредственно по потокам создания ценности внутри портфеля. Более того, Релизные Поезда (Agile Release Train, ART) разрабатывают и доставляют Эпики в соответствии с циклом Бережливый Стартап (Lean Startup), описанным далее в этой статье (рис. 6).

Определение Эпиков

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

Рисунок 2. Заявление гипотезы Эпика

Загрузить шаблон «Заявление гипотезы Эпика»

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

Создание Бережливого Бизнес Кейса (Lean Business Case)

Результатом анализа Эпика является заполненный Бережливый Бизнес-Кейс (Рисунок 3).

Рисунок 3. Бережливый Бизнес-Кейс (Lean business case)

Загрузить шаблон «Бережливый Бизнес-Кейс»

Команда LPM обсуждает Бережливый Бизнес-Кейс, чтобы принять решение «идём» или «не идём» в разработку (MVP и далее) этого Эпика. После того, как подтверждение со стороны команды LPM получено, Эпики портфеля переходят в состояние «Готово к разработке» в Канбан системе портфеля. Когда у одного или нескольких Релизных Поездов (ART) появляются ёмкость и бюджет — Эпик «вытягивают» на реализацию. Владелец Эпика отвечает за совместную работу с Менеджментом Продукта и Менеджментом Решения, а также Архитекторами Систем, чтобы разделить Эпик на Фичи или Капабилити во время уточнения беклога. Владельцы Эпика помогают расставить приоритеты по этим элементам в соответствующих беклогах и непрерывно несут ответственность за их разработку и контролируют полученные результаты.

Определение MVP

Анализ Эпика включает в себя определение минимального жизнеспособного продукта (MVP) для него. В контексте SAFe-организации MVP — это ранняя и минимальная версия нового продукта или бизнес-решения, используемая для доказательства или опровержения гипотезы Эпика. В отличие от раскадровок, прототипов, макетов и других техник проведения исследований (cusdev), MVP — это реальный продукт, который могут использовать реальные клиенты. Создание минимального, но реального продукта позволяет на практике всесторонне подтвердить или опровергнуть продуктовую гипотезу со стороны реального клиента.

Затраты на Эпик

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

Оценка затрат на создание MVP обеспечивает, что портфель инвестирует достаточно денег, чтобы подтвердить или опровергнуть гипотезу Эпика. Это помогает гарантировать, что команда LPM делает достаточные инвестиции в инновации в соответствии с Бережливыми Бюджетными Направляющими.
Прогнозируемые затраты на обозримо полную реализацию Эпика учитывают анализ рентабельности инвестиций (ROI), что помогает определить, является ли бизнес-кейс обоснованным и рентабельным, а также позволяет лидерам портфеля и Офиса Управления Ценностью (Value Management Office, VMO) подготовиться к потенциальным корректировкам бюджетов для потоков ценности в связи с появлением нового эпика.

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

Процесс оценки стоимости разработки Эпика

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

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

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

По мере создания MVP и получения новой информации Владелец Эпика может инкрементально уточнять общую стоимость реализации Эпика.

Рисунок 4. Оценка Эпиков на примере размеров футболок и диапазон затрат на реальном примере

Затраты на поставщиков

Инвестиции в Эпики часто включают в себя вклад и затраты со стороны поставщиков, как внутренних, так и внешних. В идеальном сценарии предприятия работают с внешними поставщиками на основе Agile контрактов, которые помогают оценить затраты каждого поставщика на разработку конкретного Эпика. Дополнительно почитать о работе с поставщиками можно в статье «Agile контракты».

Прогнозирование продолжительности работы над Эпиком

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

Так же, как и для размера затрат, оценить сколько времени будет продолжаться работа над Эпиком достаточно сложно, так как активности вокруг Эпика включают в себя несколько компонентов: продолжительность работы внутри самой организации, продолжительность работы поставщиков, а также процесс фактического сотрудничества и взаимодействия между внутренними и внешними командами. На практике, если разработка Эпика не будет полностью передана на аутсорсинг, то команда LPM может ориентироваться на прогнозы своих Релизных Поездов (ART), которые вовлечены в работу над Эпиком. Ожидается, что эти Поезда будут координировать работу с внешними поставщиками со своей стороны.

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

Предполагаемый размер Эпика в сторипоинтах для каждого Agile Release Train, вовлечённого в работу над ним. Расчёт можно изначально сделать с помощью размеров футболок и затем заменить диапазон затрат на диапазон сторипоинтов (через вычисленную среднюю стоимость сторипоинта на текущий момент времени – Алексей Ионов).
Историческая пропускная способность в сторипоинтах для Релизных Поездов, задействованных в создании Эпика.
Процент (%) аллокации ёмкости, которые Поезда смогут выделить на работу над Эпиком. Это распределение обычно основано на результатах обсуждений между Менеджментом Продукта и Менеджментом Решения (если последний присутствует в ролях портфеля – Алексей Ионов), Владельцами Эпика и командой LPM.

В примере, показанном на рисунке 5, портфель имеет крупный Эпик-Энейблер «Эпик 1», который затрагивает три Релизных Поезда (Agile Release Train). Команда LPM хочет спрогнозировать, за сколько Интервалов Планирования удастся реализовать Эпик.

ART 1 оценил размер своей части Эпика в 2000 – 2500 сторипоинтов. Менеджмент Продукта определяет, что ART 1 может выделить 40% от своей общей ёмкости на реализацию этой части Эпика. У поезда 1 историческая пропускная способность на один Интервал Планирования — 1000 сторипоинтов. Таким образом, ART 1 прогнозирует, что на его работу над Эпиком потребуется от пяти до семи Интервалов Планирования.

Рисунок 5. Пример таблицы для прогнозирования продолжительности работы над Эпиком

Владелец Эпика собирает такие вычисления от каждого поезда, который планируется вовлечь в работу над Эпиком. В результате Владелец Эпика может увидеть, что некоторые Agile Release Train, скорее всего, будут готовы к выпуску по требованию раньше, чем другие. Тем не менее, прогнозируемая продолжительность доставки всего Эпика по всем ART, вероятно, составит от шести до восьми Интервалов Планирования (PI). Если этот прогноз не соответствует потребностям бизнеса, то необходимо будет обсудить корректировку работы портфеля со всеми заинтересованными лицами. Такие корректировки могут заключаться в изменении аллокации ёмкости у Поездов или увеличении бюджета для поставщиков. Владелец Эпика обновляет прогноз продолжительности работы над Эпиком в начале работы над ним (и далее инкрементально, при появлении новой информации из любого источника – Алексей Ионов).

Реализация Эпиков

Стратегия Бережливый Стартап SAFe (Lean Startup) рекомендует использовать высокоитеративный цикл «создание-измерение-обучение» для обеспечения инноваций в продуктах и реализации стратегических инвестиций. Такой подход к работе над Эпиками даёт реальные экономические и стратегические преимущества от применения метода «Бережливый стартап». Таким образом, организация инкрементально управляет инвестициями и рисками, а также использует преимущества потока и его визуализации, которые заложены в SAFe (рис. 6).

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

MVP необязательно включает в себя все определённые заранее Фичи/Капабилити, он может содержать также просто бюджет на их определение.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

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

Рисунок 6. Эпики в цикле Lean Startup

После того, как Эпик одобрен для реализации, Владелец Эпика взаимодействует с Agile командами, чтобы начать действия, необходимые для проверки на практике гипотезы бизнес-результатов для Эпика:

Если гипотеза верна, Эпик переходит в состояние «Продолжение разработки» (Persevere), что обычно означает расширение работ за счет разработки дополнительных Фич и Капабилити. Релизные Поезда (ART) непрерывно управляют любыми дальнейшими инвестициями в Эпик, с помощью WSJF расставляя приоритеты для Фич в беклоге ART. Фичи, которые возникли локально внутри Agile Release Train, и те, которые появились в результате декомпозиции Эпика на Фичи, конкурируют друг с другом во время регулярного обновления приоритетов с помощью WSJF.
Если гипотеза ложна, Владельцы Эпика могут принять решение о повороте/развороте (Pivot), создав новый Эпик для обсуждения на уровне команды LPM, или полностью отказаться от инициативы и переключиться на другую работу в беклоге.

После оценки гипотезы Эпика он может считаться или не считаться элементом уровня портфеля.

Эпики уровня Поезда не управляются командой LPM и не рассматриваются как активные в Канбан системе Портфеля. Для таких Эпиков может потребоваться отдельная простейшая, но дополнительная к основной, Канбан система на уровне поезда исключительно для учета и управления такими Эпиками.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Тем не менее, Владелец Эпика, как правило, берёт на себя ответственность за управление движением Эпика на протяжении всего жизненного цикла этого Эпика.

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

Эпики Релизного Поезда (ART) и Поезда Решения

Некоторые инициативы Релизного Поезда (ART) и Поезда Решения могут быть слишком большими для разработки внутри одного Интервала Планирования (PI). Также, Эпики могут возникать локально внутри Релизных Поездов (ART) или Поездов Решения. Если Эпик превышает порог, установленный в Направляющих, он рассматривается как инициатива, заслуживающая внимание LPM из-за его значительного влияния на бизнес.

В отдельных случаях Эпики портфеля могут быть декомпозированы на другие Эпики уровня Релизного Поезда и Поезда Решения, чтобы обеспечить инкрементальную разработку. Даже несмотря на то, что такие Эпики будут в основном локальными задачами, они могут оказывать существенное влияние на финансовые, человеческие и другие ресурсы. И это влияние может быть достаточно большим, чтобы оправдать усилия на создание Бережливого бизнес-кейса, обсуждение и получение предварительного финансового одобрения со стороны команды Lean Portfolio Management (LPM).

Одной из важнейших задач при запуске портфельного управления является настройка Бережливых Бюджетных Направляющих и конкретно, в рамках Направляющей №3, правил и политик, по которым определяются и управляются Эпики разного уровня и масштаба. Здесь SAFe задаёт лишь общие рамки, но много решений зависит от лидеров конкретной организации и их видения стратегического управления.

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Как и в случае с Эпиками уровня портфеля, у каждого Эпика Agile Release Train и Поезда Решения обычно есть Владелец Эпика, который помогает определить, исследовать и реализовать его. Если Эпиков достаточно много, то рекомендуется создать локальную Канбан систему уровня ART или Поезда Решения, которая бы отражала этапы Канбан системы портфеля. Такая наглядность поможет управлять Эпиками. Менеджмент Продукта и Менеджмент Решения, а также Владельцы Бизнеса (и команда LPM, если применимо) рассматривают Эпики уровня своего поезда и принимают решение об их утверждении или отклонении на основе анализа и полученных знаний. После утверждения локальный Эпик уровня ART или Поезда Решения разбивается на Фичи или Капабилити для дальнейшей разработки через беклог ART или Поезда Решения соответственно.

Узнать больше:

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2017.

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