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

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

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

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

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

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

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


person Adam Parkin    schedule 18.08.2015    source источник


Ответы (4)


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

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

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

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

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

person Barnaby Golden    schedule 19.08.2015
comment
Я бы добавил, что ярлыки сквозные. Вы можете пометить различные типы проблем в Jira одной и той же меткой. Таким образом, вы можете создать собственный флаг, такой как TODO, NEEDS ATTENTION, REQUIRES DOCUMENTATION и т. Д. Вы не будете создавать для этого эпики или компоненты. - person Benny Bottema; 31.01.2018

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

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

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

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

person Krishnan    schedule 28.04.2016
comment
Компоненты - это не функции. - это интересное различие, в чем разница? Есть ли опасность в сопоставлении компонентов и функций примерно 1: 1? - person Adam Parkin; 29.04.2016
comment
Опасностей как таковых нет. Просто неэффективно, что вы в конечном итоге либо используете их только одним способом (в качестве компонента или функции), либо смешиваете их, вот и все. Я много думал о том, как точно объяснить разницу, и надеюсь, что следующее станет хорошим примером. - person Krishnan; 30.04.2016
comment
Я возьму в качестве примера задачу технического долга (большую), потому что она сама по себе является очень технической проблемой, но помогает лучше увидеть разрыв. Скажем, Refactor Payment Module - это гигантская задача, охватывающая несколько спринтов. Следовательно, вы захотите создать его как Epic. И компонентами для этой проблемы будут Платежный модуль. Хммм ... просто подумал об этом: другими словами, эпики описывают более широкие цели, которых необходимо достичь, и после достижения они должны умереть, тогда как компоненты просто обозначают части или области приложения, которое будет иметь значение навсегда. - person Krishnan; 30.04.2016
comment
Я не уверен, что эти разграничения действительно решают поставленный вопрос. Компоненты и метки не вечны - конструкция системы может измениться так, что данный компонент больше не существует. Ярлык может потерять актуальность по разным причинам. Когда вы все это разбиваете, эпос, метка и компонент - это просто категоризации с различными ограничениями на то, что вы можете с ними делать (хотя и странные ограничения - история не может быть обязательной для двух эпосов? История не может включать в себя два компонента?). Я не считаю дизайн Atlassian очень дальновидным. - person Eric; 11.01.2017
comment
Похоже, что компоненты действительно допускают множественные назначения, и это хорошо, поэтому разграничение между компонентами и метками становится более полезным, поскольку компоненты контролируются централизованно, а метки имеют произвольную форму. - person Eric; 11.01.2017
comment
В дополнение к этому, компонентам также можно назначить «ведущую роль», что полезно в различных сценариях. - person Jon Luzader; 12.03.2018

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

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

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

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

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

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

Примеры ярлыков.

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

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

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

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

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

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

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

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

person Anestis Kivranoglou    schedule 16.01.2017
comment
В контексте разговора здесь есть еще один термин Инициативы, который может быть синонимом Эпики. Инициативы IMO более понятны, в то время как Epic, как мы видим, расплывчата. Тем не менее, пока ваша команда находится на той же странице, что и определение, вы, как правило, можете делать то, что хотите. - person Max Cascone; 26.08.2017
comment
Это должен быть ответ. Так много ответов я вижу здесь и в Интернете без примеров. Это единственный пример - исходный ответ жалкий @BarnabyGolden - person TheBlackBenzKid; 19.04.2018

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

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

person Sateesh    schedule 16.10.2015