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 dans la rédaction d'une documentation d'exigences volumineuse et de directives rigides, ce n'est pas toujours le cas. Les méthodes traditionnelles de développement logiciel reposaient essentiellement sur le respect d'un ensemble d'exigences prédéfini pour chaque fonctionnalité d'un produit, service ou application donné. Cela enfermait les équipes dans des directives strictes, limitant ainsi la flexibilité nécessaire pour procéder à des ajustements instantanés en fonction des données en temps réel ou des retours 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 d'utilisateur » est né.

Une User Story est Une brève description, en deux ou trois 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 en langage clair, sans termes trop techniques, pour une lecture et une compréhension aisées. tout le monde – et pas seulement les développeurs. Par exemple, une user story pour une application d'exercice ou de musculation pourrait être : « En tant qu'utilisateur iOS, je souhaite synchroniser mes données avec une Apple Watch afin de suivre plus précisément mes calories brûlées. »

Ces descriptions pouvaient ê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 conçues pour ê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 planifier un road trip, mais devoir lister chaque direction avant même de quitter la maison. Une fois parti, vous devez suivre ces indications, même si un meilleur itinéraire ou une attraction touristique intéressante 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, dont la rédaction prenait une éternité aux équipes et qui limitait souvent les développeurs à une seule méthode de travail dès le départ. Toutes les exigences devaient être détaillées dès la phase de planification, et les développeurs étaient contraints de les respecter malgré les modifications ou les problèmes rencontrés en cours de route. Les User Stories simplifient le travail des développeurs et des équipes de production sur les nouvelles mises à jour et fonctionnalités des produits en privilégiant les petites mises à jour régulières, basées sur les avantages les plus importants pour l'utilisateur final.

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

Les user stories agiles ont offert aux équipes une plus grande flexibilité et leur ont permis de proposer en continu 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 privilégié la décomposition des livrables en parties plus petites et plus faciles à gérer, ce qui a permis de maintenir l'enthousiasme des clients et de faire progresser le backlog produit. Cela a également permis d'éviter le problème fréquent de trop dévoiler et de se retrouver bloqué sur quelque chose qui n'est pas forcément dans l'intérêt de l'utilisateur.

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

En 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, ensuite décomposé en User Stories individuelles. Ces Epics s'inscrivent ensuite dans une Initiative plus vaste, regroupant plusieurs Epics et leurs User Stories. Les Initiatives et les Epics permettent aux équipes d'organiser différentes User Stories en fonction d'objectifs communs.

Reprenons notre exemple précédent avec l'application d'entraînement imaginaire. Notre récit utilisateur expliquait comment un utilisateur iOS pourrait souhaiter 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é. Les deux récits utilisateurs pourraient alors s'inscrire dans une épopée telle que « Améliorer la fonctionnalité de suivi d'activité pour le lancement du premier trimestre ». Dans ce cas, l'initiative globale pourrait être « Augmenter le nombre d'utilisateurs de 3 % ».

Ensemble, les User Stories contribuent à faire progresser 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 peuvent ainsi déployer des mises à jour plus fréquemment et même 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 dès le début du processus de production. Cela évite aux développeurs de se cantonner à une solution unique et leur offre 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 privilégie le déploiement de nouvelles fonctionnalités et mises à jour, petites mais cohérentes, plutôt que l'approche traditionnelle globale et globale. Cela permet de motiver l'équipe de développement en garantissant l'avancement du backlog produit. De plus, les développeurs n'ont plus à consacrer leur temps à la rédaction d'une documentation des 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 pertinentes pour l'utilisateur. Elles permettent également aux équipes de réagir plus rapidement et en temps réel aux demandes des utilisateurs, les mises à jour étant effectuées par segments plus restreints. L'objectif des User Stories est de permettre aux équipes de prendre du recul et de comprendre les attentes et les besoins des utilisateurs d'un service donné.

Les 3 C des User Stories

Un autre créateur de XP, Ron Jeffries, 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 de deux ou trois phrases de la User Story. Elle doit aborder les points suivants : 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 est un échange entre toutes les parties prenantes, notamment l'utilisateur final, les équipes de production et de développement, et le Product Owner. L'objectif de cette collaboration est d'établir une compréhension commune et de déterminer la valeur de chaque User Story. Les éléments abordés lors de cette Conversation doivent se refléter dans le contenu de la Carte.

Confirmation

La confirmation est un test d'acceptation au cours duquel le Product Owner confirme que la User Story a été réalisée selon une définition prédéfinie de « terminé ». Elle représente les conditions spécifiques à remplir 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 créer des User Stories est d'échanger avec vos utilisateurs. Vous pourrez ainsi comprendre ce qu'ils attendent de votre produit ou service et comment les satisfaire.
2. Déterminer une définition de « Terminé » : C'est ainsi que le Product Owner 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 le OMS : Le « qui » doit désigner le rôle spécifique auquel la User Story est destinée. Ce rôle doit correspondre à un utilisateur final réel (comme l'utilisateur iOS dans notre exemple), et non aux membres de votre équipe, comme un développeur. S'il existe plusieurs types d'utilisateurs, vous pouvez créer plusieurs User Story.
4. Définir le 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 le Pourquoi : Le « pourquoi » doit décrire les avantages de l’histoire utilisateur, comme par exemple l’obtention d’un suivi plus précis des calories dans notre exemple.
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 attentes de l'utilisateur cible sans être trop complexes.

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.

« En tant que [ qui/rôle ], Je veux [ quoi/action ] pour 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é à une grande variété de produits, et même à des types d'utilisateurs spécifiques. Bien que cette structure spécifique ne soit pas indispensable, elle peut vous aider à identifier les user stories nécessaires à votre produit.

N'hésitez pas à créer plusieurs User Stories ; c'est même encouragé ! En organisant vos User Stories au sein d'Epics et d'Initiatives globales, votre équipe peut garantir des améliorations produit constantes et continues qui répondent aux attentes et aux besoins de vos utilisateurs.