Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

La liste des stories que nous réalisons durant le sprint doit être considéré comme notre contrat de fourniture : voilà ce que nous avons fait, voici où nous en sommes. L’un des mécanismes essentiels en contexte agile est le feedback. La simple déclaration énoncée ci-dessus est sans valeur si je suis dans l’incapacité de la constater et de donner du feedback dessus. Et pour donner ce feedback, il nous faut la connaissance de l’acteur concerné.

Régulièrement, hélas, je vois arriver ces fameuses « user stories techniques ». La justification que j’obtiens alors est : non mais là c’est technique, on a besoin de le faire ! J’ai alors droit à des merveilles du genre :

• Stocker les donner fournisseur.

Ne souriez pas, c’est très fréquent. Mon exemple est d’ailleurs loin d’être le pire. Je vous épargne le classique « développer la couche de persistance »…

Un second effet de ces user stories techniques peut aussi se constater en planning meeting

La user story technique et le planning meeting

C’est donc conjointement à des user stories plus classiques que ces « stories techniques » se présentent en planning meeting.

Mais si les user stories classiques sont traitées assez efficacement, leurs homologues techniques necessitent environ 4 fois plus de temps (bien que je ne l’ai pas mesuré précisément).  Sont en cause :

• Une difficulté à cadrer la solution, car la finalité n’est pas claire. Il manque le contexte.
• Impuissance à déterminer le périmètre de la story. Quand celle-ci sera-t-elle terminée ? Quels sont les tests d’acceptation ?

Même avec 4 fois plus de temps, le découpage en tâches et l’estimation s’avèrent moins satisfaisants. Même si vous n’êtes pas fan du découpage en tâches et des estimations, il n’en reste pas moins que ceux-ci s’avèrent symptomatiques de la compréhension de l’item.

Mais voilà : c’est du travail technique, ce n’est pas fonctionnel. Est-ce vraiment le cas ?

Remettre la story technique dans son contexte

Basculer de la user story technique à leurs équivalents fonctionnels est moins difficile qu’il n’y parait de prime abord. Il s’agit surtout de se poser les bonnes questions :

• Pourquoi a-t-on besoin de faire cela ? Que se passe-t-il, ou qu’est-ce qui se passe mal, si on ne fait pas cela ?
• Dans quel contexte cela sera-t-il utilisé ?
• D’un point de vue externe, comment saurais-je que le système possède cette propriété ou cette capacité supplémentaire ?

Cette liste n’est pas exhaustive, et vous pourrez facilement imaginer d’autres questions de la même eau. Le but est simple : remettre l’item technique dans un contexte fonctionnel. Dans le cas que nous avons énoncé plus haut (stocker les données fournisseur), à la question « qu’est-ce qui se passe mal si on ne fait pas cela », la réponse est : on ne peut pas communiquer ces informations si le système s’arrête entre leur acquisition et la transmission. Je pourrais vous le souffler à l’oreille, mais cette réponse nous permet assez facilement d’en déduire une user story fonctionnelle…

Et mon refactoring, alors ?

Eh bien c’est vrai, le refactoring, ce n’est pas fonctionnel (apparemment).  Doit-on le rejetter, l’ignorer ? Bref, le développeur doit-il se débrouiller et caser ça à l’heure du déjeuner ?

Bien sûr que non ! Mais ce n’est pas non plus une raison pour produire une « user story technique ».

N’oubliez pas que le mainteneur du système (donc le développeur) est aussi un utilisateur du système. Tout comme le sont les ops et les exploitants chargés de déployer et d’assurer le bon fonctionnement du système en production, soit dit en passant. En tant que mainteneur, vous pouvez demander à rendre un type d’évolution plus facile, de pouvoir prendre en charge de nouveaux périphériques ou de nouveaux algorithmes plus efficacement. Vous pouvez souhaiter que les évolutions ou les corrections soient localisées à un seul composant.

Bref, vous pouvez exprimer des besoins qui une fois remis dans le contexte d’un objectif, peuvent être discutés avec le Product Owner. Et vous pouvez même produire des critères d’acceptation ! Certes, ce ne seront pas des tests d’acceptation (on reste iso-fonctionnel, n’est-ce pas ?), mais on peut évaluer l’atteinte de ces critères ne serait-ce que qualitativement. N’oubliez-pas :

Tout ce qui a besoin d’être mesuré peut être mesuré d’une manière qui est de toute manière supérieure à pas de mesure du tout !

Maintenant, c’est trop gros !

Vous avez basculé dans l’usage ? Bien. Et maintenant vous vous rendez compte que votre story a pris de l’embonpoint, car elle intègre maintenant le contexte d’usage ! Je vous entend : c’est justement pour cela que vous aviez fait une story technique, pour que ce ne soit pas trop gros.

Il faut alors passer à la cure d’amaigrissement. Mais pas en réalisant un morceau du mécanisme après l’autre, en faisant des tranches plus fines de ce mécanisme.

Faire des tranches fines dépasse le cadre de ce post. Cela reste une compétence clef à acquerir pour le développement agile, en particulier pour le Product Owner. Je vous recommande à ce titre l’exercice du Carpaccio pour aiguiser votre savoir-faire.

A emporter

Peut-être un jour devrais-je faire face à une story technique que je ne saurais pas mettre dans un contexte d’utilisation. Pour l’instant tout va bien. Si vous faites face à cette difficulté, tentez l’exercice !

Reprenez les questions évoquées dans ce post. Au besoin, enrichissez-les des vôtres. Reprenez vos User Stories techniques et mettez-vous à 2 ou 3 autour d’une table et basculez votre story technique dans l’usage qui en est fait.