Керстин Экснер
Senior Product Manager, eBay
26 декабря 2022
Что такое Agile Epic? Лучшие практики, шаблон и пример
"Знаете ли вы разницу между agile epic и пользовательской историей?Или как наилучшим образом использовать agile epics для ваших требований к продукту и дорожной карты продукта?Если вы хотите узнать, как использовать agile epics в своих интересах, прочитайте мои семь лучших советов с шаблоном и примерами.
Что такое Agile Epic?
Agile epic - это полезный инструмент в гибком управлении проектами, используемый для структурирования вашего гибкого бэклога и дорожной карты.
Проще говоря, agile epic - это набор небольших пользовательских историй, описывающих большой рабочий элемент. Считайте Epic большой пользовательской историей. Например, epics часто используются для описания новой функции или большей части функциональности, которую нужно разработать.
Epic - это верхний информационный уровень в agile-бэклоге. Он содержит несколько пользовательских историй, и каждая пользовательская история, в свою очередь, содержит все задачи, необходимые для реализации.
Иерархия Epic, пользовательских историй и задачAgile Epic в основном используются, когда часть работы слишком велика, чтобы ее можно было выполнить за один спринт или итерацию. Если вы используете epic для группировки пользовательских историй для новой функции, легко отслеживать прогресс и знать, какой процент выполненной работы по сравнению с невыполненной.
Эпики обычно пишутся и поддерживаются владельцем продукта или менеджером по продукту.
7 лучших практик использования Agile Epic
Для Agile epic нет установленного шаблона. Вы можете написать его любым удобным для вас способом, если это помогает в планировании вашей работы и общении с вашими гибкими командами и заинтересованными сторонами.
Независимо от того, используете ли вы scrum, канбан или гибридный процесс разработки, epics поможет вам спланировать вашу работу и отчитаться о ней.
Вот несколько советов, чтобы убедиться, что ваши agile epic наиболее полезны.
Unsupported block type: action
1. Начните с эпических историй, а затем с историй (сверху вниз).
Поиск ваших Epic может быть очень полезен с помощью карты истории пользователя. Ваша “Активность” верхнего уровня на карте пользовательских историй становится epic, а нижние уровни становятся пользовательскими историями и задачами.
Когда вы разрабатываете совершенно новый продукт, начиная с epics и детализируя их по мере продвижения, это дает вам представление о проделанной и выдающейся работе.
Часто agile epic соответствуют функциям или более крупным улучшениям (например, редизайну части вашего продукта), но то, как вы хотите структурировать свои epic, полностью зависит от вас.
2. Назовите эпическую скважину
Когда вы называете свои agile epic, подумайте о том, кто будет использовать эту информацию. Например, ваши команды гибкой разработки должны понимать, что они создают, а ваши заинтересованные стороны также должны понимать ваш прогресс.
В то время как история пользователя описывает потребности конечного пользователя, хорошей практикой будет, если epic описывает результат, которого вы хотите достичь с его помощью.
Рассмотрите эти примеры для эпических имен:
- Поток оформления заказа V2
- Оптимизация процесса оформления заказа
- Увеличьте коэффициент конверсии при оформлении заказа
Первое название вообще не описывает, что это такое, кроме какой-то работы по оформлению заказа. Второе название лучше, поскольку оно описывает, что процесс оформления заказа должен быть оптимизирован. Но третье название еще лучше, поскольку оно включает в себя результат, которого вы хотите достичь с помощью этой оптимизации.
В инструментах гибкого управления, таких как, например, Jira от Atlassian, epics можно использовать для фильтрации, группировки и создания отчетов. Поэтому важно выбрать название, которое говорит само за себя.
3. Сделайте свои Epic подходящего размера
Epic обычно используется, когда для выполнения работы над элементом невыполненной работы требуется более одного спринта. Epic может быть разбит на столько пользовательских историй, сколько вам нравится, если вы можете отслеживать весь список.
Epic должен быть не слишком большим и не слишком маленьким. Эмпирическим правилом будет период реализации от нескольких недель до нескольких месяцев. Это хороший размер для отчетности о проценте выполненных работ.
Создание слишком больших epic означает, что прогресс идет очень медленно, процентные показатели почти не увеличиваются за двухнедельный спринт, а отчетность не имеет смысла. Кроме того, если внедрение epic занимает слишком много времени, вероятно, на этом пути будет так много изменений в требованиях, что отчетность о прогрессе практически становится бессмысленной.
Создание слишком маленьких epic означает, что у вас будет большое их количество, чтобы манипулировать ими в вашем бэклоге или дорожной карте. Может стать трудно сохранить представление высокого уровня. Кроме того, если epics завершаются за очень короткое время (например, за один спринт), они просто добавляют дополнительные накладные расходы, не обеспечивая большой ценности.
4. Используйте Epics для структурирования вашего бэклога
Epics - отличный способ структурировать бэклог продукта, который обычно состоит из очень длинного списка пользовательских историй. Не каждая история должна быть включена в epic, поскольку небольшие фрагменты работы просто завершаются в течение одного спринта. Но структурирование больших элементов работы в epics имеет два основных преимущества:
- Он обеспечивает высокоуровневое представление больших элементов в вашем бэклоге,
- Поскольку размер epic складывается из добавления точек истории всех его пользовательских историй, epics также предоставляют сравнение относительного размера инициатив для определения приоритетов.
Список epic также можно использовать для создания высокоуровневого представления дорожной карты продукта для высшего руководства.
5. Используйте Epics для координации нескольких команд
Epics могут быть очень полезны для координации работы нескольких групп разработчиков гибкого программного обеспечения. Объединение работы для нескольких групп разработчиков в одном epic позволяет разделить отчетность по каждой команде и отслеживать прогресс в целом.
6. Включите показатели успеха
При определении epic стоит подумать о том, какая метрика успеха может быть связана с ним. В конечном итоге вся работа с продуктом служит для обеспечения ценности клиента для конечных пользователей. Включение показателя успеха в ваш epic означает, что члены команды разработчиков и заинтересованные стороны понимают, чего вы пытаетесь достичь с помощью этой части работы.
Некоторые компании используют OKR для постановки квартальных целей. Ссылка на показатель OKR в epic - отличный способ привязать epic к бизнес-целям.
7. Сделайте Epics гибкими по объему
Поскольку epic описывает высокоуровневый рабочий элемент, выполнение которого продолжается в течение нескольких недель или месяцев, вполне вероятно, что по ходу работы возникает новое понимание или обнаруживаются новые технические сложности. Поэтому epic должен быть гибким по объему.
Масштаб epic определяется объемом связанных с ним пользовательских историй, обычно измеряемых в пунктах истории. По мере появления новых требований могут добавляться новые истории пользователей и расширяться рамки epic.
Шаблон Agile Epic
Для epic нет установленного формата, но несколько полезных вещей, описанных выше, полезны.
Шаблон Agile epic- Выберите хорошее название, которое говорит само за себя.
- В описании дайте общее представление о том, что включает в себя epic. Обратитесь к любым целям компании, чтобы проиллюстрировать, как это связано с бизнес-приоритетами.
- Показатель успеха конкретно описывает, что будет измеряться после завершения этого epic.
- Большая история пользователя обозначает историю пользователя на уровне всей Epic. Это очень полезно для документирования того, как этот epic обеспечивает ценность для ваших пользователей.
Пример Agile Epic
Вот пример epic для нового оптимизированного процесса оформления заказа мобильного приложения с целью увеличения конверсии.
Пример Agile EpicВ рамках этого epic у нас могли бы быть истории пользователей, такие как:
- Интеграция Apple Pay (“Как покупатель, я хочу расплачиваться одним касанием телефона, чтобы быстро оформить заказ”)
- Используйте платежный адрес в качестве адреса доставки по умолчанию (“Как покупатель, я хочу ввести данные своего адреса только один раз, чтобы я мог быстро оформить заказ”)
Заключение
Agile epics - это гибкий инструмент в вашем гибком инструментарии. Начиная новую крупную разработку, подумайте о больших объемах работы, необходимых для ее завершения, и определите несколько эпосов. Затем вы можете создавать все свои истории пользователей в этих epics по ходу работы и сохранять гораздо лучший обзор, чем в неструктурированном бэклоге.
Epics можно использовать по-разному. Мне было бы очень интересно узнать, как вы используете epics в своих гибких командах в комментариях.
Для получения дополнительных статей с практической информацией о самых разных темах управления продуктами подпишитесь на нашу рассылку.
Материал был переведен и отредактирован командой ProductLand. Источник
Присоединяйся к чату комьюнити
Будь в курсе всех новостей, обращайся за помощью к коллегам и находи единомышленников!
