Scrum epic что это

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

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

Редактировать

Эпик в Скрам (v2)

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

Редактировать

Founder, Executive Partner

Зачем нужны эпики в скрам? (v2)

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

Редактировать

Founder, Executive Partner

Сколько времени занимает эпик в скрам

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

Редактировать

Founder, Executive Partner

Эпик в Скрам

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

Редактировать

Founder, Executive Partner
Переквалификация в IT
Станьте руководителем Digital–продукта в Enterprise
Начать обучение →

Пример Epic в Scrum

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

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

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

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

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

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

Редактировать

Founder, Executive Partner

Пример эпик из жизни

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

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

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

Редактировать

Founder, Executive Partner

Зачем нужны эпики в скрам?

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

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

Редактировать

Founder, Executive Partner

Чем эпик отличается от темы, истории и задачи

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

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

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

Редактировать

Founder, Executive Partner

Сколько времени занимает эпик в скрам (v2)

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

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

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

Epics — Эпики

Эпик — существенная инициатива по разработке Решения.

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

• Что мы делаем
• Наша команда
• Блог
• Контакты

• Расписание тренингов
• Карта тренингов
• Сертификации
• Обучение Scrum Master
• Обучение Product Owner
• Обучение Kanban

• Услуги для компаний
• Тренинги для групп от 10 чел.
• Кейсы клиентов

© 2008 — 2023 ScrumTrek

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

Разделите большой объем работы на небольшие истории с помощью эпиков agile.

Автор: Max Rehkopf

Просмотр тем

Краткое описание: в Agile эпик — это объем работы, который можно разбить на несколько отдельных заданий (так называемых «пользовательских историй») в зависимости от потребностей или запросов клиентов или конечных пользователей. Эпики играют важную роль в успехе команд Agile и DevOps.

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

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

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

Что такое эпик в agile?

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

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

Пример эпика в agile

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

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

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

Эпик: запуск ракеты, март 2050 г.
История: обновить диапазон дат, включив в него даты запуска в марте 2050 г.	История: уменьшить время загрузки запрошенных сведений о рейсах до 250 млн⁻¹ фунтов на кв. дюйм во время запуска.	История: сократить общий расход топлива на 1 %.	История: нанять нового специалиста по ракетным двигателям взамен Гэри. #garygate2050

Место эпиков в законченной agile-программе

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

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

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

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

Создание эпика в agile

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

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

Деление эпика на составляющие в agile

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

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

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

Количественная оценка эпиков в agile

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

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

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

Оптимизируйте эпики с помощью автоматизации

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

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

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

Общие сведения об эпиках в agile

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

Поделитесь этой статьей

Max Rehkopf

Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian.

Create epics for free in Jira Software

Подписаться

Подпишитесь и получайте больше статей

Thanks for signing up!

Обучающее руководство

Узнайте, как использовать эпики в Jira Software

С помощью этих пошаговых инструкций вы научитесь создавать эпики в Jira Software и работать с ними

Пользовательские истории в agile?

Пользовательские истории — это требования к системе, которые зачастую выражены в виде «личность + потребность + назначение». Узнайте, как истории выступают в качестве ориентиров для 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 историях.

© 2017 JIRA — real help