Что такое эпик в jira
Узнайте, как использовать эпики в Jira Software
Руководство по созданию и использованию эпиков в Jira Software
Просмотр тем
Учебное руководство по эпикам Jira
Из этого обучающего руководства вы узнаете, как использовать эпики в Agile-разработке ПО с помощью Jira Software. Оно посвящено эпикам в проектах компании и проектах команды.
Создавать эпики рекомендуется в тех случаях, когда нужно распределить большой объем работ на несколько спринтов или на длительный период времени. Вы также можете создать эпик, если обнаружите некую закономерность в нескольких пользовательских историях и решите объединить их в одну группу. Ознакомьтесь с примерами и шаблонами эпиков в нашем руководстве по эпикам.
10 минут на прочтение. Прохождение учебного курса занимает не менее 2 недель
У вас нет опыта agile-разработки ПО или применения Jira Software
Вы создали учетную запись Jira Software и проект Jira Software (scrum или kanban)
Работа с эпиками в проектах компании
Шаг 1. Создание нового эпика в Jira Software
Создать эпик в Jira Software можно тремя способами: на дорожной карте, из бэклога или нажав кнопку создания задачи в основном меню. При создании эпика потребуется ввести следующую информацию.
Создание эпика на дорожной карте
Дорожная карта полезна для визуализации и планирования больших объемов работ, которые уже находятся в процессе выполнения или могут стать приоритетными в будущем.
Сначала включите дорожную карту.
Подсказка. Для создания нового эпика также можно навести курсор на промежуток между уже существующими на дорожной карте эпиками. Подробнее о дорожных картах в Jira Software.
Создание эпика из новой задачи
Вы можете создать эпик или задачу любого другого типа из основного меню навигации.
Создание эпика из панели эпиков в бэклоге
Шаг 2. Добавление историй или связанных задач
После того как эпик создан, в него нужно будет добавить истории или связанные задачи.
Для описания одной конкретной задачи используются истории, баги и задания. А эпики, в свою очередь, используются для описания группы задач, связанных с общим большим объемом работ. Работа по выполнению эпика обычно занимает несколько спринтов или просто больший период времени, если вы не используете спринты. Ознакомьтесь с нашим руководством по механизмам поставки, чтобы узнать, как agile-команды изящно управляют объемом работы и придают ей четкую структуру. Вам также может пригодиться наше руководство по работе с задачами в Jira Software.
Добавить историю в эпик можно двумя способами.
Через экран создания задачи
Из панели эпиков
Перейдите в Backlog (Бэклог).
Откройте панель эпиков.
Нажмите Create issue in epic (Создать задачу в эпике)
На дорожной карте
Удаление задачи из эпика
Перейдите в бэклог или раздел активных спринтов:
находясь в бэклоге, перетащите задачу в раздел Issues without epics (Задачи без эпиков), расположенный в нижней части панели эпиков; либо
находясь в бэклоге или разделе активных спринтов, нажмите нужную задачу, чтобы она отобразилась в правой части экрана, а затем нажмите x в названии эпика (например, Apples на скриншоте 1, расположенном ниже).
Шаг 3. Просмотр эпиков
Вы можете использовать бэклог для просмотра информации, связанной с эпиками.
Панель эпиков. Перейдите в Backlog (Бэклог) и откройте панель эпиков для просмотра эпиков и управления ими.
Список эпиков. На панели эпиков отображается список всех эпиков в проекте.
Просмотр задач, входящих в эпик. Нажмите название эпика, чтобы увидеть все относящиеся к нему задачи из всех спринтов.
Вы также можете открыть задачу эпика, чтобы увидеть список содержащихся в ней пользовательских историй.
Шаг 4. Установка «дорожек» для эпиков на доске
Во время спринта может быть полезно разделить доску на отдельные «дорожки» для каждого эпика, чтобы визуально упростить ее.
Вот как это можно сделать в Jira Software.
Перейдите в Backlog (Бэклог) (или активный спринт).
Кнопка «. »Выберите more (
) > Board settings (Дополнительно > Настройки доски).
Нажмите Swimlanes (Дорожки).
В разделе Base swimlanes (Стандартные дорожки) выберите Epics (Эпики).
Когда вы начнете спринт, задачи на доске будут сгруппированы по соответствующим эпикам.
Шаг 5. Отслеживание выполнения эпика
Иногда полезно следить за невыполненными задачами, связанными с эпиком. Например, для эпика, работа над которым займет несколько спринтов, может пригодиться возможность отслеживания оставшегося объема работы для оценки сроков его выполнения.
Для удобного доступа к такой информации можно использовать Epic Report (Отчет по эпику) в Jira Software.
Шаг 6. Завершение эпика
Для завершения эпика перейдите в бэклог или на дорожную карту
Откройте панель эпиков.
В выпадающем меню нужного эпика выберите пункт Mark as Done (Отметить как завершенный).
Автоматизация — отличный способ надежно синхронизировать эпики, истории и подзадачи. См. один из наиболее распространенных примеров использования в библиотеке шаблонов Jira Automation.
Отметьте эпик как завершенный, когда вся работа, запланированная для него, выполнена. Чтобы упростить задачу, рекомендуется определить четкие критерии готовности эпика. Чтобы отметить эпик как завершенный, выполнять все истории, связанные с ним, необязательно.
Хотите узнать больше?
Подробнее о работе со спринтами в Jira Software см. в нашем руководстве по спринтам.
Вы можете задать свои вопросы сообществу Atlassian.
Работа с эпиками в проектах команды
На дорожной карте можно создавать и визуализировать эпики команды, а также управлять ими. Дорожные карты полезны для планирования большого объема работ за несколько месяцев до их начала, а также для того, чтобы объединять схожие истории из разных спринтов.
Шаг 1. Создание нового эпика в Jira Software
Создать эпик в Jira Software можно тремя способами: из дорожной карты, бэклога или основного меню навигации. При создании эпика потребуется ввести следующую информацию.
Создание эпиков на дорожной карте
Эпики создаются и управляются с помощью дорожной карты. Дорожная карта полезна для визуализации и планирования больших объемов работ, которые уже находятся в процессе выполнения или могут стать приоритетными в будущем.
Создание эпика из новой задачи
Вы можете создать эпик или задачу любого другого типа из основного меню навигации на любом экране. Если вы создадите эпик с помощью интерфейса доски, то такой эпик будет отображаться только на дорожной карте или в бэклоге.
Создание эпика из панели эпиков в бэклоге
Чтобы использовать бэклог для Kanban, включите возможность использования бэклога в настройках доски. Подробнее см. в разделе о том, как включить бэклог Kanban.
Шаг 2. Изменение дат начала и завершения
Потяните за один из концов полосы эпика на дорожной карте, чтобы изменить дату его начала или завершения. Вы также можете изменить эти даты, нажав эпик на дорожной карте или в бэклоге. Выставлять даты начала и завершения необязательно, однако рекомендуется для упрощения долгосрочного планирования.
Шаг 3. Добавление связанных задач
Новую связанную задачу можно добавить в эпик непосредственно на дорожной карте, из бэклога или с доски через панель информации о задаче.
Для описания одной конкретной задачи используются истории, баги и задания. А эпики, в свою очередь, используются для описания группы задач, связанных с общим большим объемом работ. Работа по выполнению эпика обычно занимает несколько спринтов или просто больший период времени, если вы не используете спринты. Ознакомьтесь с нашим руководством по механизмам поставки, чтобы узнать, как agile-команды изящно управляют объемом работы и придают ей четкую структуру. Вам также может пригодиться наше руководство по работе с задачами в Jira Software.
На дорожной карте
Доска или бэклог
Из бэклога или с доски через панель информации о задаче
Совет. Вы можете выбрать несколько задач: клавиша Command + щелчок мышью для Mac или клавиша Ctrl + щелчок мышью для Windows —это позволит добавить все задачи к эпику единовременно.
Шаг 4. Просмотр информации об эпике
Чтобы увидеть информацию об эпике, такую как дата его начала, завершения и связанные с ним задачи, выберите эпик на дорожной карте или в бэклоге.
Шаг 5. Установка «дорожек» для эпиков
Во время спринта может быть полезно разделить доску на отдельные «дорожки» для каждого эпика, чтобы более наглядно отобразить прогресс. Вот как это можно сделать в проектах команды.
Совет. Вы можете создать задачу внутри «дорожки» эпика, чтобы быстро добавить ее в этот эпик. Это также можно сделать, выбрав нужный эпик в фильтре.
Шаг 6. Завершение эпика
Когда вся работа над эпиком будет завершена, следует пометить этот эпик на дорожной карте как завершенный.
Отметьте эпик как Done (Завершенный), когда вся работа, запланированная для него, выполнена. Чтобы упростить задачу, рекомендуется во время создания эпика определить четкие критерии его готовности. Чтобы отметить эпик как завершенный, выполнять все связанные с ним задачи необязательно.
Подробнее
Kelly is a Product Marketer on the Jira team. She is passionate about continuous improvement and helping teams work better together. Before Atlassian, Kelly led agile adoption and transformation efforts across Marketing teams, which included scaling Jira and Confluence across 10+ business units and hundreds of users. When she is not busy telling the world about the power of Atlassian tools for teams, you can find her practicing yoga or walking her dogs around the hills of San Francisco.
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 чтобы вернуть данные из БД)
Механизмы 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]