JIRA: эпики vs этикетки vs компоненты

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

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

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

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

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

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

65
jira jira-agile

4 ответов

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

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

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

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

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

52

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

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

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

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

26

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

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

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

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

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

  • Android клиентское приложение
  • сервер В API
    • Расширения)
  • нашему вспомогательному персоналу нужно больше инструментов для решения проблем. (обогатить инструменты поддержки)
  • программное обеспечение слишком сложно использовать! ( перепроектировать UI UX)

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

13

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

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

4