Что такое эпик в скрам, примеры эпиков, как с ними работать + приемы декомпозиции эпиков

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

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

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

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

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

• Пользователь может сохранять товары в избранное, чтобы снова их там посмотреть
• Пользователь может посмотреть избранное, чтобы купить добавленные туда товары.

Затем уже эти пользовательские истории нужно разбить на задачи:

• Добавить кнопку «избранное» на каждую страницу
• Создать базу данных, где будут храниться товары из избранного
• Создать страницу, где будет отображаться избранное пользователя
• Добавить на главную страницу кнопку «Посмотреть избранное».

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

Сам по себе эпик в скраме — это описание верхнего уровня. А пользовательские сценарии или user story — это уже детализированные требования, в которых при этом есть часть ценности всего эпика.

Как вы поняли, эпик — это нечто эпичное. То, к чему не так–то просто подступиться. Чтобы стало еще понятнее, можно проиллюстрировать примером из жизни. Например, самое эпичное из жизни большинства девушек — провести свадьбу. К такой задаче так просто и не подступиться, но можно разбить на шаги и выполнять все по списку:

• составить список гостей,
• купить свадебное платье,
• сделать дизайн приглашений и разослать их гостям,
• забронировать ресторан и согласовать меню,
• заказать тамаду, фотографа и видеооператора,
• выбрать начинку для торта и заказать его,
• и еще много–много всего.

Но когда все эти задачи будут выполнены, то и весь эпик будет готов.

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

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

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

Затем сам Epic в Scrum разбивают на истории. То есть он состоит из них. Истории стараются брать такие, чтобы можно было реализовать их за 1-2 недели.

Задачи (они же таски) — это этапы, которые надо сделать, чтобы завершить историю.

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

• Обязательно фиксируется общая цель спринта, ее нужно достичь в конце.
• Перед началом работы, команда обсуждает продолжительность спринта. При работе над следующим продуктом он может меняться, но тоже только после обсуждения и обоснований.
• Как правило, спринт длится от одной до четырех недель . В Apple спринт длится 3 недели. Но бывают и исключения. Так в Nokia спринт длился аж 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).
• Чем срок спринта короче, тем более гибким становится процесс разработки. Команда быстрее получает обратную связь, может внести изменения, что–то исправить или улучшить. Идеальный спринт длится 1-2 недели.

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

• Эпик помогает понять требования высокого уровня от заинтересованных сторон и то, что именно нужно. В нём отражается конечный результат по фиче.
• Он также нужен для определения объема работы, который согласуется с клиентом. Это также помогает в оценке того, сколько времени потребуется, чтобы доставить полную функциональность.
• Эпики помогают зафиксировать объёмные идеи в бэклоге продукта. Они устанавливают иерархию для PBI, где эпик представляет исходную идею, тесно связанную с конкретным результатом.

Как работать с эпиком в скрам?

Тут ничего нового — работать как с обычной пользовательской историей. То есть эпик:

• надо обсуждать внутри команды
• приоритизировать
• декомпозировать.

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

• иметь свою собственную ценность в основе,
• их можно успеть сделать за спринт.

Тут есть несколько хитрых приемчиков в дополнение к обычным методам декомпозиции.

• разбить по процессам
• разбить по ролям
• разбить по времени завершения.

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

В работе все также.

• Определяем, какие задачи надо сделать первыми
• Какие можно оставить на последний момент
• Какие в принципе можно делать только, если время останется.

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

Напомню заодно и про роли в скрам:

• Владелец продукта или Product owner. Это не заказчик, но человек из команды, которые выполняет его роль. То есть он отвечает за видение продукта заказчиком. Принимает решения об изменениях. Связывает команду и заказчика. Здорово, если Product owner видит реализацию проекта на 2-3 спринта вперед.
• Скрам–мастер. Этот человек контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче. Выявляет проблемы и узкие места в процессе работы. Устраняет их. И в итоге доводит продукт до выпуска.
• Команда разработки. Это 7-9 человек, которые непосредственно работают над продуктом. В этой команде могут быть продажники, программисты и дизайнеры, копирайтеры и аналитики, бухгалтеры и маркетологи. Это не хаотичный набор сотрудников, а только те, кто реально нужен проекту. Участники команды мотивируют друг друга, подтягивают, если нужно. Здорово, если в команде царит дружеская конкуренция.

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

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

Еще один важный момент: какого–то фиксированного или регламентированного способа по работе с эпиками в скрам нет. Да и не может быть, ведь все гибко. Все зависит от проекта и потребностей вашей команды.