« User story » : l'explication simple, ou comment découper un produit en étapes

On vous a peut-être dit que votre projet serait découpé en « user stories ». Le mot vient du métier, il ne vous appartient pas, et il cache une idée que vous pratiquez déjà quand vous confiez un chantier : une étape se décrit par ce qu'on pourra vérifier à la fin.

Une user story, en explication simple, est une étape de construction décrite du point de vue de la personne qui utilisera le logiciel, avec la liste de ce qu'on pourra vérifier une fois l'étape finie. Nous disons « étape » dans la suite de cet article, et dans notre produit aussi, parce que le mot anglais n'apporte rien à celui qui commande un logiciel.

Une étape, c'est une phrase et une preuve

Prenez un outil de gestion d'atelier. « Le client reçoit un message quand sa réparation est prête » est une étape. Elle tient en une phrase, elle nomme la personne concernée, et surtout elle vient avec ce qui prouve qu'elle est faite : le message part au bon moment, il contient le bon numéro de dossier, il ne part pas deux fois, et il ne part pas du tout si le client a demandé à ne rien recevoir. Cette liste de preuves est la partie qui compte. Sans elle, l'étape est un vœu, et la fin d'un chantier devient une négociation où chacun défend sa lecture de la phrase de départ.

Pourquoi le découpage change ce que vous voyez

Un projet livré en un seul bloc vous laisse sans nouvelles jusqu'au jour où on vous montre tout. À ce moment-là, corriger coûte cher, parce que le reste a été construit par-dessus. Un projet découpé vous rend une chose vérifiable à intervalles courts. Vous ne regardez pas du code, vous regardez un comportement : le message part-il, la facture s'imprime-t-elle avec les bonnes mentions, la remise fidélité s'applique-t-elle sur le bon montant. Le découpage est votre seul moyen de garder la main sans lire une ligne technique, et c'est aussi ce qui rend lisible un cahier des charges pour qui n'est pas du métier.

Qui découpe, qui construit, qui vérifie

Chez nous, trois agents se partagent ce travail et ne se marchent pas dessus. Marcel découpe : il prend le cahier des charges que vous avez validé et en tire une suite d'étapes, chacune avec sa liste de preuves. Amélie construit l'étape. Félix la vérifie, et il a le dernier mot : tant que les preuves ne passent pas, l'étape ne compte pas comme faite. La séparation a une raison : celle qui écrit et celle qui contrôle ne peuvent pas être la même, sinon le contrôle épouse le travail. Nous avons vu ce que donne l'inverse quand tout est vert et que c'est pourtant faux.

L'ordre est notre règle la plus stricte : les tests s'écrivent avant le code. Félix pose d'abord la liste de ce que l'étape devra prouver, et cette liste échoue, puisque rien n'existe encore. Amélie construit ensuite jusqu'à ce qu'elle passe. Écrit dans cet ordre, un test décrit ce que vous vouliez ; écrit après, il décrit ce que la machine a produit, et il ne vous protège de rien. Nous avons détaillé ce choix et ses coûts dans le test d'abord, imposé aux agents.

Le piège de l'étape trop grosse

« Gérer les clients » est un chapitre, de la taille d'un trimestre. Personne ne sait quand il finit, donc personne ne sait s'il est fini. Le signe est facile à repérer : si vous ne pouvez pas écrire en trois lignes ce que vous irez vérifier à l'écran, l'étape est trop grosse et doit se couper. À l'inverse, une étape qui ne produit rien d'observable pour un humain n'a pas sa place seule dans une liste que vous validez. Entre les deux, le bon calibre est celui qui vous permet de dire « ça me va » ou « non, il manque ceci » en regardant le résultat, sans qu'on ait besoin de vous traduire quoi que ce soit.

Le mot qui reste le vôtre

Chaque étape construite vous revient comme une proposition, pas comme un fait accompli. Vous dites « Ça me va », et la suivante démarre. Vous dites non, et elle repart en correction. Cette porte existe à chaque document et à chaque étape, ce qui ralentit un peu et évite beaucoup, pour les raisons que nous avons posées dans « Ça me va » : la validation humaine.

Découper votre projet ce soir

Prenez une feuille et écrivez dix phrases commençant par un nom de personne : le client, la secrétaire, le comptable, vous. Chaque phrase dit ce que cette personne fait, ou reçoit, dans votre futur logiciel. Sous chacune, écrivez deux lignes de preuve : ce que vous irez regarder pour dire que c'est bon. Si une phrase résiste, vous venez de trouver la partie de votre métier que personne n'a encore écrite, et c'est celle qui aurait fait dérailler le chantier plus tard.