Et désolée pour cette question particulière qui pourra être jugée comme déplacée, car ça ne concerne pas Scrum mais les « bonnes pratiques » en général.
Dans le cas d’un ticket déjà déployé en production, si le feedback d’un client est mauvais (malentendu sur les attendus, par exemple), et qu’il faut retravailler la fonctionnalité, est-ce qu’il vaut mieux rouvrir le ticket, ou est-ce qu’il vaut mieux créer un nouveau ticket?
Dans les deux cas, pourquoi?
Je veux pas influencer les réponses, je préfère garder mon avis pour moi, dans un premier temps.
C’est à la fois de l’humour oui, mais aussi une vrai question.
En partant du principe que la solution codée ne convient pas, est il plus facile de modifier (et j’insiste, ce n’est PAS (!!!) du refactoring) le code, avec toute la dette induite, ou de recréer de zéro un nouveau code avec les connaissances acquises grâce à la première itération ?
En lisant ton message, je comprends que « rouvrir » veut dire que le ticket a été clôturé et qu’il a donc respecté la DoD donc il est terminé.
Je vais partir de ce postulat en tout cas mais si ce n’est pas le cas corrige moi.
Côté « pratiques », dans les équipes avec qui j’ai pu travailler, un ticket en production était Done, et on ne rouvre pas un ticket Done. Il reflète l’état du produit à date : la feature est livrée, qu’il y ait malentendu ou non.
Un malentendu est donc vu comme un feedback, une info prise par l’équipe qui va donc créer de nouveaux items (tickets) pour retravailler la fonctionnalité.
Dans le cas de rouverture d’un ticket « Done »…, sans parler de « bonne ou mauvaise pratique » je n’arrive pas à voir ce que ça apporte en fait. Généralement ça crée plus de complexité pour l’équipe qui ne sait plus ce qui est d’actualité ou pas, ce qui est à faire ou défaire… Sans détailler, on perd en simplicité et tout ce qui en découle.
Là il va falloir commencer par définir ce qu’est un ticket dans ta gestion opérationnelle.
Si tu veux on peut parler de ce qu’on fait d’un PBI en cas de feedback utilisateur.
Mais ce n’est pas exactement le même sujet, car un PBI n’a pas de statut « ouvert » ou « fermé ».
Un ticket c’est spécifique à la gestion opérationnelle de ton organisation.
Donc c’est à l’organisation de définir comment vous gérer les tickets.
Ma réponse est purement logistique on crée un nouveau ticket et on y parle du précédent.
Le précédent ticket est fermé et il est sûrement dans la tête de plusieurs personnes.
À nouveau ticket démontre bien qu’il y a une nouvelle demande et la référence au précédent permet dans récupérer l’information facilement.
Dans la pratique de la réouverture de ticket j’ai connu pendant une belle période l’expérience d’un responsable qui fermait les tickets ré-ouverts juste en se disant bah on l’a fini ce truc là
XP => à la fin du sprint
Soit c’est DONE et on merge, et plus besoin de la branche
Soit c’est pas DONE et on jette, on recommencera tout si le ticket est repris dans un autre sprint.
"Réouvrir un ticket " n’a pas de sens.
On fait un ticket qui décrit la situation actuelle (le code a visiblement été considéré comme DONE et déployé en prod.) et on décrit la situation souhaitée.
Les commits sont dans la branche de prod, et peuvent servir à relire l’histoire.
Mais c’est en prod, l’histoire est écrite.
