jira что такое эпик

Истории, эпики и инициативы

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

Просмотр тем

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

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

Что такое истории, эпики и инициативы?

Эпики и истории в Agile

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

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

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

Примеры agile-историй

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

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

Полные определения, примеры и рекомендации приведены в следующих разделах.

Эпики и инициативы в Agile

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

Пример эпиков в инициативе

Предположим, ваша ракетная компания хочет в этом году сократить стоимость запуска в космос на 5 %. Такая цель идеально походит на роль инициативы, так как за один эпик с этой масштабной задачей не справиться. Инициативу можно разделить на такие эпики, как «сократить потребление топлива на этапе запуска на 1 %», «увеличить частоту запусков в квартал с 3 до 4» и «уменьшить значение температуры на всех терморегуляторах в экономичном режиме с 22 до 20 градусов Цельсия».

На примере компании Atlassian

У нас в компании инициативы называются «PC-заявками». Заявки Project Central («проекта всех проектов») формируются в Jira Software так же, как и эпики. Каждая команда выбирает для себя 4–5 самых важных целей на год и создает PC-заявку для каждой из них. За счет таких заявок руководство и учредители понимают, какая работа ведется в компании.

За рамками инициатив

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

Многие клиенты Atlassian используют Advanced Roadmaps в Jira Software, чтобы работать с пятью уровнями, которые находятся выше уровня эпиков. Эти уровни позволяют лучше определять проекты и управлять ими.

Узнайте, как компания Twitter унифицировала проекты и ведение совместной работы с помощью Jira: читать полную историю

Когда подразделению Cloud Foundations компании Atlassian потребовалось наглядное представление работы их команды, насчитывающей сотни инженеров, они воспользовались Advanced Roadmaps в Jira, чтобы решить ключевую проблему, с которой сталкиваются организации с распределенными командами. Возможность Advanced Roadmaps в Jira Software помогла команде составить план, который позволял наблюдать общую картину, отслеживать прогресс и без труда делиться информацией с заинтересованными сторонами.

Так выглядит планирование с помощью Advanced Roadmaps для подразделения Cloud Foundations в Atlassian. Узнать больше

Структурирование работы

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

Для начала вы можете узнать о настройке эпиков в Jira Software, а затем ознакомиться со стратегическим планированием и отслеживанием работы нескольких команд с помощью Advanced Roadmaps в Jira Software.

Источник

Issue types в Jira: что делать, чтобы команда не путалась в задачах и всегда доводила проект до конца

Речь пойдет о базовых принципах работы в Jira: проектах (epic), задачах (task) и подзадачах (sub-task). Разберем этапы планирования проектов на доступных примерах. Считаем, это полезно знать при работе не только с Jira, но и со всеми другими таск-трекерами, CRM и планировщиками. Увы, менеджеры часто забывают с чего начать постановку задачи, чтобы ее потом довели до конца.

Jira — мощный таск-менеджер. Для простых проектов часто слишком мощный. Зато в нем можно сделать все, что вам нужно. А если разберетесь в основах, поймете, что работать в нем просто. К сожалению, часто мы наблюдаем такую картину:

Менеджер видит огромный функционал.

Чтобы этого не допустить, достаточно на старте правильно описать работу компании. Разобраться, с какими типами задач вы сталкиваетесь. Создать и настроить 5-10 процессов, которые смогут закрыть все потребности бизнеса. Все станет прозрачно и понятно для руководителя, менеджера проектов и всех сотрудников.

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

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

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

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

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

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

Правильное определение горизонтов планирования — большая тема. Если нужно, сделаем по ней отдельную статью.

Главная основополагающая сущность Jira — Issue (в переводе «проблема»). Можно сказать, что Issue — это любая работа, которую нам предстоит сделать.

Чтобы упорядочить все «проблемы», в Jira предусмотрена многоуровневая настройка интерфейса. Выделим три базовых типа Issue Type:

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

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

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

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

Таск — это простая задача — конкретная и конечная, время выполнения которой можно спланировать.

Протестировать форму, отрендерить изображение, испечь бисквит — это все таски.

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

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

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

Обычно так делают, когда одну задачу нужно разделить на несколько маленьких. По умолчанию сабтаски включены в Jira, но их можно выключить. Например, мы не используем подзадачи, так не видим в них необходимости.

Таск и эпик — это самые универсальные сущности. На простых проектах их достаточно. Но в Jira существуют и другие стандартные типы «проблем»:

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

Чтобы описать в Jira все этапы работы компании, необходимые типы Issue выстраивают между собой в иерархическую древовидную структуру, которая состоит из проектов, задач и подзадач — максимум три ступени иерархии.

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

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

Мы рассказали лишь о базовых принципах работы над проектами в Jira.

Процессы могут быть очень простыми:

Задача поступила в работу, ее сделали, отправили на проверку и окончательно завершили.

Бывают процессы сложнее:

Программист пишет код, отправляет на проверку, передает на тестирование и, если все хорошо, завершает задачу.

Или можно описывать все максимально подробно:

Дизайнер создает макет — согласовывает, подбирает шрифт — согласовывает, подбирает палитру — согласовывает и т.д.

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

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

Плюсану. Просто у товарищей свое видение, которое они проецируют на всех.

Если бы было:
Issue types в Jira: как мы с ними работаем, чтобы команда не путалась в задачах и всегда доводила проект до конца

То и вопросов не было.

Epic в джира это агрегатор для фич. Фичи включают в себя user story (отобразить таблицу, редактировать строку, удалить строку) и tasks (задеплоить, развернуть, закупить). каждая из story или task может включать sub-tasks (сделать фронт, чтобы отобразить грид, сделать запросы к БД для чтения данных на грид, сделать запросы к API чтобы вернуть данные из БД)

Приветствую коллеги, на фоне эпидемии и задержек грузовых ёмкостей, как-то забываются хорошие новости. А между тем – Atlas Air Worldwide Holdings сообщила о высоких результатах, полученных ею за третий квартал 2021 года. Основной причиной в компании называют –повышенный спрос на грузовые авиаперевозки и затруднения у наземных видов транспорта. По…

Источник

Механизмы Jira, которые позволяют эффективно структурировать работу

Любая команда разработчиков при уходе от модели «waterfall» или любого другого традиционного стиля управления проектами сталкивается с одним и тем же вопросом «как мне структурировать свою работу?». К счастью метод разработки по методологии Agile использует четыре четких механизма для того, чтобы структурировать любой проект:

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

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

Epic vs Story

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

Эпики обычно сводятся к более стратегическим целям или инициативам. Эти инициативы обычно разрабатываются в процессе долгосрочного планирования и формирования стратегии развития.

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

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

В зависимости от того какую структуру agile Вы используете (scrum, kanban или Ваш собственный выбор) эпики могут использоваться по разному. Для канбана эпики могут использоваться в качестве направляющих для сегментации различных потоков работ. Если вы используете скрум, эпики могут помочь обозначить работу в Ваших спринтах, как в примере ниже.

Миссия на Марс — это эпик в этом спринте. TIS 1, TIS 2 и т.д.. — все задачи в спринте (TIS Sprint 1). Вы должны заметить, что в спринте есть как задачи (истории) так и эпики.

Оценка эпиков.

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

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

Что такое задача?

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

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

Истории пользователей (задачи) — это несколько предложений на простом языке, которые описывают желаемый результат. Они не вникают в подробные требования.

Пример задачи – рассказа пользователя.

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

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

Что такое версия?

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

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

Пример использования версий

Владелец продукта может структурировать стратегию выпуска версий ПО следующим образом:

Область изменения версии также является естественной частью развития проекта по методу agile. Графики Burndown наглядно показывают, как версия эволюционирует с течением времени. Изменения в версии должны обсуждаться со всей командой, чтобы держать всех в курсе дела.

Что такое спринт?

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

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

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

Пример спринта Вы уже видели на скриншотах выше. TIS Sprint 1 – это множество задач.

Несколько вещей, которые вы должны знать о спринте:

Отличным инструментом для любой команды scrum являются графики burndown. Они четко отслеживают прогресс на протяжении всего спринта с «оставшейся работой» по оси Y и «временем» на оси X. Диаграммы и графики Burndown являются мощным мотиватором для команды, и фокусируют каждого ее члена на работе над спринтом.

Масштабирование.

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

Наша компания предоставляет различные услуги по внедрению, оптимизации, переносу, обучению работы с продуктами jira, обращайтесь [email protected]

Источник

Изучение того как использовать эпики в программном обеспечении JIRA

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

Руководство по использованию и созданию эпиков в программном обеспечении Jira Software

Учебник по эпикам в Jira

В этом уроке мы объясним, как использовать эпики в agile разработке программного обеспечения. Мы научим вас, как работать с эпиками в Jira Software, чтобы помочь вам в вашем следующем большом проекте. Этот урок будет сосредоточен на эпиках в классических проектах и проектах следующего поколения.

Если вы используете Next-Gen, нажмите здесь.

Время:

10 минут чтения. Завершить в течение 2 недель или более

Аудитория:

Вы новичок в гибкой разработке программного обеспечения или Jira Software

Необходимое условие (Предпосылки):

Вы создали учетную запись в программном обеспечении Jira Software и проект в программном обеспечении Jira Software

КОГДА Я ДОЛЖЕН СОЗДАТЬ ЭПИК?

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

Шаг 1: Создайте новый эпик в Jira Software

Есть два способа создать эпик :

Создайте эпик из новой задачи

Создайте эпик из Панели эпиков (Epics Panel)

Когда вы создаете эпик, вам нужно будет ввести следующие данные:

Шаг 2: Добавить и удалить истории

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

КАКАЯ РАЗНИЦА МЕЖДУ ЭПИКАМИ И ДРУГИМИ ВИДАМИ ЗАДАЧ?

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

Есть два способа добавить историю в эпик:

Из экрана создания задачи

Из Панели Эпика (Epics Panel)

Чтобы удалить задачу из эпика

Перейдите либо к списку основных требований (Backlog), либо к активным спринтам:

Шаг 3: Просмотр ваших эпиков

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

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

Шаг 4: Установите дорожки для своих эпиков на своей доске

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

Вот как вы можете настроить это в Jira Software:

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

Шаг 5: Следите за ходом вашего эпика

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

В программном обеспечении Jira Software вы можете использовать Отчет по эпику (Epic Report), чтобы легко получить эту информацию.

Шаг 6: Завершите свой эпик

Чтобы завершить эпик:

КОГДА Я ДОЛЖЕН ОТМЕТИТЬ ЭПИК, КАК СДЕЛАННОЕ?

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

Хотите узнать больше?

Более подробную информацию о работе со спринтами в Jira Software можно найти в нашем руководстве по спринтам.

Есть вопросы? Спросите Атласское Сообщество.

Работа с эпиками в софтверных проектах следующего поколения

Мы только что представили эпики (Epics) для проектов программного обеспечения следующего поколения, и с этим появился новый способ управления ими: дорожная карта. Это представляет собой огромное и интересное изменение в управлении эпиками (Epics) в облаке программного обеспечения Jira Software Cloud. Мы считаем, что это будет более простой способ управления и визуализации ваших эпиков, и нам очень хотелось бы услышать, что вы об этом думаете.

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

КАКАЯ РАЗНИЦА МЕЖДУ ЭПИКАМИ И ДРУГИМИ ТИПАМИ ЗАДАЧ?

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

Шаг 1: Создание эпиков на дорожной карте

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

КОГДА Я ДОЛЖЕН СОЗДАТЬ ЭПИК?

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

Совет для профессионалов: за пределами дорожной карты вы также можете создавать эпики из глобального меню.

Шаг 2: Изменить даты начала и окончания

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

Шаг 3: Добавьте и удалите задачи

Чтобы добавить задачи с доски и списка основных требований (backlog):

Если задача уже принадлежит эпику, опция «Добавить эпик» (Add epic) будет заменена на «Изменить эпик» * (Change Epic*).

В списке основных требований (Backlog)

Чтобы добавить задачи в эпик из дорожной карты:

Совет для профессионалов: Вы можете выбрать несколько задач с помощью команды кликом на Mac или Ctrl кликом на Windows, и затем добавить их все одновременно в эпик.

Шаг 4: Просмотр деталей эпика

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

Шаг 5: Настройте дорожки для своих эпиков

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

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

Шаг 6: Завершите свой эпик

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

Чтобы завершить эпик:

КОГДА Я ДОЛЖЕН ОТМЕТИТЬ ЭПИК, КАК ЗАВЕРШЕННЫЙ?

Пометьте свой эпик как завершенный, когда вся работа над эпиком завершена. Чтобы сделать это проще, мы рекомендуем придумать четкое определение готового эпика при его создании.

Узнайте больше

Источник