Meilleure pratique d'utilisation des composants dans les projets Jira

Question

Nous utilisons beaucoup Jira dans notre développement quotidien. Vous voulez savoir s'il existe des bonnes pratiques pour créer des composants de projet dans Jira ?

Par exemple, à votre avis, est-il préférable de créer un composant pour chaque module de développement dans Jira ou peut-être que des composants à granularité plus fine sont préférés par votre équipe ?

A la vôtre,

Answer 1

Les composants sont comme des petits sous-projets. Les projets semblent être plus utiles lorsqu'ils regroupent des personnes. Je recommande à mes clients que les projets JIRA reflètent l'organisation sociale dans une certaine mesure, du moins jusqu'à ce que le nombre de projets devienne très important.

Évitez également d'utiliser un composant nommé "Misc" ou "Other". Ils ont tendance à devenir des décharges de problèmes dont personne ne se soucie.

~Matt

Answer 2

Le plus important en matière de composants est d'être sans ambiguïté et de ne pas être trop nombreux. Dans notre équipe, nous sommes en train de migrer vers une hiérarchie à 3 niveaux (au sens de GreenHopper) :

• au niveau supérieur, vous avez les composants BA qui sont peu nombreux et délimités par équipe (infra, backend, GUI) - cela permet aux gars BA d'acheminer la demande vers le bon manager de l'équipe DEV désigné comme responsable du composant.
• le deuxième niveau est le processus réel (au sens d'Unix). Cette définition est très claire. Si un problème correspond à plusieurs processus, nous l'assignons à l'un d'entre eux (BTW, GreenHopper n'autorise pas les composants à feuilles multiples, mais JIRA le fait). Ceci est fait par le gestionnaire DEV.
• le troisième niveau est facultatif et rarement utilisé, il désigne un sous-système au sein du processus. Nous l'utilisons lorsqu'une partie considérable des problèmes est liée à une partie bien définie du code et que nous voulons les suivre séparément. C'est généralement le développeur qui travaille sur le problème qui s'en charge.

Pour qu'un tel raffinement progressif fonctionne, vous devez avoir une idée de qui assigne à quel composant et qui traite les questions qui lui sont assignées. Ce dernier est désigné par Component Lead, le premier n'est pas explicitement pris en charge par JIRA (sinon nous pourrions dire que les BA ne voient que leurs composants, les responsables DEV, que leurs sous-composants + tous les BA, etc.)

Answer 3

Je ferais correspondre les composants avec vos modules/artifacts/jarres, de sorte que chaque problème puisse appartenir à un module particulier (bien qu'il puisse avoir des dépendances/relations avec d'autres également).

Si vous avez de bonnes raisons d'avoir une gestion des problèmes plus fine que le niveau du module, demandez-vous pourquoi vous ne sépareriez pas également le module associé.

Ce mappage 1-1 permet de clarifier votre calendrier de publication, vous pouvez facilement identifier les problèmes de la version X de votre projet et les modules sur lesquels vous devez concentrer vos efforts. Cela permet également de simplifier les associations entre Jira, le système de construction et le SCM. Par exemple, si vous utilisez Bamboo, vous aurez probablement un projet de construction par module, vous pouvez donc simplement ajouter l'association.

Answer 4

Depuis la version 4.2.4, il n'est plus possible de versionner des composants, mais uniquement des projets. Gardez cela à l'esprit si vous souhaitez utiliser la fonctionnalité de feuille de route.

Il y a une demande de longue date (plus de 7 ans) pour ajouter la gestion des versions des composants :

http://jira.atlassian.com/browse/JRA-3501

Answer 5

Créez un composant pour chaque module principal, ou peut-être même pour chaque niveau du système (par exemple, Backend, Frontend). Je n'irais pas en dessous de la granularité du module. Vous pouvez ajouter des composants pour les activités de soutien, telles que BA, Testing (en accord avec mdoar)... Les composants sont orthogonaux aux versions/release.