JIRA: Эпики против этикеток против компонентов

83

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

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

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

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

Точно так же я мог бы легко использовать метку «Account_Management», и любые истории / тикеты, которые являются частью функции управления учетными записями, просто помечались этой меткой.

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

jira  jira-agile  epic 
— Адам Паркин
источник

Ответы:

64

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

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

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

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

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

— Барнаби Голден
источник
5
Я бы добавил, что ярлыки сквозные. Вы можете пометить различные типы проблем в Jira одним ярлыком. Таким образом, вы можете создать собственный флаг, такой как TODO, NEEDS ATTENTION, REQUIRES DOCUMENTATION и т. Д. Вы не будете создавать для этого эпики или компоненты.
— Бенни Боттема
37

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

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

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

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

— Кришнан
источник
«Компоненты - это не функции». - это интересное различие, в чем разница? Есть ли опасность в сопоставлении компонента с функцией примерно 1: 1?
— Адам Паркин
Опасностей как таковых нет. Просто неэффективно, что вы в конечном итоге либо будете использовать их только одним способом (в качестве компонента или функции), либо смешать их, вот и все. Я много думал о том, как точно объяснить разницу , и надеюсь, что следующее будет хорошим примером.
— Кришнан
2
В качестве примера я возьму техническую долговую (большую) задачу, потому что это сама по себе техническая проблема , но помогает лучше увидеть разрыв. Скажем, «Платежный модуль рефакторинга» - это (как предполагается) гигантская задача, охватывающая несколько спринтов. Следовательно, вы захотите создать это как Epic . И компонентами для этой проблемы будут Платежный модуль . Хммм ... просто подумал об этом: другими словами, эпики описывают более широкие цели, которых нужно достичь, и однажды достигнутые они должны умереть , тогда как компоненты просто обозначают части или области применения, которые будут иметь значение навсегда.
— Кришнан
Я не уверен, что эти разграничения действительно решают поставленный вопрос. Компоненты и метки не вечны - дизайн системы может измениться так, что данный компонент больше не существует. Ярлык может потерять актуальность по разным причинам. Когда вы все это разбиваете, эпос, метка и компонент - это просто категоризации с различными ограничениями на то, что вы можете с ними делать (хотя и странные ограничения - история не может быть обязательной для двух эпосов? История не может включать два компонента?). Я не считаю дизайн Atlassian очень дальновидным.
— Эрик
Похоже, что компоненты на самом деле допускают несколько назначений, что хорошо, поэтому разграничение компонентов и меток становится более полезным, поскольку компоненты контролируются централизованно, а метки имеют произвольную форму.
— Эрик
25

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

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

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

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

Примеры компонентов

  • Клиентское приложение для Android
  • Серверный API
  • База данных и т. Д. .....

Примеры этикеток .

  • Секторы бизнес-логики (например, заказы, счета, пользователи, продукты)
  • Улучшение качества кода
  • Рефакторинг
  • Удобство использования
  • Запрос / жалоба пользователя В целом все, что помогает категоризировать вещи.

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

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

Больше? 10 спринтов? 10 историй? 20 историй? или что?

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

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

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

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

— Анестис Кивраноглу
источник
В контексте разговора здесь есть еще один термин « инициативы», который может быть синонимом эпоса . IMO Initiatives более понятна, а Epic, как мы видим, нечеткая. Тем не менее, пока ваша команда находится на той же странице, что и определение, вы, как правило, можете делать то, что хотите.
— Макс Кэскон
4
Это должен быть ответ. Так много ответов я вижу здесь и в Интернете без примеров. Это единственный пример - исходный ответ жалкий @BarnabyGolden
— TheBlackBenzKid
6

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

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

— Сатиш
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.