JIRA: Epics vs Labels vs Components

Цей блог має визначення епосу в JIRA:

Епоси - це значно більші обсяги роботи. Епіки - це робота на рівні функцій, яка охоплює багато історій користувачів. Використовуючи наведений вище приклад, епопеєю може бути вся функція управління обліковим записом та можливість перегляду попередніх покупок.

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

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

Так само я міг би так само легко використовувати ярлик "Account_Management", і будь-які історії / квитки, які є частиною функції Управління акаунтами, просто позначаються цим ярликом.

Тож моє запитання: чому / за яких обставин ви б використали епопею? чому / за яких обставин ви б використовували компонент? Чому / за яких обставин ви б використовували ярлик? Тобто - всі три (епопеї, ярлики, компоненти), схоже, слугують дуже подібним цілям (групування збірника питань), в чому різниця?

Якщо ви хочете вибрати групу з мітками та компонентами, вам потрібно скористатися пошуком проблем. Якщо ви використовуєте епоси, ви також можете використовувати пошук проблем, але ви також отримуєте вбудовану функціональність у JIRA Agile.

У вигляді відставання дошки JIRA Agile у вас є вкладка Epic. Ця вкладка дозволяє вибрати проблеми, пов’язані з окремими епосами. Крім того, він має функціональність, яка спрощує додавання нових випусків до епопеї. Остаточна перевага полягає в тому, що епічна назва відображається яскраво кольорово поряд із проблемами у списку. Це може бути дуже корисним під час перегляду відставання та отримання уявлення про те, яка робота буде далі.

Ви можете побачити більше про епопеї на сторінці Atlassian Working with Epics .

Компоненти корисні для технічної команди, оскільки вони можуть охоплювати багато епосів. Типовим компонентом може бути "база даних" або "UI". JIRA пропонує можливість призначити роботу для певного компонента певному користувачеві JIRA. Наприклад, усі проблеми, створені за допомогою компонента "бази даних", можуть бути призначені Джил Сміт.

Етикетки набагато адаптуються, і вони мають ту перевагу, що дозволяють проводити кілька присвоєнь (тому з проблемою може бути пов’язано більше однієї мітки). З етикетками дуже багато залежить від вас, як ви їх використовуєте.

Епічні за визначенням є короткочасними проблемами, якщо порівнювати їх із проектом загалом. Компоненти та ярлики, навпаки, назавжди. І, ви повинні дотримуватися їх використання за їхнім справжнім значенням, наскільки спокусливим може бути інакше.

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

Компоненти не є особливостями . Вони є технічними частинами системи. Вони також можуть бути використані для класифікації ваших деталей або ... ну, компонентів: P ... вашого товару.

Етикетки можуть бути будь-якими, як згадував @barnaby. Як правило, це ключові слова, фрази-слова, слова, до яких люди можуть захотіти поставити завдання тощо. Я використовую його в основному для того, щоб зробити проблеми більш зручними для пошуку з довгострокової точки зору. Існує плагін JIRA, який надає вам хмару ярликів JIRA (для суто вигадливих цілей, я вважаю: D), яка може вас також зацікавити.

Додаток: Atlasian тепер створили нову статтю, яка пояснює це з їхньої точки зору.

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

Моя думка / використання.

Етикетки та компоненти майже зрозумілі та вже добре відповіли.

Приклади компонентів

• Клієнтська програма для Android
• API сервера
• База даних тощо .....

Приклади ярликів .

• Сектори бізнес-логіки (колишні замовлення, рахунки-фактури, користувачі, продукти)
• Поліпшення якості коду
• Рефактор
• Юзабіліті
• Запит / скарга користувача Як правило, все, що допомагає класифікувати речі.

Але дозвольте мені дати свої два центи щодо Epics, тому що я вважаю цю фразу занадто загальною.

Епоси - це значно більші обсяги роботи

Більший? 10 спринтів? 10 історій? 20 історій? або те, що?

Особисто я класифікував би Epics як цілі .

На щорічній / квартальній ретроспективі ваша компанія проводить зустріч з усіма членами та зацікавленими сторонами та робить висновок про наступне

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

Це означало б 3 епопеї з набором історій, що охоплюють кожну із цих загальних вимог

Епопеї - це більші історії, для завершення яких потрібно більше одного спринту. Один епос може включати кілька історій користувачів. Кожна історія користувача може належати одному або декільком Компонентам. Скажімо, у вас є епічний пошук доступності авіакомпаній. Це може мати кілька історій користувачів, таких як пошук OW, пошук RT тощо. Деякі або всі з них можуть включати такі компоненти, як кеш, політика подорожей та механізм бронювання.

Етикетки служать лише для зручності. Це може не мати фізичного значення.