Эпики agile. Определение, примеры и шаблоны

В Agile и DevOps эпик предназначен для организации заданий. Это определенный объем работы, который разделяется на отдельные задания (так называемые «пользовательские истории» или просто «истории») в зависимости от потребностей или запросов клиентов или конечных пользователей. По шаблону отслеживания заданий команды могут эффективно упорядочивать и отслеживать свои задания, а также расставлять их приоритеты.

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

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

Эпик — это большой объем работы, который можно разбить на несколько историй поменьше (в Jira они называются «задачами»). Часто эпики объединяют несколько команд, работающих над несколькими проектами; более того, часто их можно отслеживать на нескольких досках.

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

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

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

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

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

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

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

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

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

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

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

Узнайте, как эпики реализованы в Jira.

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

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

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

Чтобы наглядно представить эпики, используются диаграммы Burndown. С их помощью команды находят мотивацию, а заинтересованные стороны из руководящего звена — информацию. Диаграмма Burndown для эпика служит индикатором того, насколько точно организация следует принципам Agile.

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

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

Благодаря диаграмме Burndown можно понять, как команда справляется и где встречаются блокеры. Когда эти данные перед глазами, все участники команды остаются в курсе происходящего и могут открыто обсуждать развитие продукта и прогнозируемое время завершения. А еще прозрачность — это залог доверия.

Узнайте, как настраивать диаграммы Burndown в Jira

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

1. Автоматически добавлять три истории при создании эпика. Перейти к правилу.
2. Автоматически закрывать истории, когда эпик помечается как выполненный. Перейти к правилу.
3. Изменять статус эпика при изменении статуса одной из связанных с ним задач. Перейти к правилу.

Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.

Перейти в библиотеку

Эпики не являются обязательным фундаментом программы Agile, но они — реальная движущая сила для большинства команд Agile и DevOps. Понимание роли эпиков в успехе Agile-программы помогает увидеть контекст, в котором выполняется ваша работа, а разделение эпиков на истории задает темп.