Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Tout est incroyablement plus simple avec les User Stories. L’utilisateur évoque une possibilité ? Hop ! Une User Story ! Une idée autour d’un café ? En voilà une autre !

Plus besoin de gros document, simplement de me balader avec mon calepin sous le bras ! Hélas, cette simplicité est trompeuse. En nous débarrassant d’un artéfact lourd et compliqué, j’ai nommé le célébrissime IEEE 830-1998, les créateurs des User Stories voulaient laisser la place au vrai travail de spécification : l’observation du terrain, la collecte des informations, les conversations constructives, l’exploration des alternatives. Décider ce que l’on doit faire est souvent un véritable travail d’abnégation, ou du moins il devrait l’être.

La simplicité du formalisme des User Stories est trop souvent interprété comme une licence à la superficialité. Pourtant le corpus de connaissance existe, encore faut-il aller le chercher !

La littérature traitant des spécifications est riche de dizaines d’années de publication d’excellente valeur. Oui, d’excellente valeur. Tout cela a souvent été interprété à tord au sein des projets classiques comme la nécessité d’écrire de lourds et nombreux documents se paraphrasant entre-eux (et souvent eux-mêmes).

La spécification agile a fait table rase du passé et de ses enseignements. Table rase d’un formalisme qui a fini par prendre le pas sur le contenu.

Mais est-ce vraiment le cas ?

Template Zombies

Dans l’ouvrage qui leur sont consacrés [Cohn04], Mike Cohn nous propose une formulation aujourd’hui devenu le standard de rédaction des User Stories.

“En tant que xxx, je veux yyy, afin de zzz”

Le template a comme vertu première d’obliger à capturer les éléments importants. C’est bien le cas ici. Cette approche est surtout nécessaire aux débutants comme le relèvent Tom DeMarco et ses co-auteurs [DeMarco+08]. Mais elle vient aussi avec un travers important, où la forme prends le pas sur le fond : c’est le « template zombie ». Gojko Adzic nous en donne un bon exemple [Adzic13] :

“As a user, I want to register in order to log in”

Ah oui ! Etre obligé de me logger et devoir m’enregistrer pour ce faire, j’ai vraiment hâte… D’autres sont des tâches afférentes au travail de développement. Par exemple :

“En tant que développeur, je veux automatiser le processus de déploiement, afin de mettre à disposition l’application plus rapidement et plus souvent”

Bien sûr, cela doit certainement être fait, mais qu’est-ce que cela a à voir avec le produit ? Cela a surtout à voir avec le dogmatisme qui veut que tout ce qui figure dans le plan de sprint soit sous forme de User Story. Si votre motivation est d’être conforme au processus, félicitations : vous faites un projet non-agile en utilisant des techniques agiles !

Dans le même ordre d’idées, nous pourrions évoquer les « stories techniques », mais j’ai déjà écrit sur ce sujet il y a quelques temps.

On peut accuser une certaine paresse, ou une indolence à donner un véritable sens aux user stories. Mais il n’y a pas que cela.

More rules, more pain…

On dit qu’une story doit être petite, de manière à tenir dans une itération ou à être une « survivable experiment » [Adzic+14]. De manière à avoir du feedback plus rapidement aussi, bien sûr, l’un des moteurs de l’agilité. Mais plus de focus, c’est aussi moins de contexte et moins d’invitation à aller le chercher. C’est ainsi que l’on finit par se retrouver avec des User Stories de ce genre :

“En tant qu’analyste financier, je veux un export Excel, afin de manipuler les données comme je le souhaite”

Autant pour la qualité de l’analyse. Et ce n’est pas fini. Nos stories doivent aussi être INVEST. Une bonne idée de manière générale, mais que dois-je faire si certaines de mes stories ne sont effectivement pas indépendantes ? Est-ce si grave ?

Que se passe-t-il si ma User Story consiste à explorer des options ? Dois-je rejeter cette user story car justement, je ne serais pas capable de l’estimer … ou même de la tester ?

L’approche agile doit en principe nous aider à faire face à l’inconnu ou aux idées novatrices. Au lieu de cela, nous nous engageons gaillardement dans une voie qui cherche à éliminer tout risque, à prétexter que notre story n’est « pas prête », bref à aseptiser gentiment notre beau projet.

Alors, doit-on en finir avec ces User Stories ?

Dans son livre, Jeff Patton [Patton14] nous rappelle la véritable nature d’une spécification : créer de la compréhension partagée. Les «  3 C » (carte, conversation, confirmation) nous rappellent que la carte est l’élément le moins important, simplement un « jeton pour une conversation ». Le template de des User Stories a insidieusement déplacé notre attention sur les cartes, et plus précisément l’élément situé au milieu. Ce dernier représente la solution, ironiquement c’est celui qui devrait constituer la marge de négociation du « INVEST » !

Au template, je préfère les 3 questions que nous suggère Jeff Patton (encore lui) : Qui ? Pourquoi ? Quoi ? Et précisément dans cet ordre, avec le « quoi » à la fin !

Enfin, si les User Story remettent l’église au milieu du village en redonnant aux interactions l’importance qui leur est dû, elles ne doivent pas occulter la nécessité de développer des savoir-faire, d’appréhender d’autres techniques permettant la compréhension du contexte et des enjeux, ou supportant l’acquisition d’information. Certaines de ces techniques viennent de la communauté agile, d’autres viennent d’autres domaines comme l’UX ou le « requirements management » que nous avons déjà évoqué.

Bien comprises, les User Stories véhiculent réellement l’état d’esprit agile à ce que nous appelons spécifications (à défaut d’un autre nom plus adapté) : se focaliser sur ce qui compte réellement. Mais il s’agit juste d’un point de départ, à compléter et renforcer comme nous le faisons avec nos pratiques d’ingénierie.

Références

[Adzic13] : Writing “As a User” does not make it a user story ; Gojko Adzic ; http://gojko.net/2013/09/30/writing-as-a-user-does-not-make-it-a-user-story/

[Adzic+14] : Fifty Quick Ideas to Improve your User Stories – Gojko Adzic & David Evans – Leanpub 2014 – ASIN : B00OGT2U7M

[Cohn04] : User Stories Applied, for agile software development – Mike Cohn – Addison Wesley / Signature series 2004 – ISBN: 0-321-20568-5; EAN: 978-0-321-20568-1

[DeMarco+08] : Adrenaline Junkies and Template Zombies ; Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson & Suzanne Robertson

[Patton14] : User Story Mapping – Jeff Patton – O’Reilly 2014 – ISBN : 978 1 491 90490 9