JIRA: Epics vs Labels vs Components

В этом блоге есть определение эпоса в JIRA:

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

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

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

Аналогичным образом я также мог бы легко использовать метку "Account_Management", а любые истории/билеты, входящие в состав функции "Управление учетными записями", просто маркируются этой меткой.

Итак, мой вопрос: почему и какие обстоятельства вы использовали бы эпический? почему/какие обстоятельства вы бы использовали компонент? Почему/в каких обстоятельствах вы бы использовали ярлык? Т.е. все три (эпики, ярлыки, компоненты), похоже, служат очень схожим целям (группируя коллекцию вопросов), какая разница?

Ответ 1

С метками и компонентами, если вы хотите выбрать группу из них, вам нужно использовать поиск проблем. Если вы используете эпики, вы также можете использовать поиск проблем, но вы также получаете встроенную функциональность в JIRA Agile.

В обзоре backlog на JIRA Agile-плате у вас есть вкладка Epic. На этой вкладке вы можете выбрать проблемы, связанные с отдельными эпосами. Кроме того, у него есть функциональность, которая упрощает добавление новых проблем в эпос. Конечным преимуществом является то, что эпическое имя отображается ярким цветом наряду с проблемами в списке. Это может быть очень полезно при просмотре отставания и ощущении того, какая работа будет следующей.

Вы можете увидеть больше о эпиках на странице Работа с Epics на Atlassian.

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

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

Ответ 2

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

Создайте Epics для функций или, как упоминалось в @Sateesh, для больших историй. Они должны решить свою цель, и как только деловые потребности будут выполнены, их следует закрыть/сделать.

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

Ярлыки могут быть любыми, как упоминалось @barnaby. Как правило, это ключевые слова, фразы, слова, которые могут быть связаны с заданием, и т.д. Я использую его главным образом, чтобы сделать проблемы более удобными для поиска с долгосрочной точки зрения. Существует плагин JIRA, который дает вам облако ярлыков JIRA (для чисто фантастических целей, я чувствую: D), которые могут вас заинтересовать.

Ответ 3

Дополнение: Atlasian теперь создали новую статью, объясняющую это с их точки зрения.

https://www.atlassian.com/agile/delivery-vehicles

Мое мнение/использование.

Ярлыки и компоненты почти просты и уже хорошо отвечают.

Компоненты Примеры

Клиентское приложение Android
API сервера
Database и т.д.....

Ярлыки.

Секторы бизнес-логики (ex Orders, Invoices, Users, Products)
Улучшение качества кода
Refactor
Юзабилити
Пользовательский запрос/жалоба Обычно независимо помогает категоризировать вещи.

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

Эпики - значительно большие тела работы

Larger? 10 Спринтов? 10 рассказов? 20 рассказов? или что?

Лично я бы классифицировал Epics как Цели.

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

Нам нужно настроить больше платформ (epic = Расширение платформы)
Наш персонал службы поддержки нуждается в большем количестве инструментов для решения проблем. (Инструменты поддержки обогащения)
Программное обеспечение слишком сложно использовать! (Редизайн UI UX)

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

Ответ 4

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

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