Une user story n’est pas une liste de tâches techniques

Je vois encore des user stories qui contiennent, à chaque fois, les mêmes tâches: coder, tester, écrire les détails techniques de l’implémentation. Parfois, c’est le tech lead qui y consigne la façon dont la chose doit être faite. Ce ne sont pas des user stories, et c’est une pratique à bannir définitivement.

Une user story décrit une valeur pour un utilisateur. Une tâche qui dit «coder» ou «tester» n’apporte aucune valeur métier; elle décrit le métier de développeur lui-même. Développer est un métier, voire un art, qui regroupe plusieurs savoir-faire: concevoir, tester, coder. S’il faut le rappeler dans chaque story, c’est qu’il y a un problème de maturité, chez l’équipe ou chez ceux qui la managent, pas un problème de story.

Jira n’est pas un outil de développement

Demander à un tech lead, ou lui permettre, d’y décrire l’implémentation attendue, c’est déplacer la conception vers un formulaire que personne ne relira, et priver l’équipe du moment où elle aurait dû réfléchir ensemble. C’est une vraie perte de temps et d’effort pour tout le monde: pour celui qui écrit, pour ceux qui exécutent sans comprendre, et pour ceux qui maintiendront le résultat.

Si l’objectif est de faire monter l’équipe en compétence technique, il existe un moyen qui marche: le pair programming, ou le mob programming. Le savoir-faire se transmet en travaillant ensemble sur le vrai code, pas dans le champ description d’un ticket.

Une story bien écrite dit quoi et pourquoi.

Le comment appartient à l’équipe, au moment où elle s’en saisit. C’est là que le métier s’exerce, et c’est là qu’il s’apprend