Non classé

Qu’est ce qui se cache derrière les User Story ?

User Story, ou “récit utilisateur” en français, est un terme qu’on retrouve un peu partout lorsqu’on travaille en Agile. Il sert à désigner une nouvelle fonctionnalité à implémenter, et à la décrire d’un point de vue utilisateur. Mais comme souvent en Agile, ce terme est régulièrement détourné de sa signification réelle. Qu’est ce qui se cache, alors, derrière ces fameuses User Story ?

Qui ? Quoi ? Pourquoi ?

Une User Story représente une (ou plusieurs) action(s) qu’un utilisateur réalise pour obtenir un résultat. Face à cette affirmation, le PO qui sommeille en nous nous demanderait :
  • Quel utilisateur ? S’agit il d’un client ? d’un administrateur ? d’un client en free trial ? etc.
  • Quelles actions réalise-t-il ? Quelle fonctionnalité utilise t il ?
  • Quel est le résultat qu’il veut obtenir ? A quel besoin cela va t il répondre ?
Pour répondre à toutes ces questions, il existe un format assez connu, et qui sert souvent de canevas à la rédaction d’une US :
En tant que <qui>
Je veux <quoi>
Afin que <pourquoi>
Ou en anglais
As a <who>
I want to <what>
In order to / so that <why>

Par exemple, pour un site d’informations, on pourrait avoir un

As a paying user
I want to save some posts of interest
So that I can find them back easily in the future

Si ce template n’est pas obligatoire, une bonne User Story doit malgré tout contenir ces informations pour bien savoir à qui on s’adresse, dans quel but, et quelle est l’action à réaliser : c’est en particulier en répondant au « pourquoi » qu’on se force à prendre un peu de hauteur, et qu’on s’assure que la fonctionnalité apporte bien de la valeur ajoutée au produit. Il vaut mieux avoir peu de features, mais toutes très utiles, plutôt qu’une accumulation de fonctionnalités qui ne répondent pas (ou mal) à un besoin. 

De plus, ces petites phrases sont souvent utilisées en en-tête des fichiers « .feature » utilisés par Cucumber pour donner du contexte aux tests implémentés. Souvenez vous que lorsque vous relirez ces tests plusieurs semaines plus tard, vous aurez oublié la majorité de vos discussions à ce sujet : elles peuvent alors vous aider à vous remémorer le sujet très rapidement !

Mais du coup, une US, c’est juste ça ?

Bien sûr que non ! Une bonne US répond aussi à plusieurs autres critères, cette fois ci plus orientés aux besoins d’implémentation. Ces besoins ont été regroupés derrière l’acronyme INVEST
 
Independant : il faut être le moins possible dépendant d’une autre US pour lancer son implémentation : cela simplifie la gestion des tâches au sein d’un même sprint
Negotiable : son périmètre doit être négociable : ce qui est proposé par le PO n’est pas gravé dans le marbre (cf article 3 amigos). Le développeur doit avoir une marge de manoeuvre sur les choix d’implémentation.
Valuable : on retrouve ici le « why » présenté au-dessus. Une US doit répondre à un besoin.
Estimable : l’équipe technique s’engage sur une durée déterminée pour réaliser cette tache.
Small : une US doit être la plus petite possible. Plus une US est petite, plus on a d’assurance dans la durée estimée précédemment
Testable : le point le plus souvent oublié… la testabilité doit être pensée dès la conception. Si on ne sait pas comment tester une fonctionnalité, quelle confiance peut on lui accorder ? 
 
Une US peut aussi être complétée par plusieurs éléments pour s’assurer qu’elle est bien comprise par tout le monde. On y trouve des design (Marvel, Figma, etc…), des règles métiers, des flowCharts des cas particuliers, etc…

OK, c’est clair, mais du coup, ça a l’air assez gros finalement, une US… 

Et bien justement, on s’y perd parce qu’il y a beaucoup d’abus de langage avec ce terme. Une US doit être petite pour être INVEST, mais on entend souvent aussi qu’il faut la découper en plusieurs plus petites US. Et du coup, on ne sait plus pour quelles US il faut rédiger les “En tant que…je veux…afin que…” !

Pour lever ces ambiguïtés, je préfère utiliser des mots différents pour des concepts différents. La macro-fonctionnalité s’appelle une Epic. J’entends par macro-fonctionnalité tout concept suffisamment gros pour avoir plusieurs options/écrans/fonctionnalités : par exemple, le système d’achat sur un site marchant, l’onboarding de votre application, etc… Chaque epic est composée de plusieurs US, et chaque US peut elle-même être découpée en plusieurs taches. On obtient ainsi un découpage en 3 étages Epic/US/Tache, qui peut ne pas être suffisant sur des systèmes vraiment complexes, mais qui permet néanmoins de répondre à la grande majorité des situations.

Tous ces découpages peuvent être faits suivant différentes stratégies : 

  • découpage fonctionnel (1 tache pour rajouter chaque règle fonctionnelle)
  • découpage technique (1 tache pour chaque strate logiciel/besoin technique)
  • découpage technique , centré sur la testabilité (on développe le frontend d’abord et on le teste, puis on y branche l’API et on teste les 2 ensembles, et enfin on branche le backend et on teste la totalité : les mocks réalisés aux différents niveaux peuvent aider à la maintenance future du logiciel…)

Chaque découpage a ses avantages et ses inconvénients, mais dans une stratégie Agile, il est vrai que le découpage fonctionnel reste souvent le plus pertinent, puisqu’on ajoute de la valeur ajoutée au produit à chaque US.

L’atelier Example Mapping (article à venir) peut être un excellent moyen de faire le découpage fonctionnel d’une US, mais il en existe bien d’autres !

 

Une bonne US comprend aussi une mesure de son utilisation par les clients : c’est par cette mesure qu’on sait si notre fonctionnalité plait aux clients (et donc s’il faut persister dans cette direction ou pas). Prévoyez donc cette mesure dès la conception de la US, et créez des taches pour que les développeurs mettent les flags sur les boutons pertinents. Enfin, mettez vous des rappels dans votre agenda pour analyser les mesures après quelques jours/semaines d’utilisation.
 

C’est très intéressant tout ça, mais c’est le boulot du PO et pas du QA non ?

Oui, tout à fait d’accord, mais en tant que garant de la qualité, c’est aussi votre rôle de rappeler et promouvoir les bonnes pratiques. Il arrive assez souvent que toutes ces règles ne soient pas respectées, et cela peut nuire à la qualité de votre travail (vous ne pouvez pas tester telle US, vous ne savez pas quels utilisateurs doivent avoir accès à telle autre US, etc…). Donc n’hésitez pas à challenger le process ou votre PO si vous voyez que c’est nécessaire : à la fin, tout le monde sera gagnant !

Ce qu’il faut retenir

Une US est représentée par 1 ou plusieurs « En tant que… je veux… afin que… »
Une US répond aux critères INVEST : Indépendant, Negotiable, Valuable, Estimable, Small, Testable
Une Epic est découpée en plusieurs US, chaque US est découpée en taches

Leave a Reply

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *