Эпики

Agile эпики: определение, примеры и шаблоны

Эпик - это большой объем работ, который можно разбить на несколько небольших историй.

Agile эпик - это совокупность работ, которые можно разбить на конкретные задачи (называемые «историями» или «пользовательскими историями») в зависимости от потребностей / запросов клиентов или конечных пользователей.

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

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

Что такое Agile эпик?

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

Эпики почти всегда предоставляются в виде множества спринтов. По мере того, как команда узнает больше об эпике через разработку и отзывы клиентов, пользовательские истории будут добавляться и удаляться по мере необходимости. Это ключ к agile эпикам: масштаб является гибким (flexible), основан на отзывах клиентов и ритме активности команды.

Пример agile эпика

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

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

Команда разработчиков программного обеспечения, поддерживающая покупку билетов на запуск в марте 2050 года, могла бы структурировать свою эпик следующим образом:

Эпик: запуск в марте 2050 года

История: Обновите диапазон дат, чтобы включить даты запуска в  марте 2050 года.

История: Уменьшите время загрузки для запрошенных списков рейсов до < 0,45 секунд

История: Продвигайте летнюю распродажу Сатурна на странице подтверждения бронирования первого класса.

 

Одновременно команды продвижения могут внести свой вклад в один и тот же эпик с этими историями:

Эпик: запуск в марте 2050 года

История: Поддерживаете топливные баки фунтов на квадратный дюйм> 250 PPM при запуске

История: Уменьшите общее потребление топлива на 1%

История: Наймите нового инженера по  продвижению вместо Гари. # garygate2050

 

 Понимание эпиков в рамках полной гибкой программы

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

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

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

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

Создание Agile эпика

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

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

Разбейте agile эпик

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

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

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

Измерение Agile эпиков

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

Диаграмма сгорания эпика показывает фактический и предполагаемый объем работы, которую необходимо выполнить в спринте или эпике. Горизонтальная ось X на диаграмме сгорания указывает время, а вертикальная ось Y указывает истории или задачи.

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

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

Узнайте, как настраивать  диаграммы сгорания  в программном обеспечении Jira

Понимание Agile эпиков

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

ДАЛЕЕ: Узнайте о agile историях.

По материалам Agile Coach "Agile Epics: Definition, Examples, & Templates"