A la recherche de pratiques robustes : User Story

le 30/01/2019 par Christophe Thibaut

(Dans cette série d'articles, nous nous inspirons de la Via Negativa pour partir à la recherche de pratiques robustes, basées sur des connaissances négatives, et dont le principe est d'identifier rapidement et avec certitude ce qui ne fonctionne pas, afin de construire un système plus solide.)

Scénario Utilisateur : Ce que ça n'est pas

Le terme user story est devenu si répandu qu'il y a lieu de soupçonner une récupération en masse plutôt qu'une assimilation du pattern. Afin d'éliminer d'entrée la confusion avec certaines altérations, survivances ou inventions nouvelles, rappelons donc ce que n'est pas le pattern Scénario Utilisateur :

Ce n'est pas un document, parce qu'un document se rédige, se transmet, se conserve et se consulte de manière à pallier une distance. L'erreur serait de rédiger des users stories afin de les envoyer à des développeurs absents. User Story repose sur la présence.

Ce n'est pas une spécification, parce que spécifier signifie "décrire de façon précise". L'erreur serait de croire que la user story en dit suffisamment pour pouvoir se passer des conversations de mise au point. A contrario le scénario utilisateur est un prétexte à la conversation.

Ce n'est pas une "expression de besoin", parce que l'on décrit une interaction utilisateur/système et non un besoin. L'erreur serait de faire croire que ce qui est décrit n'est pas négociable.

Ce n'est pas une tâche, car une tâche indique ce qu'il faut faire, et non ce qu'on souhaiterait obtenir. L'erreur serait d'assigner des tâches aux développeurs au lieu de les aider à comprendre ce que l'on souhaite obtenir.

Une "user story technique" n’est pas une user story, car l'utilisateur n'a rien à faire de la technique. L'erreur serait de décrire de la technique au lieu d'une interaction, et bien sûr d'assigner des tâches (techniques) aux développeurs au lieu de les aider à comprendre ce que l'on souhaite obtenir.

Ce n'est pas un template, car les templates ne servent qu'à ceux qui tentent d'enseigner le pattern user story, pas à ceux qui l'utilisent pleinement. L'erreur serait de mécaniser la description des scénarios jusqu'à les vider de leur sens.

Toutes ces confusions sont fréquentes dans les entreprises depuis qu'elles ont adopté Scrum pour le développement de logiciel. Elles tiennent probablement à plusieurs facteurs :

Simplicité apparente du pattern User Story, qui semble décrire un format de document, alors qu'il décrit en fait des interactions.
Programmes de formation insuffisants, étant donné la simplicité apparente du pattern.
Demande en formation et en accompagnement supérieure à une offre compétente de formation et d'accompagnement sur le marché (comme c'est naturellement le cas pour toute formation impliquant un savoir faire en forte demande).
Dominance de la culture du document livrable dans le développement de logiciel.
Persistance de la gestion de projet (découpés en tâches assignées à des ressources) dans le développement de logiciel.
Freins culturels, organisationnels, juridiques, et commerciaux à la création d'équipes en osmose pour fabriquer du logiciel.

Scénario Utilisateur (User Story) : Ce que c'est

Inspirés par la Via Negativa, nous avons vu ce que n'est pas le pattern User Story. En voici maintenant une définition positive :

User Story est un pattern de développement logiciel consistant à préparer, planifier et réaliser le travail de développement à travers une série de descriptions succinctes d'une petite partie des fonctionnalités du logiciel, vues du point de vue de ses utilisateurs, et qui place le focus sur la discussion plutôt que la spécification.

Quel est le sens de cette pratique ? Cette pratique permet de mettre à l'épreuve rapidement, régulièrement et par petites séquences, le logiciel qu'on est en train de construire, afin d'obtenir au plus tôt des informations à propos de :

Ce qui marche
Ce qui ne marche pas et qu'on est à peu près certain de devoir corriger, ajuster, supprimer, ou remplacer :
- technologies que l'on croyait plus simples ou mieux adaptées ;
- parties du modèle qui s'avèrent plus fausses que d'autres (tous les modèles sont faux, mais certains sont utiles) ;
- hypothèses que l'on faisait à propos des utilisateurs, de l'architecture, de l'ergonomie…
- tests qu'on jugeait faciles à faire passer et qui ne passent pas…
- bugs, erreurs, omissions, incohérences, ambiguïtés-devenues-code, trous dans la raquette, etc.
- incohérences dans la communication de l'équipe (au sens large) ;
- lacunes avérées (et donc réparables, car le plus tôt est le mieux dans ce domaine) ;
- incompatibilités (de technologies, de vocabulaire, de rôles, d'humeur…) ;
- facteurs de coûts, erreurs d'estimations ;
- rigidités, réponses au stress, perte de confiance… ;
- etc.

Mauvaises nouvelles, bonnes nouvelles

Comme on le voit, User Story est un petit pattern qui peut rapporter gros, à condition de savoir accueillir les mauvaises nouvelles. Beaucoup d'équipes qui font leur premier projet en Agile sont tentées d'éviter de telles mauvaises nouvelles (par des moyens variés : rédaction de user stories plus détaillées, allongement de la durée du sprint, "défaillance" de l'environnement d'intégration, report des livraisons, évitement mutuel avec le Product Owner, interdiction de contacter des utilisateurs, etc.). Cette réaction qui consiste à neutraliser l'information dans un projet qui "se passe mal" n'est ni nouvelle, ni propre à l'Agile : elle est inévitable dans une organisation qui à la fois sépare les responsabilités tout en évaluant les performances individuelles.

Dans la mesure où elles adviennent au plus tôt, les mauvaises nouvelles sont cruciales pour votre projet de développement. Elle contribuent à rendre celui-ci bien plus robuste aux erreurs de toutes sortes. Pensez à l'alternative : quelle serait la valeur, en fin de projet, d'une information telle que :

"Je me disais bien depuis le début que ce n'est pas vraiment la bonne façon d'utiliser ce framework…"
"Les utilisateurs ont enfin pu (après 6 mois) essayer l'application. Plusieurs d'entre eux considèrent qu'elle ne remplace pas avantageusement leur logiciel existant. Il va falloir faire de la gestion du changement."
"Tu gardes ça pour toi, mais je n'ai jamais vraiment apprécié sa manière de prendre le lead du projet"
"Nous venons de commencer la recette, et il y a déjà 48 anomalies, c'est la catastrophe."

Voilà le genre de phrases qui évoque des souvenirs douloureux chez ceux qui ont fait beaucoup de cycle en V (et/ou du faux Agile). Dans un projet de développement de logiciel, il vaut mieux en général que les mauvaises nouvelles arrivent le plus vite possible, étant donné ce que les conséquences d'une décision erronée coûtent dans ce domaine. Certes, une mauvaise nouvelle transmise trop tôt peut parfois donner lieu à des décisions hâtives et intempestives (surtout lorsque lesdites décisions précèdent la réflexion) mais c'est le plus souvent la situation inverse qui arrive, à savoir qu'en ignorant pendant trop longtemps des informations qui auraient permis d'agir à temps et en douceur, on se retrouve dans la situation d'avoir à agir trop tard et avec brutalité.

À condition qu'il soit correctement mis en œuvre et complètement assumé, le pattern user story améliore la robustesse d'un développement face aux erreurs de conception (d'estimations, de communication, …) parce qu'il permet de prendre des mesures correctives au moment où ces mesures coûtent le moins cher (et sont encore possibles). Un exemple frappant de construction de cette robustesse est révélé dans la situation suivante :

À la fin de son premier sprint, une équipe de 4 développeurs discute avec le Product Owner à propos d'une démonstration dont le résultat n'est pas satisfaisant. Il s'avère que pour une certaine user story, l'IHM de l'application est supposée permettre la gestion d'un portefeuille de contrats. L'un des développeurs fait remarquer que la base de données (existante) à laquelle s'adosse l'application ne contient pas d'entité correspondant à la notion de portefeuille. Jusque là, cette notion était reflétée dans les applications existantes (via des vues SQL), mais elle n'était pas structurante en termes d'expérience utilisateur. Une discussion s'ensuit à propos des changements à apporter au modèle métier dans la nouvelle application. Le Product Owner, vraisemblablement irrité de participer à une conversation largement dominée par des considérations techniques, interrompt, faisant remarquer qu'on perd du temps. L'un des développeurs rétorque qu'au contraire on est en train de gagner du temps : peu importe de savoir si cette erreur de conception aurait pu être décelée plus tôt, le fait est qu'elle est maintenant manifeste, et que quel que soit l'angle sous lequel ils évaluent les différentes solutions possibles, les développeurs sont convaincus que faire comme si cette erreur ne s'était pas produite, en minimisant ses impacts sur le modèle métier et l'IHM, conduira à une application moins bien adaptée aux besoins, moins intuitive, moins performante, et plus coûteuse à maintenir.

Si la démonstration, la revue ou les tests d'un scénario utilisateur mettent en évidence des problèmes qui ne peuvent pas être ignorés, votre projet vient de gagner à la fois en robustesse et en efficience.

Une personne à qui je faisais cette observation m'a objecté : sauf si ces problèmes "tuent" le projet sur place. Je complète donc cette observation par la suivante :

Si la démonstration, la revue ou les tests d'un scénario utilisateur doivent mettre en évidence un obstacle fondamental à la réalisation du projet, autant que cela arrive le plus tôt possible.

Ces observations constituent à mon sens un premier pas vers une forme de sagesse du développement logiciel. Une personne expérimentée dans ce domaine vous accordera sans conteste qu'il est plus simple, moins coûteux et moins risqué de livrer (i.e. développer, tester, démontrer, corriger) 5 stories par semaine (en moyenne) pendant 1 an, que de livrer l'équivalent de 260 stories au bout d'un an. On pourrait discuter à loisir de la bonne "taille" de story ou d'itération, mais le principe sous-jacent est indiscutable. Il a pour nom diviser pour régner. C'est le même principe qui fait qu'un programmeur (sain d'esprit) corrige ses erreurs de compilation au lieu de continuer à coder comme si de rien n'était, ou bien que l'algorithme quicksort est plus rapide que bubble sort (pour une taille de données non triviale), ou bien encore, c'est la raison pour laquelle chaque chose a sa place dans ma cuisine, et que celle-ci est rangée (la plupart du temps).

Le pattern User Story, à condition d’être mis en œuvre pour ce qu'il est -- un processus de retour d'information, et non un découpage en lot ou une méthode de gestion des tâches de programmation -- permet de récolter au plus tôt des informations négatives à propos de ce que vous construisez. Ces informations sont cruciales dans la mesure où elles rendent votre projet à la fois plus robuste et plus efficient. C'est exactement le sens de la formule "fail early, fail fast", qui nous enjoint à apprendre en marchant, c'est à dire en faisant des erreurs, et l'on pourrait résumer un projet agile en succès, à la somme de ses users stories qui ont survécu.