Эпики
Epic (Эпик) - это контейнер для весомой "инициативы по разработке решений", которая охватывает значительные инвестиции, которые происходят в рамках портфеля. Из-за их значительного масштаба и влияния эпики требуют определения Минимального жизнеспособного продукта (MVP) и одобрения со стороны Lean Portfolio Management (LPM) перед внедрением.
Lean Portfolio Management (Бережливое управление портфелем) согласует стратегию и исполнение, применяя бережливые и системные подходы к стратегии и инвестиционному финансированию, гибким операциям с портфелем и управлению им.
Портфолио эпика, как правило, является сквозным, обычно охватывающим несколько потоков создания ценности и программных инкрементов (PI). SAFe рекомендует применять цикл "Lean Startup build-measure-learn" (строй-измеряй-учись) для эпиков, чтобы ускорить процесс обучения и разработки, а также снизить риски.
Подробности
В этой статье в первую очередь описывается определение, утверждение и внедрение портфолио эпиков. Программные и Большие решения эпиков, которые следуют аналогичной схеме, кратко описаны в конце этой статьи.
Существует два типа эпиков, каждый из которых может происходить на разных уровнях Фреймворка. Бизнес-эпики напрямую создают ценность для бизнеса, в то время как вспомогательные эпики используются для продвижения Архитектурной взлетно-посадочной полосы для поддержки предстоящих деловых или технических потребностей.
Architectural Runway (Архитектурная взлетно-посадочная полоса) состоит из существующего кода, компонентов и технической инфраструктуры, необходимых для реализации краткосрочных функций без чрезмерной перестройки и задержек.
Важно отметить, что эпики - это не просто синоним проектов; они работают совершенно по-разному, как показано в таблице ниже. SAFe обычно не рекомендует использовать модель финансирования проектов (см. статью "Бережливое управление портфелем"). Вместо этого финансирование для внедрения эпиков распределяется непосредственно на потоки создания ценности в рамках портфеля. Кроме того, Agile Release Trains (ARTs) разрабатывают и внедряют epic в соответствии с циклом бережливого запуска (рис. 6).
Agile Release Train (ART) - это долгоживущая группа гибких команд, которая вместе с другими заинтересованными сторонами постепенно разрабатывает, поставляет и, где это применимо, эксплуатирует одно или несколько решений в потоке создания ценности.
Weighted Shortest Job First (WSJF) Более ценная и кратчайшая работа в первую очередь - это модель приоритизации, используемая для упорядочения заданий (например, Улучшений, Возможностей и Эпиков) для получения максимальной экономической выгоды. В SAFe WSJF оценивается как стоимость задержки (CoD), деленная на размер задания.
| Эпики | Проекты |
|---|---|
| Реализуется стабильными, кросс-функциональными потоками создания ценности и ARTs. | Осуществляется временными командами, которые распускаются после завершения работы |
| Нет фиксированной даты начала и окончания; область действия является переменной. Продолжается, пока WSJF не скажет иначе. | Фиксированная дата начала и окончания; область действия ограничена. Весь объем должен быть реализован. |
| Прогресс измеряется как соответствие результатов с гипотезой о пользе. | Прогресс измеряется на основе выполнения задач. |
| Бережливый бизнес-кейс, основанный на гипотезе выгоды и определении MVP. | Чрезмерно подробное бизнес-обоснование, основанное на спекулятивной ROI (рентабельности инвестиций). |
| Внедрение следует за процессом построения-измерения-обучения из SAFe Lean Startup Cycle | Внедрение обычно следует поэтапному, последовательному (водопадному) процессу. |
| После утверждения бизнес-кейса бережливого производства необходимо приступить к оценке MVP. | После утверждения бизнес-обоснования принимаются предварительные обязательства по всему объему проекта. |
Определение Эпика
Поскольку эпик являются одними из наиболее значительных инвестиций предприятия, заинтересованные стороны должны согласовать их намерения и определение. На таблице ниже представлен шаблон утверждения гипотезы эпика, который можно использовать для сбора, организации и передачи важной информации о эпике.
Elevator pitch – прием, который пришел к нам из США. Дословно он переводится как «презентация в лифте», то есть за несколько секунд нужно рассказать о себе самую суть. Данный прием пригодится не только в бизнесе, но и, например, на родительском собрании в классе своего ребенка.
| Утверждение гипотезы эпика | |
|---|---|
| Дата входа в Воронку: | <Дата, когда эпик попал в воронку.> |
| Название эпика | <Короткое название эпика.> |
| Владелец эпика | <Название владельца эпика.> |
| Описание эпика |
<Шаг Elevator pitch (заявление о ценности), который описывает эпик в ясной и краткой форме> Для <заказчик> которое <что-то делает> и <решает> это <описание - "как"> что <предоставляет ценность> в отличие от <конкурента, текущего решения или несуществующего решения> наше решение <делает что-то лучше - "почему"> |
| Бизнес-результаты | <Измеримые выгоды, которые может ожидать бизнес, если гипотеза эпика подтвердится.> |
| Опережающие индикаторы | <Ранние меры, которые помогут предсказать гипотезу о результатах бизнеса.> Дополнительные сведения по этой теме см. в статьях расширенной темы "Инновационный учет". |
| Нефункциональные требования |
<Нефункциональные требования (NFRs), связанные с эпиком.> |
Портфолио эпиков становятся видимыми, разрабатываются и управляются с помощью системы Портфолио Kanban, где они проходят различные стадии зрелости, пока не будут одобрены или отклонены. Прежде чем приступить к реализации, эпики требуют анализа. Владельцы эпика берут на себя ответственность за основное сотрудничество, необходимое для выполнения этой задачи, в то время как корпоративные архитекторы обычно разрабатывают вспомогательные эпики, которые поддерживают технические соображения для бизнес-эпиков.
Определение MVP эпика
Анализ эпика включает в себя определение Минимального жизнеспособного продукта (MVP) для epic. В контексте SAFe MVP - это ранняя и минимальная версия нового продукта или бизнес-решения, которая используется для доказательства или опровержения гипотезы эпика. В отличие от раскадровок, прототипов, макетов, каркасов и других методов исследования, MVP - это реальный продукт, который может быть использован реальными клиентами для получения достоверного обучения.
Создание бережливого бизнес-кейса
Результатом анализа эпика является Бережливый бизнес-кейс
LPM рассматривает пример бережливого бизнеса, чтобы принять решение о том, стоит ли начинать или нет эпик. После утверждения эпика проекты портфолио остаются в портфолио невыполненных работ до тех пор, пока у одного или нескольких видов эпиков не появятся возможности для реализации и бюджет. Владелец эпика отвечает за работу с Менеджментом продуктов и решений и Системным архитектором/Инженером по разделению эпика на функции или возможности во время доработки по обратной связи. Владельцы эпиков помогают расставлять приоритеты по этим пунктам в своих соответствующих отчетах и несут некоторые постоянные обязанности по управлению и контролю.
Оценка затрат эпика
По мере продвижения эпика по портфельному канбану команде LPM в конечном итоге потребуется понять потенциальные инвестиции, необходимые для реализации предполагаемой ценности. Это требует значимой оценки стоимости MVP и прогнозируемой стоимости полной реализации, если гипотеза эпик подтвердится.
- Стоимость MVP гарантирует, что в бюджете портфеля достаточно денег, чтобы доказать / опровергнуть гипотезу эпика, и помогает гарантировать, что LPM инвестирует в инновации в соответствии с ограничениями бережливого бюджета.
- Прогнозируемые факторы затрат на внедрение в анализе рентабельности инвестиций помогают определить, является ли бизнес-обоснование обоснованным, и помогают команде LPM подготовиться к потенциальным корректировкам бюджетов потоков создания ценности
Стоимость MVP
Оценка стоимости MVP создается владельцем эпика в сотрудничестве с другими ключевыми заинтересованными сторонами. Он должен включать сумму, достаточную для доказательства или опровержения гипотезы MVP. После утверждения стоимость MVP считается жестким ограничением, и поток создания ценности не будет тратить больше этой стоимости на создание и оценку MVP. Если у потока создания ценности есть доказательства того, что эти затраты будут превышены во время внедрения эпика, дальнейшую работу над эпиком следует прекратить.
Оценка Стоимости Внедрения
MVP и/или полная стоимость внедрения дополнительно складываются из затрат, связанных с внутренними потоками создания ценности, плюс любые затраты, связанные с внешними поставщиками. Первоначально он оценивается с использованием размера футболки и уточняется с течением времени по мере внедрения MVP.
Оценка эпиков на ранних стадиях может быть затруднена, поскольку на данный момент данные и знания ограничены. Определение размера футболок - это метод оценки затрат, который может быть использован LPM, владельцами эпика, архитекторами и инженерами, а также другими заинтересованными сторонами для совместной работы по размещению эпика в группы (или группы затрат) аналогичного размера. Диапазон затрат устанавливается для каждого размера футболки с использованием исторических данных. Каждое портфолио определяет соответствующий диапазон цен для каждого размера футболки. Пробелы в диапазонах затрат отражают неопределенность оценок и позволяют избежать слишком большого обсуждения крайних случаев. Полная стоимость внедрения может быть уточнена с течением времени по мере создания MVP и обучения.
Оценка Epics с использованием размеров футболок (проиллюстрированный диапазон затрат является лишь примером)
Затраты поставщика
Масштабные инвестиции часто включают в себя вклад и затраты поставщиков, как внутренних, так и внешних. В идеале предприятия привлекают внешних поставщиков с помощью гибких контрактов, которые поддерживают оценку затрат на вклад поставщика в конкретный проект. Дополнительные сведения по этой теме см. в статье "Расширенная тема гибких контрактов".
Прогнозирование продолжительности эпика
Хотя может быть сложно спрогнозировать продолжительность эпика, реализуемого сочетанием внутренних проектов и внешних поставщиков, понимание прогнозируемой продолжительности эпика имеет решающее значение для правильного функционирования портфолио. Подобно стоимости эпика, продолжительность эпика может быть спрогнозирована как внутренняя продолжительность, продолжительность поставщика, а также необходимое сотрудничество и взаимодействие между внутренней командой и внешней командой. Практически, если эпик не будет полностью передан на аутсорсинг, LPM может сосредоточиться на прогнозах внутренних ARTs, затронутых эпиков, поскольку ожидается, что внутренние ARTs будут координировать работу с внешними поставщиками.
Прогнозирование продолжительности эпопеи требует понимания трех точек данных:
- Предполагаемый размер эпика в ключевых точках для каждого затронутого ARTs, который можно оценить с помощью метода оценки затрат по футболке, заменив диапазон затрат диапазоном точек
- Историческая скорость задействованных ARTs
- Процент (%) распределение мощностей, которые могут быть выделены для работы над эпиком, как это согласовано между руководством продукта и решения, владельцами epic и LPM
В примере, показанном на рисунке 5, в портфолио есть существенный компонент эпика, который затрагивает три ARTs, и LPM стремится получить оценку прогнозируемого количества PI. ART 1 оценил размер эпика в 2000-2500 баллов. Управление продуктами определяет, что ART 1 может выделить 40% от общей мощности на реализацию своей части epic. При исторической скорости в 1000 сюжетных очков за PI ART 1 прогнозирует от пяти до семи PI для эпика.
Программа приращения (Program Increment, PI) - это временной интервал, в течение которого Гибкая система выпуска (ART) обеспечивает дополнительную ценность в виде работающего, протестированного программного обеспечения и систем. PI обычно длятся от 8 до 12 недель. Наиболее распространенной схемой для PI является итерация разработки, за которой следует одна итерация инноваций и планирования (Innovation and Planning, IP).
Рисунок 5. Примерный рабочий лист для прогнозирования продолжительности эпика
После повторения этих вычислений для каждого ARTs владелец эпика может увидеть, что, хотя некоторые ATR, вероятно, будут готовы к выпуску по требованию раньше, чем другие, прогнозируемая продолжительность доставки всего эпика по всем ARTs, вероятно, составит от шести до восьми PI. Если этот прогноз не соответствует требованиям бизнеса, последуют дальнейшие переговоры, такие как корректировка распределения мощностей или выделение большего бюджета на работы, выполняемые поставщиками. Как только эпик будет запущен, владелец эпика будет постоянно обновлять прогнозируемое завершение.
Внедрение эпика
Стратегия бережливого стартапа рекомендует итеративный цикл "создание-измерение-обучение" для инноваций продукта и стратегических инвестиций. Эта стратегия внедрения эпика обеспечивает экономические и стратегические преимущества бережливого стартапа за счет постепенного управления инвестициями и рисками при одновременном использовании преимуществ SAFe в плане потока и видимости (рисунок 6).
Сбор данных, необходимых для доказательства или опровержения гипотезы эпика, представляет собой итеративный процесс, который продолжается до тех пор, пока не будет получен результат, основанный на данных, или команда не израсходует бюджет MVP. В целом, результатом доказанной гипотезы является MVP, подходящий для продолжения инвестиций со стороны потока создания ценности. Продолжение инвестиций в эпик, у которого есть опровергнутая гипотеза, требует создания нового эпика и одобрения функции LPM.
Безопасный Цикл Бережливого запуска
Рис. 6. Epics в цикле бережливого запуска
После утверждения к внедрению Владелец эпика работает с гибкими командами, чтобы начать разработку, необходимую для реализации гипотезы эпика по бизнес-результатам:
- Если гипотеза подтвердится, эпик перейдет в состояние настойчивости, что приведет к увеличению объема работы за счет внедрения дополнительных функций и возможности. ARTs управляет любыми дальнейшими инвестициями в эпик с помощью постоянного определения приоритетов функций WSJF в невыполненной программе. Местные особенности, выявленные в ARTs, и те, что взяты из эпика, конкурируют во время обычной смены приоритетов WSJF.
- Однако, если гипотеза окажется ложной, владельцы Epic могут принять решение о повороте, создав новый epic для проверки LPM или вообще отказавшись от инициативы и переключившись на другую работу в бэклоге.
После оценки гипотезы эпика она может рассматриваться или не рассматриваться как проблема портфеля. Однако у владельца эпика могут быть некоторые текущие обязанности по управлению и контролю. Расширение прав и возможностей и децентрализованное принятие решений в рамках бережливых бюджетов зависят от ограждений для конкретных сдержек и противовесов. Ключевые показатели эффективности потока создания ценности и другие показатели также поддерживают ограничения для информирования LPM о прогрессе эпика в достижении своей гипотезы о бизнес-результатах.
Эпопеи программ и решений
Эпики также могут исходить из местных программ или Курсов по разработке решений, часто начинающихся как инициативы, заслуживающие внимания LPM из-за их значительного влияния на бизнес или инициатив, превышающих порог эпика. Эти эпики требуют бережливого бизнес-обоснования, а также рассмотрения и утверждения с помощью системы Portfolio Kanban. В статье "Программа и решение Канбан" описываются методы управления потоком этих эпиков.
