JIRA: Epics vs Labels vs Composants

Ce blog a une définition de l’épopée dans JIRA:

Les épopées sont des corpus de travail significativement plus grands. Les epics sont un travail au niveau des fonctionnalités qui englobe de nombreuses user stories. En utilisant l’exemple ci-dessus, une épopée peut être la fonctionnalité de gestion de compte complète et la possibilité de voir les achats précédents.

Donc, si (en tant que propriétaire du produit) j’ai une fonctionnalité importante que je souhaite livrer et qui comprendra de nombreuses tâches plus petites et probablement des sprints, une épopée est un bon choix.

Cependant, je pourrais tout aussi bien créer un composant (en utilisant l’exemple du blog) “Gestion de compte”, et assigner ce composant à toute tâche liée à cette fonctionnalité.

De même, je pourrais aussi facilement utiliser une étiquette “Account_Management”, et tous les articles / tickets faisant partie de la fonctionnalité de gestion de compte sont simplement étiquetés avec cette étiquette.

Alors ma question: pourquoi / quelles circonstances utiliseriez-vous une épopée? pourquoi / quelles circonstances utiliseriez-vous un composant? Pourquoi / quelles circonstances utiliseriez-vous une étiquette? C’est-à-dire que tous les trois (épopées, étiquettes, composants) semblent servir des objectives très similaires (regrouper un ensemble de problèmes), quelle est la différence?

Avec les étiquettes et les composants, si vous souhaitez en sélectionner un, vous devez utiliser la recherche par problème. Si vous utilisez des épopées, vous pouvez également utiliser la recherche de problèmes, mais vous disposez également de fonctionnalités intégrées dans JIRA Agile.

Dans la vue backlog d’un tableau JIRA Agile, vous avez un onglet Epic. Cet onglet vous permet de sélectionner les problèmes associés aux épopées individuelles. De plus, il est doté de fonctionnalités facilitant l’ajout de nouveaux problèmes à une épopée. Le dernier avantage est que le nom épique est affiché de manière colorée à côté des problèmes de la liste. Cela peut être très utile lorsque vous visualisez l’arriéré et que vous obtenez une idée du travail à venir.

Vous pouvez en savoir plus sur les épopées sur la page Atlassian Working with Epics .

Les composants sont utiles pour l’équipe technique car ils peuvent couvrir de nombreuses épopées. Un composant typique peut être «firebase database» ou «interface utilisateur». JIRA offre la possibilité d’atsortingbuer du travail à un utilisateur particulier pour un composant particulier. Par exemple, tous les problèmes créés avec un composant de «firebase database» pourraient être atsortingbués à Jill Smith.

Les étiquettes sont beaucoup plus adaptables et présentent l’avantage de permettre des affectations multiples (plusieurs étiquettes peuvent donc être associées à un problème). Avec les étiquettes, c’est à vous de voir comment vous les utilisez.

Par définition, les épopées sont des problèmes de courte durée par rapport au projet dans son ensemble. Les composants et les étiquettes sont pour toujours. Et, vous devriez vous en tenir à leurs véritables significations, même si cela peut être tentant.

Créez Epics pour les fonctionnalités , ou comme mentionné par @Sateesh, pour des histoires plus importantes. Ils doivent résoudre leur problème et, une fois le besoin de l’entreprise terminé, ils doivent être fermés .

Les composants ne sont pas des fonctionnalités . Ce sont les parties techniques du système. Ils peuvent également être utilisés pour classer vos pièces ou … enfin, les composants: P … de votre produit.

Les étiquettes peuvent être n’importe quoi, comme mentionné par @barnaby. Généralement, ce sont des mots-clés, des phrases-clés, des mots auxquels les gens peuvent vouloir associer une tâche, etc. Je les utilise principalement pour améliorer la recherche des problèmes dans une perspective à long terme. Il y a un plugin JIRA qui vous donne un nuage d’étiquettes JIRA (à des fins de fantaisie, je pense: D) qui pourrait vous intéresser également.

Ajout: Atlasian a maintenant créé un nouvel article expliquant cela de leur sharepoint vue.

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

Mon avis / usage.

Les étiquettes et les composants sont quasiment simples et répondent déjà bien.

Exemples de composants

Application client Android
API serveur
Base de données etc …..

Exemples d’ étiquettes .

Secteurs de logique métier (ex Commandes, factures, utilisateurs, produits)
Amélioration de la qualité du code
Refactor
Facilité d’utilisation
Requête / réclamation de l’utilisateur En général, tout ce qui aide à classer les choses.

Mais permettez-moi de donner mes deux centimes sur Epics, car je trouve cette phrase trop générique.

Les épopées sont des corpus de travail significativement plus grands

Plus grand? 10 sprints? 10 histoires? 20 histoires? ou quoi?

Personnellement, je classerais les épopées en objectives .

Chaque année et chaque sortingmestre, votre entreprise organise une réunion avec tous les membres et parties prenantes et conclut ce qui suit

Nous devons cibler plus de plates-formes (epic = Platform Expanding )
Notre personnel d’assistance a besoin de plus d’outils pour gérer les problèmes. ( Enrichir les outils de support )
Le logiciel est trop difficile à utiliser! ( Refonte de l’interface utilisateur UX )

Cela signifierait 3 épopées avec un ensemble d’histoires pour couvrir chacune de ces exigences génériques

Les épopées sont des histoires plus grandes qui nécessitent plus d’un sprint. One Epic peut impliquer plusieurs user stories. Chaque user story peut appartenir à un ou plusieurs composants. Dites, vous avez une recherche de disponibilité de compagnie aérienne épique. Cela peut avoir plusieurs user stories comme la recherche OW, la recherche RT, etc. Certains ou tous peuvent impliquer des composants tels que le cache, la politique de voyage et le moteur de réservation.

Les étiquettes sont juste pour plus de commodité. Cela n’a peut-être pas de signification physique.