De l'écriture des User Stories
J'ai été sollicité récemment sur un sujet de User Story, et en y répondant, j'ai pris un peu le temps de reprendre un peu le sens de l'écriture des User Stories.
US et Agilité
Ecrire des users stories pour être agile, les écrire comme l'entend les méthodes agiles, être agile parce qu'on écrit des users stories...
Différentes choses dans ces propos me chiffonnent, j'aime à rappeler, de distinguer l'Agile (qui est de l'ordre de l'état d'esprit), des cadres de travail ou des méthodes.
Pour rappel, Scrum n'impose pas de formalisme d'échange entre le responsable produit et l'équipe.
Il préconise d'avoir un backlog, avec des éléments suffisants petits (un item doit pouvoir être réalisé en un sprint).
XP a apporté des éléments précisant un formalisme qui se veux standardisant. Aujourd'hui, la plupart des projets "agiles" utilisent ce "standard" pour échanger de l'information.
Échanger
Il faut bien comprendre qu’une
US est avant tout un support d’échange, à la conversation, et non pas un
livrable rédactionnel fini. Une US sert avant tout à transcrire un bout d’idée
sous un format « standard » pour pouvoir la présenter aux
développeurs.
XP préconise que cela tienne
sur un bristol horizontal (titre, règle de gestion exprimé en tant que, je
peux, afin de, et tests d’acceptation), cela donne une idée qu’en terme de
contenu cela doit rester léger.
Même si cela reste un standard,
ce n’est pas absolument la forme qui importe, et l’important est de savoir si
finalement, grâce à cela, les équipes de développement sont en mesure de faire
correctement leur travail. En soit, le travail de rédaction des US n’est
qu’une étape dans le dialogue avec l’équipe pour obtenir le produit imaginé.
Pour rappel, les US doivent
être INVEST (indépendante, négociable, verticale, suffisamment petite, testable), et le N de INVEST est négociable, c’est-à-dire que les
développeurs doivent pouvoir demander au PO de retravailler/découper/reformuler
une US, car lors de l’échange l’équipe trouve que l’US n’est pas à la bonne
granularité, qu’il manque telle ou telle information, ou qu’elle n’est pas
compréhensible en l’état.
Cela ne doit pas être considéré comme un livrable figé, immuable, mais bien un élément d'échange, qui peut vivre durant son cycle de vie.
Il faut être vigilant à ne pas
transformer le travail de rédaction des US en ce qui s’apparentait avant à un
cahier des charges, ou un dossier de spécification. Sinon on revient à un
travail en silo, et du cycle en V.
Finalement, chaque US pourrait être un chapitre d'une spécification plus large, et le format ayant changé, appelé cela l'agile, alors que les usages restent toujours ceux de l'ancien monde.
Les écrits ne doivent en cas être des commandements et surtout ne jamais se substituer à l'échange verbale.
Agilité
Il faut revenir au manifeste
agile, dont la 1ère valeur est individu & interaction plutôt que des
processus & des outils.
La 2ème valeur indique
également notre préférence en un logiciel qui fonctionne plutôt qu’en une
documentation complète.
Backlog
Sur un autre sujet, il est important que
le backlog ne soit pas de taille démesurée, et on ne prépare pas toutes les US
en début de projet, sinon on retombe dans l’inefficace cycle en V.
En main
courante, j’encourage à ne garder qu’une vingtaine d’US finalisées (on va dire
l’équivalent de 2 sprints d’avance).
Le reste doit rester à l’état d’idée (epic, features, ....), afin de pouvoir ajuster au bon moment le besoin, et ne pas avoir
besoin de repasser un temps important à corriger une spécification, ou à donner
une spécification qui soit bancale (car rédigée 6 mois auparavant) vis-à-vis
d’un existant qui a pu diverger.
Échanger et comprendre le besoin
Pour résumé, l’important est de
se mettre d’accord ensemble (avec l’équipe de dev) sur leur besoins, sur ce qui les
aide à traduire un besoin métier en un code applicatif, qui répond à vos
exigences.
L’important n’est pas de passer
du temps à rédiger, mais de maximiser le temps que vous avez à échanger avec
l’équipe, pour qu’elle s’approprie votre besoin, le challenge, et que
vous-mêmes vous vous imprégniez de leurs contraintes.
Les 3 amis
Afin de favoriser l’échange
avec l’équipe et de déterminer la qualité de vos US en terme de contenu, il existe
une pratique qui s’appelle le three amigos. Une fois ou deux par sprint, vous
envoyez vos US aux développeurs et aux testeurs.
Vous organisez ensuite un
workshop d’une heure, avec un po, un développeur, et un testeur, et vous vous concentrez
sur comment tester les US (pas forcément besoin de descendre au niveau d’un
plan de test).
Le but est que derrière cet
échange tout le monde ait compris le besoin, car si on sait le tester, c’est
qu’on a compris quel était le besoin, et parfois dans cette démarche, le po
peut prendre conscience que son besoin n’est pas clair, ou trop important (pas
assez découpé). Cela permet à chacun de découvrir ce qu’attend les uns les
autres, et avoir les US au bon niveau en fin de compte.
A la fin
Vous êtes à la disposition de
l’équipe pour qu’ils fassent au mieux leur travail, et l’équipe est à votre
disposition pour produire le meilleur produit.
Pascal Ogil
Pascal Ogil