Ce qu’est un récit utilisateur et ce qu'il n’est pas
Les récits utilisateurs sont apparus en réponse au besoin de l'Extreme Programming (XP), du Kanban et de Scrum de diviser les projets en segments incrémentaux plus petits pour les sprints et les itérations. Ils diffèrent des cas d’utilisation en ce qu’ils se concentrent sur la plus petite unité de travail possible. Les cas d’utilisation, présentés à l’origine par Ivar Jacobson, peuvent être constitués de plusieurs récits portant sur un thème commun. Les récits eux-mêmes sont des histoires simples décrivant un objectif ou une attente unique d'un utilisateur. Vous pouvez décomposer la création d’un récit utilisateur en trois étapes :
- Décrire le besoin.
- Planifier l’itération.
- Mettre en œuvre et tester la réalisation du récit.
À chaque étape, le récit utilisateur peut être affiné pour atteindre la perfection.
Les récits utilisateurs ne contiennent pas de liste d’exigences ou d’instructions de codage, mais sont associés à des critères d’acceptation ou à des tests. L’objectif d’un récit utilisateur n’est pas de se concentrer sur la façon de concevoir, cependant. Au lieu de cela, l’accent est mis sur les personnes qui attendent la fonctionnalité, ce que celle-ci fera et en quoi elle est importante. Les récits apportent une dimension humaine aux fonctionnalités qui finissent par composer la liste d'activités à réaliser du backlog.
Pourquoi les récits d’utilisateurs sont-ils importants ?
Plus qu’une simple liste de fonctionnalités, les récits associent l’utilisateur à la conversation. Les récits utilisateurs fournissent du contexte au développement de logiciel en se concentrant sur la valeur perçue par l’utilisateur. Ce processus qui place l'humain au premier plan supplante le langage Agile, ce qui permet aux non-développeurs de collaborer et de participer aux conversations.
Les récits utilisateurs facilitent le dialogue constant tout au long du projet de développement informatique afin d’aider dans des domaines tels que la planification des sprints/de l'itération et la hiérarchisation du backlog d'une version de logiciel. En revanche, le développement traditionnel en cascade adopte des dialogues au début et à la fin du processus de développement.
Dans son livre User Stories Applied for Agile Software, Mike Cohn de Mountain Goat Software explique : « Nous prenons les décisions en fonction des informations que nous avons à portée de main, et nous le faisons souvent. Plutôt que de prendre un ensemble complet de décisions au début d’un projet, nous répartissons la prise de décision sur toute la durée du projet. Pour ce faire, nous nous assurons d'avoir un processus qui nous permet d’obtenir des informations le plus tôt et le plus souvent possible. C’est là que les récits utilisateurs entrent en scène. »
Qui rédige le récit utilisateur ?
Les responsables de produit, les parties prenantes, les chefs de produit et d'autres membres de l’équipe commerciale participent à la rédaction des récits utilisateurs. Beaucoup disent cependant que la personne qui les rédige est moins importante que celle qui participe aux discussions et aux conversations qui donnent vie aux récits. Commencez par identifier la personne qui utilisera la fonctionnalité (le persona), avec autant de détails que nécessaire. L’utilisateur peut être défini en termes de fonction ou de description de poste, comme étudiant, voyageur fréquent ou responsable marketing.
Une bonne compréhension de l'utilisateur final limite les préjugés ou les hypothèses des développeurs. Si les utilisateurs sont disponibles, ils peuvent participer, mais, souvent, l’équipe a des designers, des responsables, des rédacteurs et d’autres personnes qui jouent le rôle de représentants du client. Les participants peuvent varier en fonction de l’utilisation du récit utilisateur. Par exemple :
- Création de récits utilisateurs : les participants peuvent inclure des clients, la gestion de produit, l’ingénierie et d’autres parties prenantes telles que les RH, les finances et les ventes.
- Maintenance des récits d’utilisateurs : les participants comprennent la gestion de produit ou un responsable de produit.
- Application et utilisation du récit utilisateur : les participants comprennent des ingénieurs/développeurs, des rédacteurs techniques et des testeurs d’assurance qualité.
Comment rédiger des récits utilisateurs efficaces
Les récits utilisateurs sont des énoncés simples et d’une ligne des bénéfices apportés par une fonction utile. Avant de rédiger le récit utilisateur, effectuez des enquêtes et des entretiens d’utilisateurs pour interroger ces derniers sur les fonctionnalités nécessaires. Commencez par rédiger un parcours de client, énoncé sous forme de récits incrémentaux, sur des cartes de 7,5 x 13 cm ou sur des notes Post-it. Ces cartes peuvent être mises immédiatement en production ou fournir un contexte pour le backlog.
Dans le cas d'une cartographie de récits utilisateurs, vous pouvez afficher les notes Post-it sur un mur de salle de conférence afin que l’ensemble de l’équipe puisse la voir et travailler sur la planification à long terme.
Il existe quelques techniques que vous pouvez utiliser pour vous aider à rédiger les récits dont vous avez besoin. Une technique courante est la structure Rôle - Fonctionnalité - Raison ou Bénéfice (RFB), que vous construisez en complétant les blancs de cette phrase :
- En tant que (utilisateur/persona/client), je veux (faire quelque chose) afin de (recevoir un avantage).
En plus de la question RFB, Ron Jeffries a inventé une méthode qui met en évidence son « approche des trois C » :
- Carte : écrivez la réponse à la question RFB (décrite ci-dessus) sur la carte.
- Conversation : les quelques détails de la carte constituent la base d'une promesse remplie par le deuxième C. Au cours de cette phase, l’équipe discute des détails et définit à quoi correspond le statut « fait ».
- Confirmation : il s’agit du résultat des retours qui détermine les critères de test ou d’acceptation. Ce critère d’acceptation est souvent écrit au dos de la carte et est utilisé comme liste de contrôle initiale lors des futures réunions pour déterminer la fin des travaux.
Tout d’abord introduit dans un article de Bill Wake en 2003 et popularisé par le livre de Mike Cohn, User Stories Applied for Agile Software Development, l’acronyme INVEST est une méthode permettant d'évaluer les récits utilisateurs. Les critères INVEST sont les suivants :
- Indépendance pour mener les développements dans n’importe quel ordre.
- Capacité à Négocier l’étendue du récit à développer.
- Apporte de la Valeur à l’utilisateur ou à l’entreprise.
- Possibilité d' Estimer la manière d'achever le récit.
- Est assez Petit pour être conçu, codé et testé en une seule itération.
- Et enfin, peut être Testé.
La rédaction de récits utilisateurs suivant les méthodes RFB et des trois C sont de bons points de départ. Évaluer l’efficacité en fonction des objectifs INVEST permet de garder les récits petits, fonctionnels et testables.
Bennett Lauber, Chief Experience Officer with The Usability People, LLC, makes the following suggestions for someone preparing to write their first user story: “Make sure you do some research on your users and create personas. This will help the development team have empathy with the user.”
Modèle de récit utilisateur agile
Vous souhaitez vous lancer dans la rédaction d'un récit utilisateur ? Téléchargez un modèle gratuit pour vous aider à définir clairement la fonctionnalité du point de vue de l'utilisateur final. Le modèle comprend des zones pour le type d’utilisateur, son besoin et la raison du besoin. En créant ces récits utilisateurs courts d’une phrase, l’équipe de développement peut développer du code qui répond aux besoins du récit utilisateur. Trouvez d’autres modèles Agile utiles à télécharger ici.
Télécharger le modèle de récit utilisateur agile
Comment rédiger un cas de test à partir d’un récit utilisateur
Un récit utilisateur fournit une orientation pour le développement des critères de tests ou d’acceptation. Cette liste de contrôle aide les développeurs à déterminer le moment où la fonctionnalité est achevée. Comme pour tous les éléments des récits utilisateurs, les critères d’acceptation sont également écrits du point de vue de l’utilisateur. Les critères de test ou d’acceptation décrivent les éléments nécessaires pour réussir à réaliser la fonction requise.
Ces critères doivent inclure les éléments suivants :
- Les exigences fonctionnelles et non fonctionnelles prévues
- Scénarios négatifs de la fonctionnalité
- Lignes directrices sur la performance
- Flux de travail de l’utilisateur approprié
- Impact sur les autres fonctionnalités
- Expérience utilisateur
Thomas Stiehm, CTO at Coveros, writes test cases using Gherkin Language. “This is the given, when, then (GWT) format,” he says. “I use test automation in Cucumber and that consumes Gherkin for automated testing. In addition, involving an experienced tester helps create better stories. They can ask important functionality questions while the story is being developed, which in turn results in more usable functionality.”
Utilisons une inscription à une conférence comme exemple de cas de test : un utilisateur soumet un formulaire qui comprend ses coordonnées et choisit une option de paiement ; une confirmation est affichée à l'écran et envoyée par e-mail. Ces éléments font partie de la liste d’acceptation. Le cas de test considère également la facilité et le flux de l’expérience utilisateur (UX). Comme le récit utilisateur lui-même, la quantité de détails testés ne reflète que ce qui est nécessaire pour s’assurer de la valeur de la fonction.
Hernan Santiesteban, of Great Lakes Web, shares his advice. “One of the best ways to write a test case is to use the given, when, then template, which establishes test conditions, user actions, and expected outcome. For example: given an administrative user signs in successfully, when the admin opens the user dashboard, then the admin will be presented with user management functions.”
Les avantages de la rédaction de récits utilisateurs solides
Pour certains chefs de produit et membres de l’équipe de développement, rédiger des récits utilisateurs à la place des listes d’exigences peut donner l'impression de rajouter des étapes au processus Agile global. Cependant, un avantage clé des récits utilisateurs est qu’ils dépendent de la collaboration et permettent de tenir tout le monde informé et sur la même longueur d’onde. Les choses peuvent évoluer pendant les processus de développement grâce à des découvertes et aux commentaires des parties prenantes ; par conséquent, les récits utilisateurs peuvent évoluer ou s’adapter à ces circonstances.
Voici quelques-uns des avantages les plus courants :
- Décrire rapidement l’avancement en décomposant la vue d’ensemble en projets plus petits.
- Motiver l’équipe et faire progresser le projet avec des réussites rapides.
- Privilégier les utilisateurs finaux et favoriser ainsi une plus grande acceptation et satisfaction des utilisateurs.
- Donner la priorité aux fonctionnalités de grande valeur.
- Offrir un tremplin pour des conversations collaboratives qui permettent de planifier des solutions créatives.
- Encourager des niveaux élevés de coopération qui permettent à l’équipe de rester concentrée sur les résultats qui, à leur tour, créent de meilleurs produits globaux.
Comment rédiger un bon récit utilisateur
Cela paraît contre-intuitif que le développement d’initiatives logicielles de grande envergure doive son succès et son efficacité à des pratiques de l’ancienne école. De simples cartes de 7,5 x 13 cm de différentes couleurs et un feutre permanent constituent la base modeste sur laquelle s'appuyer pour créer des récits utilisateurs qui apportent du contexte à un processus de développement Agile. Les petites cartes favorisent des descriptions simples axées sur les bénéfices, découvertes grâce à la collaboration d’équipe.
Tous les récits utilisateurs sont uniques et doivent être complétés par des cartes de récits, des diagrammes, des storyboards et des maquettes. Voici ci-dessous quelques bonnes pratiques qui peuvent vous aider à rédiger un récit d’utilisateur efficace :
- Sachez qui est votre utilisateur : définissez et comprenez vos personas d’utilisateur.
- Incluez toutes les parties prenantes : assurez-vous d’inclure toutes les parties prenantes pertinentes dans le processus de rédaction des récits utilisateurs. L’équipe de test peut même être en mesure d’affiner l’histoire.
- Concentrez-vous sur l’utilisateur : les discussions et les conversations du point de vue de l’utilisateur fournissent du contexte et permettent de définir à quoi correspond le statut « fait ».
- Faites court et simple : décrivez seulement un élément de fonctionnalité dans chaque récit utilisateur. Si une histoire est trop importante pour être développée sur une courte période, divisez-la en incréments plus petits ou ajoutez des conditions spécifiques qui limitent la fonction. Un bon principe général est qu’un récit d’utilisateur doit être assez court pour que l’équipe de développement puisse le terminer en une seule itération.
- Discutez et collaborez : les discussions sur la taille du projet, le produit minimum viable (MVP), les personnes qui l’utiliseront, ce qu’il fera, et en quoi il apporte de la valeur, participent toutes aux décisions sur l’inclusion et la portée.
- Évitez les détails techniques : n'écrivez pas de tâches techniques ou d'énoncés portant sur la manière de les réaliser dans les récits utilisateurs, car cela peut empêcher la créativité et la collaboration. Les détails techniques viennent plus tard dans le processus et sont intégrés par les développeurs, les testeurs et les architectes de systèmes. Un modèle peut aider à laisser de côté les détails techniques.
- Concentrez-vous sur le QQP : qui l’utilisera, qu'est-ce que c'est et pourquoi c'est important.
- Encouragez la visualisation : utilisez toutes les méthodes (dessins, cartographie de récits ou d'impact, storyboards, maquettes et prototypes) appropriées pour visualiser le produit fini.
- Clarifiez la valeur et le bénéfice : assurez-vous que l’objectif du récit est clair, que le niveau d'urgence est noté, et que le récit est complet.
Difficultés et pièges courants de la rédaction de récits utilisateurs
Un récit utilisateur répond aux questions telles que : qui utilisera la fonction ? Que fera la fonction ? Et pourquoi la fonction est-elle importante ? Les détails du récit établissent le contexte commercial et l'intérêt pour l'utilisateur, et stimulent les discussions d’équipe. Une difficulté courante rencontrée lors de la rédaction des récits utilisateurs consiste à s’assurer que le récit est assez complet pour exprimer la valeur, mais assez simple pour être réalisé sur une courte période, comme un sprint (qui dure généralement entre une et quatre semaines). Le récit ne doit pas contenir de détails techniques sur la façon dont il sera construit ni d'instructions de codage. Ces détails ne sont pas nécessaires à ce stade du développement.
Si un récit est trop long ou trop général, il peut être décomposé en petites parties.
Voici un bon exemple :
- En tant que client bancaire, je veux être en mesure de voir mon solde, afin de pouvoir planifier les paiements de factures.
Il peut être tentant d’ajouter plus de détails ou d’autres fonctions, mais cela créera un récit trop complexe. Ce type de récit ressemblerait à cela :
- En tant que responsable des ventes, je veux obtenir des rapports sur les prévisions, les ventes et le personnel, afin de pouvoir établir mon budget pour une année entière.
Cet exemple comporte plusieurs éléments (générer des rapports individuels : prévisions, ventes et personnel) qui doivent être décomposés en plusieurs récits utilisateurs plus petits.
De plus, assurez-vous d’inclure des critères d’acceptation qui identifient ce à quoi correspond le statut « fait ». Comme indiqué ci-dessus, les critères d’acceptation sont souvent écrits sous forme de liste de contrôle au dos de la carte du récit utilisateur.
Les difficultés supplémentaires rencontrées lors de la rédaction des critères d’acceptation comprennent les éléments suivants :
- La tendance naturelle à se concentrer sur la façon de créer. Cependant, ne pas aborder les détails techniques lors des discussions conduit à des conversations plus riches qui mènent à des solutions créatives ; cela permet également d’inclure des utilisateurs et des membres non techniques de l’équipe dans les discussions.
- Les dialogues et les conversations peuvent prendre du temps et sont souvent oubliés, ce qui limite l’impact positif des récits utilisateurs.
- Le manque de données sur l’utilisateur ou le persona ou une mauvaise compréhension de ceux-ci compromettent l’acceptation de la fonctionnalité lorsqu’elle est mise entre les mains de l’utilisateur final.
- Limiter les récits au plus petit incrément n’est pas facile, mais intégrer trop de détails rend le récit utilisateur trop complexe.
- Omettre des informations essentielles, telles que les critères d’acceptation ou les avantages pour les clients, peut laisser des questions sans réponse pendant le processus de développement.
Le livre User Stories Applied for Agile Software de Mike Cohn identifie le problème principal du développement de logiciel à l’aide de cette observation simple : « Les besoins logiciels sont un problème de communication. »
Le langage technique associé au développement de logiciel et aux méthodologies Agile peut être un obstacle pour beaucoup. Tout au long du processus de développement, la rédaction de récits utilisateurs intègre des conversations et des dialogues ouverts, la décomposition des tâches afin de maintenir l’élan et des définitions solides du statut « fait ». Le développement de logiciel est un processus à grande échelle et chronophage avec de nombreuses parties prenantes et des attentes élevées. Cependant, en suivant quelques lignes directrices simples et certaines techniques démodées, les complexités de la création de logiciels deviennent plus visibles pour l’ensemble de l'équipe et, en fin de compte, plus réalisables.
Maîtriser la rédaction de récits utilisateurs avec Smartsheet pour le développement de logiciel
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.