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"