JIRA: fermer ou résoudre?
Vous pouvez rouvrir un problème résolu et un problème fermé dans JIRA. Quelle est la différence pratique? (outre le fait de demander des autorisations différentes pour résoudre/résoudre les problèmes, par exemple si le contrôle qualité est impliqué)
Notre équipe a des divergences d’opinion sur la question de savoir s’il faut résoudre ou fermer, et je voudrais pointer vers une autorité et lui dire "nous devrions le faire de cette façon".
Le workflow du problème typique est la personne travaillant sur le bogue qui le résout, et la personne qui a ouvert le bogue est celle qui décide si la résolution est acceptable. Si c'est le cas, ils le ferment. Sinon, ils rouvrent le bogue pour une discussion/un travail/une discussion plus poussés.
L'exception à cette règle est lorsqu'un bogue est un doublon. Souvent, la personne qui travaille sur le bogue se rend compte qu'il s'agit d'un doublon et peut ensuite le fermer lui-même en tant que duplicata. Ou peut-être qu'ils résolvent le problème en double, l'ouvreur accepte et le ferme.
IIRC, JIRA a un flux de travail assez flexible (même s’il est compliqué). Vous pouvez donc configurer n’importe quel processus que vous jugez approprié pour votre équipe et les groupes qui soumettront des problèmes.
Edit: Je réalise que je n'ai pas réellement abordé la réouverture des problèmes fermés. D'après mon expérience, cela n'arrive pas souvent parce que les gens recherchent dans le système des problèmes les bogues existants qui présentent le même comportement que ce qu'ils voient. Et si vous êtes chanceux, les bogues s’ouvrent souvent sans enquête sur les problèmes existants.
Cela étant dit, un spécialiste de l'assurance de la qualité ou du terrain ira "Je me souviens de ce bogue. Bon sang, ils ont dit qu'il était réparé" quelque temps après que le propriétaire initial l'ait fermé. À ce stade, ils peuvent rouvrir l'ancien bogue ou en créer un nouveau et créer un lien vers l'original. Ma préférence est qu'il y ait un nouveau bogue et un lien plutôt que de rouvrir. La raison en est que le "nouveau" problème peut présenter le même comportement, mais peut avoir une cause complètement différente. C'est souvent le cas lorsque des messages de journal d'erreur vraiment génériques sont crachés.
- Résolu est généralement "Prêt pour le test"
- Fermé est généralement "ça a marché"
Vous pouvez également consulter cet article de blog pour plus de détails sur la manière dont JIRA utilise les états Resolved/Closed et le champ Resolution du système.
Nous le faisons, vis-à-vis de nos clients externes, lorsque nous réglons l’incident au client facturé (cela peut tout aussi bien être un problème qu’une tâche SED), jusqu’alors, l’incident reste tout simplement résolu.
Je crois que vous ne devriez pas rouvrir un incident fermé, celui-là étant les livres, alors qu'un incident résolu vous pouvez rouvrir.
À propos, il serait sage de lire ce que ITIL dit à ce sujet. Comme dit sur cette page :
_ {Règles pour la réouverture d'incidents}
En dépit de tous les soins appropriés, il peut arriver que des incidents se reproduisent même s’ils ont été officiellement clôturés. Il est donc sage de disposer de règles prédéfinies indiquant si et à quel moment un incident peut être rouvert. Il Par exemple, il peut être logique de convenir que si l'incident se reproduit dans un jour ouvrable, il peut être rouvert - mais au-delà de ce point, un nouvel incident doit être signalé, mais lié au (x) incident (s) précédent (s). .Le seuil/les règles de temps exacts peuvent varier d’une organisation à l’autre - mais des règles claires doivent être convenues, consignées et documentées, et des directives doivent être données à tout le personnel du centre de services afin que l’uniformité soit appliquée.
En règle générale, vous ne pouvez ni éditer, ni vous connecter à un problème fermé, et vous devez en tenir compte.
Mon conseil est: seulement des testeurs Fermer
Habituellement, Dev/Resource devrait résoudre et seul le journaliste peut fermer.
Je pense que CLOSED est un statut et RESOLVED est un état.
- Un problème peut être résolu comme TERMINÉ, NON RÉPÉTIBLE, ou ANNULÉ (ou tout statut que vous choisissez ... défini dans les règles de workflow).
- La résolution peut être utilisée assez facilement aussi dans JQL ... par exemple. PROJECT = DBA et RESOLUTION est VIDE
- RÉSOLU Les problèmes apparaissent également avec des caractères barrés lorsqu'ils sont énumérés dans d'autres commentaires ou liens.
- Au niveau de la base de données, RESOLUTION DATE est un champ séparé qui apparaît également dans la section DATE d'un problème.
Je pense qu’il existe également un grand nombre de rapports sur les problèmes résolus.
En bout de ligne ... RÉSOLU peut signifier «non plus actif» pour un certain nombre de raisons et il dispose de fonctionnalités spéciales dans JIRA. FERME est juste un autre statut.
