Le réflexe
“Ticket fini. Je prends quoi après ?”
Le travail arrive prédécoupé. Tu le traites, tu le rends. Savoir si le découpage était bon, c’est la question de quelqu’un d’autre.
Le réflexe builder
“Ticket fini. En le faisant, j’ai vu que la cause est une couche en dessous. Voilà ce que je changerais.”
Pourquoi
Celui qui écrit un ticket l’écrit depuis l’extérieur du code. Celui qui le fait passe deux jours à l’intérieur et apprend des choses que l’auteur n’avait aucun moyen de connaître. Cette connaissance est nette pendant environ une journée, puis elle se dissout dans le sentiment général que le système est un peu bizarre à cet endroit.
Si elle ne remonte pas, le ticket suivant porte le même angle mort, et deux trimestres après, l’équipe redécoupe le même problème de la même mauvaise façon, avec un autre numéro dessus.
“Le formulaire ne s’affiche pas sur mobile” est une tâche. “Personne sur mobile ne s’est inscrit depuis trois semaines” est un problème. L’un change une ligne de code. L’autre change ce sur quoi l’équipe travaille ensuite, et sur un marché où le téléphone est l’ordinateur, il change ce qu’est l’entreprise.
Tu fais le ticket d’abord, toujours. La trouvaille voyage avec la livraison, elle ne la remplace jamais. Rends une analyse à la place d’un code qui marche et la prochaine sera lue comme une manœuvre.
À essayer
Deux lignes dans le ticket, avant de le fermer.
Ce que ça m’a appris sur le vrai problème : … Ce que je ferais autrement en repartant de zéro : …
Personne ne les a demandées. C’est le principe.
À discuter
Quelqu’un ici a déjà découvert, en le faisant, que la tâche demandée n’était pas la bonne. Il l’a dit à qui, et qu’est-ce que ça a changé ?