Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage, je m'appelle Nicolas
Brandon Bernard et aujourd'hui on va parler de ce qu'est une user story. Alors quand
on parle de méthodologie agile, le sujet des user stories ou des récits utilisateurs
en français, il est vraiment incontournable et pourtant la définition ou plutôt l'utilisation
qu'en effet ne correspond pas toujours au concept d'origine. D'ailleurs si jamais le
sujet de l'agilité vous n'est pas vraiment familier, je vous conseille d'écouter un précédent
épisode du podcast où on aborde le sujet. En 1998, pendant la visite d'un projet de
transformation numérique chez Chris Lair, Alistair Cockburn, un des perfondateurs du
mouvement agile, lance la phrase suivante, a user story is a promise for conversation,
donc a réussi utilisateur et l'annonce ou l'invitation, la promesse d'une discussion.
En 1999, Kent Beck introduit entre autres le concept de user story en pratique pour la
gestion de projet dans son ouvrage Extreme Programming Explained et au fil des années,
le concept ne cessera d'évoluer et les bonnes pratiques verront le jour à force d'expérience.
Alors si vous demandez à un développeur ou une développeuse prise de hasard de vous décrire
le concept d'un réutilisateur, il y a de très fortes chances pour que la réponse soit à peu
près la description textuelle d'une fonctionnalité logicielle du point de vue d'un utilisateur,
souvent une à deux lignes sur un post-it ou sur un ticket. Si évidemment il y a une part de vérité
sous cette description, c'est un peu comme la partie visible de l'iceberg parce qu'en utilisant
les user stories que sous la forme d'une simple carte ou d'un post-it, on perd une grosse partie
de la raison d'être de ces user stories. Une user story, c'est un outil qui permet de définir
une exigence logicielle en fonction de trois données importantes qui, quoi et pourquoi,
ou autrement dit qui est l'utilisateur qui va effectuer cette action, qu'est-ce qu'il va pouvoir
faire et quel bénéfice cette action va-t-elle lui apporter à lui ou à un autre utilisateur.
Mais le concept surtout, il s'arrête pas là. Comme le disait Alistair Cockburn,
une user story doit inviter à la discussion et c'est là le concept important qui diffère
des anciens outils de gestion et de suivi de projet. En décrivant trop précisément en amont
une fonctionnalité qui doit être réalisée, ça ferme la possibilité de rediscuter de la tâche,
à la fois avec les différents corps de métier, développeurs, architectes, UI designers, etc.
Mais aussi avec le client. En réalité, on se donne une fausse idée de certitude en essayant de tout
prévoir, ce qui est impossible évidemment, un projet, il vit et il évolue, même pendant la
phase de développement, en fixant à la fois le but, la fonctionnalité, mais aussi souvent le
chemin pour y arriver, l'implémentation. Donc l'idée derrière une user story, c'est de définir
simplement le contexte et le but, mais de laisser l'implémentation libre à la discussion de chacun
des corps des métiers. Ça permet à la fois de solliciter la créativité de tous les corps
de métier pour améliorer cette implémentation, mais aussi de pouvoir réagir plus facilement
en cas de changement dans l'orientation d'un projet. Mais alors comment être sûr d'y arriver,
tout en gardant le projet cohérent ? Ça, on va le faire grâce à un cadre de travail dont je vais
vous parler qui s'appelle le framework des 3C. Ce framework, il décompose la création d'une user
story en trois grandes parties. Évidemment, elle commence chacune par la lettre C, donc on a la carte,
la conversation et la confirmation. La carte, c'est souvent la partie la plus connue de la création
d'un récit utilisateur et c'est malheureusement parfois la seule dont les gens se souviennent.
Cette étape est consistée à rédiger en langage naturel, on va dire 10 à 15 mots,
une exigence logicielle sous la forme d'une fonctionnalité du point de vue de l'utilisateur
final. On va utiliser une forme utilisateur action-benefice. Un exemple, en tant que vendeur,
je souhaite poster une photo de mon article pour améliorer mes chances de vente. Cette
phrase, elle va servir à la fois de description courte mais aussi plus ou moins d'identifiant
quand on aura besoin d'évoquer ce récit utilisateur en particulier. Ensuite, on a la
conversation. On l'a dit, c'est le gros élément différentiant par rapport à d'autres méthodes
de gestion de tâches plus classiques. La partie de discussion d'une user story doit avoir une place
importante et doit dans l'idéal rassembler au maximum les échanges avec le client, qui peuvent
aller jusqu'à même prendre des citations, des extraits de conversations, des échanges de mails
ou peu importe, les échanges avec les différents corps de métiers en interne et évidemment
les fichiers, ressources et un maximum de documents qui traitent du récit utilisateur en question.
Il faut vraiment rappeler que ce n'est pas seulement au Product Owner, Scrum Master ou chef
de projet de participer à la conversation, il faut que cet espace pousse à la discussion toutes
les branches travaillant sur le projet. Ensuite, on a pour terminer la confirmation. Cette partie
doit contenir toutes les spécifications requises par le client pour valider que le récit utilisateur
est réalisé et correspond bien aux exigences. L'équipe projet peut aussi ajouter des éléments
de confirmation en fonction des attentes en termes de qualité en interne afin que la fonctionnalité
soit validée quand elle paraît parfaitement fonctionnelle et que l'implémentation soit de
qualité. C'est en s'appuyant sur tous les éléments présents dans la partie confirmation que de chaque
récit utilisateur, que le Product Owner pourra définir si la user story est définitivement
validée ou si elle doit repartir dans un cycle de développement parce qu'il doit y avoir des
modifications. En pratique, on retrouve souvent six états différents pour un même récit utilisateur
et donc ces six états sont en attente, on dit pending en anglais, en discussion, discussing,
affaire, tout doux, en développement, developing, en confirmation, confirming et terminé, finished.
Évidemment, on peut passer d'un état à un autre de manière descendante dans l'ordre dans
lesquels j'ai donné ces états mais on peut repartir d'un état en confirmation à un état
discussing puisqu'on se rend compte que certaines spécifications de la user story n'étaient pas
valides ou en tout cas n'étaient pas suffisamment précis ou voilà, amenées à faire des choix
qu'on n'était pas prévu à l'origine et puis repartir en tout doux quand les modifications
doivent être faites en développement etc. Alors il existe un moyen d'hémotechnique
pour se rappeler d'un certain nombre de bonnes pratiques quand on rédige des récits utilisateurs.
Cette astuce, c'est l'acronyme investe. I pour indépendant, un récit utilisateur, il doit
pouvoir être déployé sans dépendre d'un autre récit utilisateur, celui-là il est important
à garder en tête. N, c'est pour négociable, l'idée c'est de ne cadrer que l'essentiel
du besoin utilisateur pour laisser un maximum d'espace à la discussion. V, c'est pour valuable,
un récit utilisateur, il doit délivrer une valeur pour l'utilisateur final, sinon,
ce récit utilisateur, il doit être remis en question. E pour estimable, une estimation doit
justement pouvoir être réalisé pour pouvoir être priorisé et loger dans un sprint parce que si
on ne sait pas du tout l'ampleur de la user story, au moins avoir grosses homodos et une idée,
on ne va pas savoir si on peut le faire maintenant ou si il va falloir un sprint complet pour l'arréaliser
ou peu importe. S, c'est pour small, un récit utilisateur, il doit pouvoir être suffisamment
court à réaliser pour être complété en quelques jours. Si la user story dure plusieurs semaines,
un mois ou peu importe, il est nécessaire de la diviser en plusieurs user stories plus courtes.
Et enfin, le T, c'est pour testable. Évidemment, cette user story doit être testable grâce aux
critères de confirmation établies pendant la rédaction de la user story. Elle doit être
autovalidatrice. Alors, les avantages d'une bonne utilisation des user stories dans la gestion
d'un projet, il y en a quelques-uns, c'est d'abord de s'assurer de garder la tension fixée sur les
utilisateurs en premier, les utilisateurs finaux évidemment. C'est de favoriser également la
collaboration entre les différents corps de métier pendant la phase de communication.
De pousser la recherche de solutions créatives pour l'équipe et gagner du temps de développement
et surtout gagner de la qualité finale. Et également de maximiser l'inertie en gardant
des récits utilisateurs justement suffisamment court et motivant pour les développeurs et
développeuses. Donc on voit que en réalité, ce qui est attendu des récits utilisateurs,
c'est assez peu souvent ce qu'on retrouve en réalité en pratique dans le monde professionnel.
Mais n'hésitez pas à partager cet épisode du podcast avec d'autres gens autour de vous,
pas forcément que des développeurs et des développeuses, des chefs de projet,
tous les membres de votre équipe. Et si jamais vous préférez une version écrite,
eh ben vous retrouverez la version écrite de cet épisode directement dans les notes de ce podcast.
Donc vous pouvez aussi partager le lien de l'article avec votre équipe.
Sur ce, je vous donne rendez-vous la semaine prochaine pour un prochain épisode du podcast
de Code Garage ou directement sur la plateforme code-garage.fr pour retrouver tous nos podcasts,
tous nos articles et évidemment toutes nos formations complètes pour continuer à vous
former dans vos compétences de développeurs et de développeuses et progresser dans votre carrière.
A la semaine prochaine, salut !