Anatomie d'un bon ticket

La plupart des tickets sont mauvais. Ce sont des titres vagues — « corriger bug connexion », « mettre à jour tableau de bord », « travail backend » — sans description, sans critères d'acceptation et sans contexte pour quiconque autre que la personne qui les a écrits. Ces tickets créent l'illusion d'un suivi tout en ne suivant rien d'utile.

Un bon ticket comporte trois parties :

• Titre comme résultat. Le titre indique ce qui sera vrai une fois le travail terminé, et non quelle activité aura lieu. « Les utilisateurs peuvent réinitialiser leur mot de passe par courriel » est un résultat. « Travailler sur les trucs de mot de passe » est une activité. La différence compte parce que les titres orientés résultat sont testables — vous pouvez regarder le travail terminé et demander « est-ce vrai? »
• Description comme pourquoi. La description explique pourquoi ce travail est important et fournit suffisamment de contexte pour que quelqu'un qui n'est pas familier puisse comprendre la décision. Pas un roman — deux ou trois phrases qui répondent à « pourquoi maintenant? » et « quel est l'impact sur l'utilisateur? »
• Critères d'acceptation comme quoi. Une courte liste de conditions concrètes et testables qui définissent « terminé ». Pas « ça devrait bien fonctionner » — mais « le point de terminaison retourne un 200 avec un jeton valide, un 401 avec des identifiants expirés et un 429 après 5 tentatives échouées en 60 secondes ».

Le test d'un bon ticket est le test de prise en charge : un développeur qui n'était pas à la réunion où cela a été discuté pourrait-il le prendre et le livrer sans poser de questions de clarification? Si la réponse est non, le ticket n'est pas terminé — c'est un espace réservé.

Les critères d'acceptation sont la partie la plus souvent omise d'un ticket et la plus coûteuse à omettre. Sans eux, « terminé » signifie ce que le développeur qui y a travaillé pense que cela signifie — ce qui peut ne pas correspondre à ce que le chef de produit attendait, à ce contre quoi l'AQ testera ou à ce dont le client a réellement besoin.

Les bons critères d'acceptation sont concrets et testables. « La recherche devrait être rapide » n'est pas un critère d'acceptation — c'est un espoir. « Les résultats de recherche sont retournés en moins de 200 ms pour des requêtes allant jusqu'à 1 000 enregistrements » est testable. « Le formulaire devrait gérer les erreurs avec élégance » est vague. « Le formulaire affiche un message d'erreur en ligne rouge lorsque le champ courriel est vide et que l'utilisateur clique sur Soumettre » est suffisamment précis pour construire et vérifier.

Les critères d'acceptation devraient être convenus avant le début du travail, et non écrits après. Lorsqu'un développeur et un chef de produit s'alignent sur les critères avant la première ligne de code, ils s'alignent sur la portée. Sans cet alignement, le développeur construit ce qu'il a compris, le chef de produit s'attendait à quelque chose de différent et le ticket revient — coûtant du temps aux deux et érodant la confiance. Écrire les critères d'acceptation à l'avance prend 10 minutes. Retravailler une fonctionnalité mal comprise prend des jours.

La description est la source de vérité. Les commentaires sont la conversation à ce sujet. Les mélanger est la façon dont les tickets deviennent illisibles.

La description devrait contenir tout ce dont quelqu'un a besoin pour comprendre le travail : le contexte, les exigences, les critères d'acceptation et tous les liens pertinents. Elle est écrite une fois (et mise à jour si la portée change). C'est la partie que vous lisez en premier lorsque vous prenez un ticket, et elle devrait répondre à vos questions sans vous obliger à faire défiler 47 commentaires.

Les commentaires sont pour la discussion qui se produit pendant le travail : questions de clarification, négociations de portée, mises à jour de statut, rétroaction de révision. Les commentaires sont en ajout seulement et chronologiques — ils capturent la conversation, pas la conclusion. Lorsqu'un fil de commentaires résout une question qui change les exigences, la réponse retourne dans la description. La description est modifiée; le commentaire reste comme piste d'audit de la façon dont la décision a été prise.

Les équipes qui déversent tout dans les commentaires se retrouvent avec des tickets où les exigences réelles sont enfouies dans le commentaire nº 23, coincées entre une mise à jour de statut et une réaction emoji. Le développeur qui prend le ticket doit lire tout le fil pour reconstruire l'état actuel. Ce n'est pas de la coordination — c'est de l'archéologie.