Ce que les tickets font mal

Les tickets suivent le travail. Ils sont terribles pour stocker les connaissances. Un ticket qui dit « migrer le service d'authentification vers le nouveau format de jeton » capture ce qui doit être fait et pourquoi — mais la décision architecturale qui en résulte, la spécification du format de jeton et la stratégie de migration n'ont pas leur place dans le ticket. Ils appartiennent à une documentation qui survit au cycle de vie du ticket.

Le mode d'échec est familier : une équipe utilise les tickets comme base de connaissances, et six mois plus tard, trouver la décision de migration d'authentification nécessite de fouiller dans 2 000 tickets fermés avec des mots-clés qui correspondent à des dizaines de résultats non liés. La décision est là quelque part — enfouie dans une description, un commentaire ou une pièce jointe — mais elle n'est pas trouvable dans un délai raisonnable.

Les tickets sont éphémères par conception. Ils représentent une unité de travail avec un début, une fin et un statut. Les décisions architecturales, les contrats d'API, les procédures de runbook et les guides d'intégration sont des connaissances persistantes qui nécessitent un emplacement persistant : un wiki, un répertoire /docs dans le dépôt, un fichier ADR (Architecture Decision Record). Le ticket peut pointer vers le document. Le document ne devrait pas vivre à l'intérieur du ticket.

Un fil de 30 commentaires sur un ticket est une conversation qui aurait dû avoir lieu ailleurs. Les tickets sont des outils de coordination — ils répondent à « que faut-il faire ? » et « est-ce terminé ? ». Ils ne sont pas le bon médium pour les débats de conception, les négociations d'exigences ou les sessions de dépannage.

Quand un ticket devient un fil de discussion, trois choses tournent mal. Premièrement, le rapport signal/bruit chute : les exigences réelles sont enfouies entre les mises à jour de statut, les questions tangentielles et les pings « des nouvelles là-dessus ? ». Deuxièmement, la conversation n'est pas visible pour les personnes qui ne suivent pas ce ticket — une décision de conception prise dans un commentaire de ticket n'apparaît pas dans le canal Slack de l'équipe, les notes de réunion ou la documentation. Troisièmement, les métadonnées du ticket (statut, responsable, date d'échéance) se déconnectent de la réalité d'une portée encore en évolution.

La discussion appartient aux outils de discussion : fils Slack avec un résumé publié dans le ticket, documents de conception liés depuis le ticket, ou un appel de 15 minutes avec des notes capturées dans la description. Le ticket est la page d'accueil d'un élément de travail, pas la transcription de chaque conversation à son sujet.

Un backlog n'est pas un stationnement pour les idées — mais la plupart des équipes le traitent comme tel. Chaque demande de fonctionnalité, bogue mineur, « ce serait bien d'avoir » et « on devrait probablement faire ça un jour » obtient un ticket, et ce ticket reste intact pendant des mois. Le backlog grossit. Personne ne l'élague. Finalement, vous avez 800 tickets et aucun moyen de distinguer les 30 qui comptent des 770 qui ne comptent pas.

Les backlogs périmés entraînent des coûts réels. Les développeurs perdent du temps à faire défiler des tickets morts lors de la planification de sprint. Les nouveaux membres de l'équipe ne peuvent pas distinguer les tickets actuels des fossiles de deux pivots produit passés. Les recherches retournent du bruit. Le backlog devient un monument culpabilisant au travail que l'équipe ne fera jamais — et chaque regard porté sur lui mine la confiance dans le processus de planification.

L'hygiène du backlog est une discipline, pas un nettoyage ponctuel. Une cadence saine : une fois par mois, examinez chaque ticket de plus de 90 jours. S'il n'a pas été priorisé en trois mois, il n'est soit pas assez important pour être fait, soit pas assez bien défini pour être estimé. Fermez-le. S'il compte, il reviendra — et quand il reviendra, ce sera avec un contexte frais et des priorités actuelles.

L'instinct est de garder les tickets ouverts « au cas où ». Cet instinct est faux. Un ticket fermé n'est pas supprimé — il est consultable, peut être lié et rouvert. Le fermer signifie simplement que l'équipe est honnête sur ce qui est réellement dans la portée. Un backlog de 50 tickets qui reflète les vraies priorités est infiniment plus utile qu'un backlog de 800 tickets qui reflète chaque idée que quiconque a jamais eue.