Créer un nouveau produit ou implémenter une nouvelle fonctionnalité devrait être gratifiant et encourager l’innovation. Cependant, lorsqu’une équipe de développement se retrouve coincée à rédiger une longue documentation d’exigences avec des directives rigides et étouffantes, ce n’est pas toujours le cas. Les méthodes traditionnelles de développement de logiciels s’appuyaient largement sur le respect d’un ensemble d’exigences prédéterminé pour chaque fonctionnalité unique d’un produit, d’un service ou d’une application donné. Cela enfermait les équipes dans des directives strictes, ce qui ne leur laissait que très peu de flexibilité pour effectuer des ajustements à la volée en fonction des données en temps réel ou des commentaires des clients.

Puis, à la fin des années 90, les équipes de développement ont commencé à adopter des méthodologies de gestion de projet agiles et l'idée d'une approche centrée sur le client. 'Histoire de l'utilisateur' est né.

Une histoire d'utilisateur est une brève description en 2 à 3 phrases d’une ou plusieurs fonctionnalités d’un système logiciel donné du point de vue du client/utilisateur final. Les User Stories sont rédigées dans un « langage simple », ce qui signifie qu’elles ne contiennent pas de termes trop techniques, de sorte qu’elles peuvent être facilement lues et comprises par tout le monde – et pas seulement les développeurs. Par exemple, une histoire d’utilisateur pour une application d’exercice ou d’entraînement pourrait être quelque chose comme : « En tant qu’utilisateur iOS, je souhaite synchroniser les données avec une Apple Watch afin de pouvoir suivre les calories brûlées avec plus de précision. »

Ces descriptions peuvent être rédigées par une ou plusieurs parties prenantes, notamment l'équipe de développement, les responsables ou les clients/utilisateurs. Les user stories étant censées être flexibles et refléter les besoins de l'utilisateur, elles étaient souvent rédigées sur une fiche ou un post-it et régulièrement révisées ou modifiées.

En créant des descriptions d'exigences simplifiées et pertinentes, les équipes de développement ont pu se concentrer sur la fourniture rapide des fonctionnalités et des mises à jour souhaitées par leurs utilisateurs.

Qu'est-ce qu'une User Story en Agile ?

Imaginez que vous planifiez un voyage en voiture, mais que vous devez lister toutes les directions avant même de quitter votre maison. Une fois que vous êtes parti, vous devez suivre ces indications même si un meilleur itinéraire ou une attraction touristique amusante surgissent en chemin. C'était un peu comme ça avant le développement agile de logiciels.

Les User Stories ont été créées pour remplacer la documentation traditionnelle des exigences, qui prenait une éternité aux équipes et obligeait souvent les développeurs à se contenter d'une seule façon de faire les choses dès le début. Toutes les exigences devaient être détaillées lors de la phase de planification, et les développeurs étaient obligés de suivre ces exigences malgré les changements ou les problèmes rencontrés en cours de route. Les User Stories permettent de simplifier la façon dont les développeurs et les équipes de production travaillent sur les nouvelles mises à jour et fonctionnalités des produits en mettant l'accent sur les petites mises à jour régulières en fonction de ce dont l'utilisateur final bénéficiera le plus.

Selon les mots de Mike Cohn, l'un des fondateurs de l'agilité et méthodologies Scrum , une histoire d'utilisateur devrait « déplacer l'accent de l'écriture sur les exigences vers la discussion sur celles-ci ». Programmation extrême (XP) L'auteur et créateur pensait qu'il était plus bénéfique pour les équipes de développement d'adopter une approche « juste assez » axée sur la fourniture d'une valeur cohérente aux utilisateurs.

Les user stories agiles ont offert aux équipes beaucoup plus de flexibilité et leur ont permis de proposer en permanence de nouvelles fonctionnalités et mises à jour à leurs clients, souvent en temps réel. Plutôt que de lancer des produits de grande envergure, le développement logiciel agile a mis l'accent sur la division des livrables en parties plus petites et plus faciles à gérer, qui ont su enthousiasmer les clients et faire avancer le backlog produit. Cela a également permis d'éviter le problème courant de révéler trop de choses et de se retrouver coincé à travailler sur quelque chose qui n'est peut-être pas dans le meilleur intérêt de l'utilisateur.

Histoires, épopées et initiatives : comment les user stories agiles font avancer les projets

Dans la méthodologie agile, les User Stories font partie de ce que l'on appelle une Epic. Les Epics détaillent un ensemble de travaux plus vaste qui est ensuite décomposé en User Stories individuelles. Ces Epics s'inscrivent ensuite dans le cadre d'une Initiative encore plus vaste, contenant plusieurs Epics liés et leurs User Stories. Les initiatives et les Epics permettent aux équipes d'organiser différentes User Stories en fonction d'objectifs communs.

Revenons à notre exemple précédent avec l'application d'entraînement imaginaire. Notre exemple de récit utilisateur détaille comment un utilisateur iOS peut vouloir synchroniser les données de son Apple Watch. Cependant, un récit utilisateur distinct pourrait se concentrer sur les utilisateurs Android et d'autres trackers d'activité physique. Les deux récits utilisateurs pourraient alors être regroupés sous une épopée telle que « Améliorer la fonctionnalité de suivi de la condition physique pour le lancement au premier trimestre ». Dans ce cas, l'initiative globale pourrait être « Augmenter le nombre d'utilisateurs de 3 % ».

Ensemble, les User Stories contribuent à faire avancer les Epics, ce qui permet aux équipes de mener à bien des initiatives complètes avec des améliorations continues pour l'utilisateur final. Les équipes sont alors en mesure de déployer des mises à jour plus fréquemment et même de répondre plus rapidement aux demandes des utilisateurs et des clients.

Les avantages des user stories agiles

L’adoption de user stories agiles par rapport à la documentation traditionnelle des exigences présente quatre avantages majeurs :

1. Flexibilité accrue pour l'équipe de développement. Les user stories libèrent l'équipe de développement de la nécessité de suivre une documentation rigide et restrictive rédigée au début du processus de production. Cela évite aux développeurs de se retrouver enfermés dans une solution unique et leur donne la flexibilité nécessaire pour travailler sur des fonctionnalités et des mises à jour innovantes.
2. Les mises à jour logicielles sont plus rapides. Le développement agile se concentre sur le déploiement de nouvelles fonctionnalités et mises à jour, de petite taille mais cohérentes, plutôt que sur l'approche traditionnelle globale. Cela permet de motiver l'équipe de développement en garantissant que le backlog produit avance. De plus, les développeurs n'ont plus besoin de passer leur temps à rédiger une documentation d'exigences longue et exhaustive.
3. Les équipes peuvent se concentrer sur ce qui compte le plus : l’utilisateur. Les User Stories aident les équipes de production à se concentrer sur les fonctionnalités les plus importantes pour l'utilisateur. Elles permettent également aux équipes de répondre plus rapidement et de réagir aux demandes des utilisateurs en temps réel, car les mises à jour se produisent par segments plus petits. L'objectif des User Stories est de permettre aux équipes de prendre véritablement du recul et de comprendre ce que les utilisateurs veulent et ce dont ils ont besoin du service donné.

Les 3 C des User Stories

Ron Jeffries, un autre créateur de XP, a popularisé l'idée de décomposer les User Stories en ce qu'il appelle « les 3 C ». Selon Ron, les User Stories doivent toutes contenir ces trois éléments essentiels :

Carte

La carte est une courte description en 2 à 3 phrases de l'histoire utilisateur spécifique. La carte doit aborder les OMS (un rôle d'utilisateur spécifique), quoi (la tâche ou l’action souhaitée), et pourquoi (l’avantage d’accomplir cette tâche ou action).

Conversation

La conversation représente une discussion promise entre toutes les parties prenantes, y compris l'utilisateur final, les équipes de production et de développement et le propriétaire du produit. L'objectif de cette collaboration est d'établir une compréhension commune et de déterminer la valeur de chaque User Story. Ce qui est discuté au cours de cette conversation doit se refléter dans ce qui est écrit pour la carte.

Confirmation

La confirmation est un test d'acceptation au cours duquel le Product Owner confirme que la User Story a été satisfaite sur la base d'une définition prédéterminée de « terminé ». Elle représente les conditions spécifiques qui doivent être remplies pour atteindre les objectifs de la User Story.

Comment commencer à écrire des user stories

Une fois que vous êtes prêt à commencer à écrire des User Stories, il y a quelques éléments clés à garder à l'esprit.

1. Parlez à vos utilisateurs : Cela peut paraître évident, mais l'une des meilleures façons de commencer à créer des User Stories est d'avoir des conversations avec vos utilisateurs. De cette façon, vous pouvez déterminer ce qu'ils attendent de votre produit ou service et ce que vous pouvez faire pour les satisfaire.
2. Déterminer une définition de « terminé » : C'est ainsi que le propriétaire du produit déterminera si l'histoire utilisateur a été réalisée et si la tâche décrite peut désormais être réalisée par l'utilisateur cible.
3. Définir la OMS : Le « qui » doit désigner un rôle spécifique auquel l'histoire utilisateur est destinée. Le rôle doit correspondre à un utilisateur final réel (comme l'utilisateur iOS dans notre exemple), qui n'inclut pas les membres de votre équipe tels qu'un développeur. S'il existe plusieurs types d'utilisateurs, vous souhaiterez peut-être créer plusieurs histoires.
4. Définir la Quoi : Le « quoi » représente une action ou une tâche spécifique. Dans notre exemple, l'action consiste à synchroniser des données avec une Apple Watch.
5. Définir la Pourquoi : Le « pourquoi » doit décrire les avantages de l’histoire utilisateur, comme par exemple un suivi plus précis des calories.
6. Rédigez des user stories en langage clair : Les user stories doivent être faciles à suivre et à comprendre. Elles doivent refléter clairement le point de vue et les souhaits de l'utilisateur cible sans être trop compliquées.

Exemples et modèles d'histoires d'utilisateurs

La plupart des User Stories suivent le même format de base ou modèle de User Story.

'Comme un [ qui/rôle ], Je veux [ quoi/action ] afin que je puisse [ pourquoi/bénéfice ].”

Notre exemple précédent s’inscrit parfaitement dans ce schéma : « Comme [ OMS: un utilisateur iOS], je veux [ quoi: [synchroniser les données avec une Apple Watch] afin que je puisse [ pourquoi: [suivre les calories brûlées avec plus de précision].”

Ce modèle peut être appliqué à toutes sortes de produits différents et même à des types d'utilisateurs spécifiques au sein de ce produit. Bien que cette structure spécifique ne soit pas nécessaire, elle peut vous aider à commencer à réfléchir aux User Stories nécessaires à votre produit.

N'ayez pas peur de créer plusieurs User Stories. En fait, c'est même encouragé ! En organisant vos User Stories au sein d'Epics et d'Initiatives englobantes, votre équipe peut garantir des améliorations de produit constantes et continues qui reflètent les souhaits et les besoins de vos utilisateurs.