Понятие EPIC в методологии Scrum: как применять и декомпозировать. Примеры и эффективные приемы для разбиения больших задач на управляемые части.

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

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

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

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

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

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

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

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

• Добавить кнопку «избранное» на каждую страницу

• Создать базу данных, где будут храниться товары из избранного

• Создать страницу, где будет отображаться избранное пользователя

• Добавить на главную страницу кнопку «Посмотреть избранное».

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

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

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

• составить список гостей,

• купить свадебное платье,

• сделать дизайн приглашений и разослать их гостям,

• забронировать ресторан и согласовать меню,

• заказать тамаду, фотографа и видеооператора,

• выбрать начинку для торта и заказать его,

• и еще много–много всего.

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

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

• Эпики в скрам помогают яснее увидеть цель проекта.

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

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

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

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

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

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

• Обязательно фиксируется общая цель спринта, ее нужно достичь в конце.

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

• Как правило, спринт длится от одной до четырех недель . В Apple спринт длится 3 недели. Но бывают и исключения. Так в Nokia спринт длился аж 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).

• Чем срок спринта короче, тем более гибким становится процесс разработки. Команда быстрее получает обратную связь, может внести изменения, что–то исправить или улучшить. Идеальный спринт длится 1-2 недели.

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

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

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

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

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

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

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

• приоритизировать

• декомпозировать.

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

• иметь свою собственную ценность в основе,

• их можно успеть сделать за спринт.

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

• разбить по процессам

• разбить по ролям

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

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

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

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

• Какие можно оставить на последний момент

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

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

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

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

• Скрам–мастер. Этот человек контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче. Выявляет проблемы и узкие места в процессе работы. Устраняет их. И в итоге доводит продукт до выпуска.

• Команда разработки. Это 7-9 человек, которые непосредственно работают над продуктом. В этой команде могут быть продажники, программисты и дизайнеры, копирайтеры и аналитики, бухгалтеры и маркетологи. Это не хаотичный набор сотрудников, а только те, кто реально нужен проекту. Участники команды мотивируют друг друга, подтягивают, если нужно. Здорово, если в команде царит дружеская конкуренция.

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

• Команды делит всю работу по объему спринта.

• Эпик разбивают на кусочки.

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

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