Meilleures pratiques d'utilisation des composants dans les projets Jira
Nous utilisons beaucoup Jira dans notre développement quotidien. J'aimerais voir s'il existe des meilleures 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 plus fins sont préférés par votre équipe?
Les composants sont comme de 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, au moins jusqu'à ce que le nombre de projets devienne très important.
Évitez également l'utilisation d'un composant nommé "Divers" ou "Autre". Ils ont tendance à devenir des dépotoirs de problèmes dont personne ne se soucie.
Le plus important sur les composants doit être sans ambiguïté et pas trop. Dans notre équipe maintenant, nous migrons 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 l'équipe (infra, backend, GUI) - cela aide les gars de BA à acheminer la demande vers le gestionnaire d'équipe DEV approprié assigné en tant que chef de composant.
- le deuxième niveau est le processus réel (au sens Unix). C'est une définition très claire. Dans le cas où un problème est mappé sur plusieurs processus, nous l'attribuons à l'un d'entre eux (BTW, GreenHopper n'autorise pas les composants à plusieurs feuilles, mais JIRA simple le permet). Cette opération est effectuée par le gestionnaire DEV.
- le troisième niveau est facultatif et rarement utilisé, dénotant un sous-système dans le processus. Nous l'utilisons lorsqu'une partie considérable des problèmes sont liés à une partie bien définie du code et nous voulons les suivre séparément. Cela est généralement effectué par le développeur travaillant sur le problème.
Pour qu'un tel raffinement progressif fonctionne, vous devez avoir une idée de qui attribue à quel composant et qui traite les problèmes qui lui sont attribués. Ce dernier est désigné par Component Lead, le premier n'est pas explicitement pris en charge par JIRA (ou nous pourrions dire que les BA ne voient que leurs composants, les gestionnaires DEV, uniquement leurs sous-composants + tous les BA, etc.)
Je ferais correspondre les composants avec vos modules/artefacts/pots, de sorte que chaque problème puisse appartenir à un module particulier (bien qu'il puisse également avoir des dépendances/relations avec d'autres).
Si vous pouvez présenter des arguments solides pour une gestion des problèmes plus fine que le niveau du module, demandez-vous pourquoi vous ne sépareriez pas également le module associé.
Cette correspondance 1-1 vous aide à clarifier votre calendrier de publication, vous pouvez facilement identifier les problèmes rencontrés par la version X de votre projet et les modules sur lesquels concentrer vos efforts. Il permet également de simplifier les associations entre Jira, le système de génération 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.
Depuis 4.2.4, il n'est pas possible de versionner des composants, seulement des projets. Gardez cela à l'esprit si vous souhaitez utiliser la fonctionnalité de feuille de route.
Il y a une demande de longue date (7+ ans) pour ajouter des versions pour les composants:
Créez un composant pour chaque module principal, ou peut-être même un niveau système (par exemple Backend, Frontend). Je n'irais pas en dessous de la granularité au niveau du module. Vous pouvez ajouter des composants pour les activités de support, tels que BA, Testing (en accord avec mdoar) ... Les composants sont orthogonaux aux versions/versions
J'ai maintenant une autre version des composants.
Avec les clients, je fais référence au champ Composants comme:
A multiselect field that's useful for automatically assigning issues. Each of the things in this field has a potential assignee associated with it.
et puis je dis:
If you don't care about automatic assignment, just treat the components field as a convenient system field.
Donc, pour répondre à nouveau à la question d'origine, demandez-vous si vous attribuez des problèmes par équipe ou par niveau précis auquel vous avez fait référence?
Probablement l'ancien.
JIRA est conçu pour que chaque composant du projet ait le même ensemble de numéros de version, donc si vous voulez que vos composants aient des numéros de version indépendants, vous devez soit configurer un projet différent pour chaque composant, soit utiliser un plugin développé par mes soins qui permet un composant spécifique numéros de version et en même temps permet le regroupement des composants dans un bundle. Le plugin est "Composant/Sous-composants/Versions de bundle pour JIRA" et disponible sur Atlassian Marketplace. Plus d'informations sont disponibles sur atlassian page d'aide des plugins . Une autre option consiste à forcer chaque composant de l'équipe à avoir le même ensemble de numéros de version. Sinon, il est très difficile de sélectionner les numéros de version corrects pour les composants.
Nous utilisons une hiérarchie de composants à 2 niveaux (grâce à greenhopper ...) - Thèmes et Epics. La construction dans Greenhopper Themes and Epics ne nous permet pas d'agréger et de rapporter comme nous le voulons, et cela fait assez bien l'affaire.