Qu’est-ce qu’un récit utilisateur ?
Selon l’une des personnes à l'origine du mouvement Agile, Alistair Cockburn, « une carte de récits est une promesse de conversation. » Plus précisément, il s’agit d’une conversation avec votre client qui amène à la description d’une fonction logicielle du point de vue de ce dernier. Ceci est le fondement du récit utilisateur, un élément essentiel du cycle de vie du développement de logiciel Agile et Lean. Les thèmes, les initiatives, les epics (épopées) et les récits sont tous des blocs de construction, grands et petits, qui aident à organiser les fonctionnalités nécessaires à la création d'une solution logicielle centrée sur l’utilisateur. Les termes peuvent sembler familiers d'un point de vue littéraire, à juste titre. Un récit utilisateur est un récit simple, tandis que des récits connexes forment une epic. Voici comment ces termes fonctionnent ensemble :
Thèmes : but ambitieux ou objectif de haut niveau.
Initiative : collection d’epics qui aideront à atteindre l’objectif principal.
Epic (épopée) : besoin commercial de haut niveau ou récit utilisateur de grande portée. Celles-ci sont difficiles à mettre en œuvre en une seule itération, de sorte qu’elles sont divisées en plus petits récits. Une epic entière est généralement incluse dans une seule version de logiciel.
Récits utilisateurs : exigences ou scénarios utilisateurs succincts qui apportent de la valeur et sont écrits du point de vue de l’utilisateur. Chaque récit est lié à un sprint ou une itération.
En voici un exemple :
Le thème (tout à gauche) est l’objectif commercial de haut niveau ; il est constitué des initiatives correspondantes, des epics qui soutiennent ces initiatives et des récits (tout à droite) qui décrivent des exigences granulaires.
Une organisation de développement de logiciels peut avoir l’objectif ambitieux de moderniser sa solution. Pour accomplir cette tâche, elle doit proposer une expérience utilisateur mémorable. Par exemple, cette expérience utilisateur doit proposer une interface Web moderne, fonctionner rapidement et sur divers appareils d'utilisateurs. Dans ce scénario, chacune de ces epics sera décomposée en récits utilisateurs spécifiques.
Qu’est-ce qu'une epic ?
Une epic correspond à un besoin commercial de haut niveau ou à un récit utilisateur de grande portée. Les epics sont difficiles à mettre en œuvre en un seul sprint ou une seule itération ; elles sont donc divisées en plus petits récits. L’avantage des epics est qu'elles permettent de développer des idées plus larges, et de collaborer, avant de créer de nombreux récits utilisateurs. L’epic peut être conservée comme idée originale, créant ainsi un futur point de référence.
Quel est le but d'un récit utilisateur ?
Un récit utilisateur est destiné à aider au développement d’une solution logicielle. Malheureusement, il n’est pas rare de développer une solution logicielle qui ne correspond tout bonnement pas aux attentes de la base de clients prévue. Les récits utilisateurs sont destinés à atténuer ce risque en permettant une compréhension claire et approfondie des besoins des utilisateurs finaux, garantissant que les fonctionnalités logicielles répondent à leurs attentes.
Comment les entreprises utilisent-elles les récits utilisateurs ?
Les récits utilisateurs sont l’un des principaux artefacts utilisés dans le développement Agile. Ils sont créés pour décrire les fonctionnalités et exigences fonctionnelles et non fonctionnelles, et pour constituer une liste hiérarchisée de fonctionnalités destinée au développement. Cette liste est appelée backlog produit.
Les récits utilisateurs font partie de la carte de récits utilisateurs, une méthode utilisée pour classer les récits utilisateurs le long d'un axe horizontal et d'un axe vertical afin de représenter différents niveaux d’utilisabilité. L’axe horizontal détaille les activités qui expliquent comment l’utilisateur interagit avec le système pour exécuter une fonction. L’axe vertical représente des niveaux de complexité croissants. La première ligne est une représentation fondamentale de la fonction. La ligne suivante ajoute un peu plus de fonctionnalités, et ainsi de suite. Chaque récit utilisateur se voit attribuer un point de récit ou une estimation théorique de la difficulté ou de l'effort à fournir pour développer la fonctionnalité. De nombreuses organisations utilisent des outils de cartographie de récits automatisés. Les outils les plus populaires sont Jira, Rally by CA, StoriesOnBoard et FeatureMap.
Modèle de carte de récits utilisateurs
Vous pouvez également utiliser ce modèle pour créer votre propre carte de récits. Vous pouvez compléter le modèle à l’aide de Microsoft Word ou le recréer à l’aide de notes Post-it collées sur un mur. Ajustez le nombre de cases en fonction des besoins de développement de votre organisation.
Télécharger le modèle dans Word
Quelles sont les caractéristiques d’un récit utilisateur ?
Quel que soit le cadre Agile utilisé, Extreme Programming (XP), Kanban, DAD (Livraison Agile disciplinée), AMDD ou Scrum, les récits utilisateurs sont les mêmes. Le récit utilisateur décrit le type d’utilisateur : le persona, la fonctionnalité qu’il souhaite et le bénéfice qu’il espère que la fonction lui apportera. Un récit utilisateur solide est écrit suivant la structure Rôle -Fonctionnalité - Bénéfice (RFB) :
En tant que
Le récit utilisateur doit avoir les qualités suivantes :
Être assez complet pour prouver la valeur pour l'utilisateur.
Être centré sur l'utilisateur.
Commencer par une epic.
Être court, simple et clair.
Contenir des fichiers et des documents justificatifs si nécessaire.
Être assez complet pour prouver son intérêt, mais assez simple pour pouvoir être développé en une seule itération.
Être écrit en fonction de la contribution de toutes les parties prenantes.
Être flexible et négociable sans avoir d’impact sur d’autres récits ou fonctionnalités.
Être facile à tester.
Inclure des critères d’acceptation (conditions de satisfaction) pour les testeurs.
Vous entendrez peut-être les termes récits utilisateurs et exigences système utilisés de façon interchangeable. Traditionnellement, le développement en cascade utilise les exigences du système pour définir comment une solution logicielle doit fonctionner. Les équipes vont loin dans le détail, ce qui inclut les risques, la portée et d’autres lignes directrices spécifiques au développement. Les récits utilisateur, d’un autre côté, sont simples, favorisent la discussion et soutiennent la méthodologie de développement Agile qui englobe la collaboration et le changement.
Comme mentionné précédemment, les récits utilisateurs doivent être simples mais complets. Par exemple, un bon récit utilisateur peut se lire comme cela :
En tant que client bancaire, je veux pouvoir déposer un chèque en ligne, afin de ne pas avoir à me rendre à la banque.
Voici un exemple de récit utilisateur trop détaillé :
En tant que client bancaire, je veux pouvoir déposer un chèque en ligne, visualiser et imprimer l'historique de mes dépôts, afin de ne pas avoir à me rendre à la banque.
Qu'est-ce qu'un point de récit ?
Chaque récit utilisateur se voit attribuer un point de récit, une mesure de la difficulté ou de l'effort requis pour le développer et le mettre en œuvre. Les équipes peuvent utiliser des numéros à un chiffre (1, 2, 3), à plusieurs chiffres (100, 200, 300), ou tout autre format qu’elles choisissent. La proportion est le facteur important. Par exemple, un récit auquel sont attribués 200 points de récit nécessite deux fois plus d’efforts qu’un récit auquel sont attribués 100 points de récit.
Que sont les critères d’acceptation des utilisateurs ?
Les critères d’acceptation, également connus sous le nom de conditions de satisfaction, garantissent que la solution logicielle répond aux besoins des utilisateurs finaux ou des parties prenantes. Ces critères peuvent inclure les exigences en matière de performance, les normes, les scénarios et les règles de comportement du système. L’équipe de test utilise les critères d’acceptation pour vérifier que le développement est terminé. Une fois ces paramètres atteints, le récit ou la fonctionnalité est considéré(e) comme « fait(e) ».
Comment rédiger un récit utilisateur efficace
La rédaction de vos premiers récits utilisateurs peut être difficile, surtout parce qu'ils constituent la base des fonctionnalités de votre produit. Les récits utilisateurs sont le plus souvent développés au cours de l’étape initiale du développement et utilisés pour planifier les itérations et les sprints, mais ils peuvent être créés à tout moment (au début, pour établir la portée de l’ensemble du projet/solution ; lors du développement, pour identifier de nouveaux récits, supprimer des récits inutiles et diviser les récits en morceaux plus petits ; durant la transition) et ajoutés au backlog pour l’itération suivante.
Les 10 conseils suivants vous aideront à créer des récits utilisateurs efficaces :
Faites passer les utilisateurs d’abord : le but d’un récit utilisateur est d'expliquer la fonctionnalité du point de vue d’un utilisateur. Assurez-vous d’interroger ou de sonder les utilisateurs et d’inclure des informations factuelles définies par ceux-ci. Dans certains cas, l’utilisateur peut ne pas être une personne, mais plutôt un système.
Définissez les personas : comprendre vos utilisateurs est essentiel pour rédiger un récit utilisateur. Créez des personnages fictifs qui représentent vos utilisateurs finaux cibles (ceux-ci peuvent inclure les consommateurs, les acheteurs, les clients fréquents, les comptables, les professionnels RH). Les comportements d’achat, les problèmes qu’ils cherchent à résoudre, et les objectifs globaux sont autant d’informations importantes à connaître sur votre client idéal. Utilisez des noms de persona plutôt que le rôle générique de l’utilisateur lors de la rédaction de vos récits.
Collaborez : veillez à rassembler toutes les parties prenantes pertinentes dans une salle pour collaborer pendant la création des récits utilisateurs. La gestion de produit, les ingénieurs/développeurs, les testeurs, l’assistance client, les ventes et le client doivent tous être représentés.
Faites simple : rédigez un récit simple et clair. Utilisez une voix active et concentrez-vous uniquement sur les faits importants.
Commencez par les epics puis affinez-les : commencez par un récit utilisateur plus large pour comprendre pleinement les fonctionnalités globales, puis étudiez les détails de la fonctionnalité à proprement parler. Chaque étape d’un processus plus large doit devenir un récit unique. Ce processus vous permet d'adapter le récit à un seul sprint ou itération.
Incluez des critères d’acceptation : rédigez des critères d’acceptation qui définissent ce qui correspond au statut « fait » pour ce récit particulier. Les critères d’acceptation contribuent parfaitement aux cas de test utilisés par l’équipe de test pour vérifier que la fonctionnalité est prête pour l’utilisateur.
Commencez par des notes Post-it ou des cartes d’index : lorsque les récits utilisateurs sont apparus dans le cadre de l'Extreme Programming (XP), ils étaient inscrits sur de simples cartes d’index. Utiliser cette méthode encourage la collaboration et la discussion, la visibilité et la transparence ; c'est aussi un moyen facile de faire bouger les choses et de réaliser un storyboard dans un cadre collaboratif.
Affichez les récits utilisateurs dans une zone accessible : rendre le récit utilisateur visible dans un espace ouvert, comme sur un mur ou un tableau blanc, encourage la collaboration tout au long du projet de développement. L’affichage du récit peut être amélioré à l’aide de diagrammes, de modèles, de diagrammes de flux de travail, de cartes de récits et d’esquisses.
Accueillez les commentaires : le développement Agile est flexible. Les commentaires vous permettent d’affiner les fonctionnalités pour vous assurer que le produit offre un intérêt pour l’utilisateur.
Incluez des estimations de temps : le temps nécessaire pour terminer le développement basé sur un récit utilisateur est important pour planifier les itérations et les versions. Les estimations de temps peuvent aider à attribuer des tâches et des sous-tâches aux membres de l’équipe.
Il existe deux techniques principales qui peuvent vous aider à rédiger des récits utilisateurs :
Trois C : inventée par Ron Jeffries en 2001, la formule Trois C comprend une carte ou une note Post-it, une conversation entre les utilisateurs, les développeurs, les testeurs et les responsables de produit à propos de la fonctionnalité, et la confirmation que l’objectif a été atteint.
INVEST : ces critères, introduits par Bill Wake en 2003 et popularisés par le livre de Mark Cohn, User Stories Applied for Agile Software Development, évaluent la valeur d’un récit utilisateur en s’assurant qu’il est indépendant (peut être développé dans n’importe quel ordre), négociable, qu'il apporte de la valeur (à un utilisateur ou à une entreprise), qu'il peut être estimé (temps nécessaire pour l’achever), qu'il est de petite taille (conception, test et code en une seule itération) et testable.
Pour en savoir plus sur la rédaction d’un récit utilisateur et obtenir des conseils et des modèles pour vous aider à commencer, lisez l'article How to Write a User Story in Software Development that Focuses on the User.
Qui rédige le récit utilisateur ?
Il ne s’agit pas nécessairement de savoir qui écrit le récit utilisateur, mais qui est impliqué dans le processus de développement du récit utilisateur. L’objectif est une discussion collaborative qui aboutit à un récit utilisateur. La gestion de produit, les ingénieurs/développeurs, les testeurs, l’assistance client, les ventes et, le plus important, le client doivent tous participer au processus. Le chef de produit ou le responsable de produit est généralement responsable des récits utilisateurs tout au long du cycle de vie du développement.
Quelle est la définition du statut Fait selon la méthode Agile ?
Chaque équipe aura sa propre définition du statut fait ou terminé dans le développement Agile, et cette définition peut varier en fonction de ce dont on cherche à évaluer l’achèvement : un récit utilisateur, un sprint ou une version complète. Il existe des critères qui peuvent être mis en place pour vérifier qu’une fonctionnalité ou une fonction est vraiment terminée. La liste de contrôle des critères peut inclure les éléments suivants :
Le code est-il écrit ?
Le code a-t-il été testé ?
La fonctionnalité répond-elle aux critères d’acceptation ?
La fonctionnalité s’intègre-t-elle dans la solution existante et fonctionne-t-elle avec celle-ci ?
Les spécifications techniques du produit ont-elles été mises à jour ?
La documentation du produit a-t-elle été mise à jour ?
Les cas d’utilisation et les récits utilisateurs sont-ils la même chose ?
Les termes récit utilisateur et cas d’utilisation sont similaires, mais les cas d’utilisation contiennent beaucoup plus de détails granulaires qu'un récit utilisateur. Un récit utilisateur est écrit pendant une discussion collaborative, représente le point de vue d’un utilisateur et comprend l’objectif de l’utilisateur et les critères d’acceptation.
Les cas d’utilisation et les récits utilisateurs sont-ils la même chose ?
Les termes récit utilisateur et cas d’utilisation sont similaires, mais les cas d’utilisation contiennent beaucoup plus de détails granulaires qu'un récit utilisateur. Un récit utilisateur est écrit pendant une discussion collaborative, représente le point de vue d’un utilisateur et comprend l’objectif de l’utilisateur et les critères d’acceptation.
Cette même information se retrouve dans un cas d’utilisation, mais celui-ci va encore plus loin et décrit les exigences fonctionnelles de la solution, y compris toutes les possibilités d’interaction utilisateur/système et les risques éventuels. De nombreux projets de développement intègrent la création de récits utilisateurs, la cartographie des récits et les cas d’utilisation pour élaborer un produit complet et abouti.
Exemples, avantages et défis de récits utilisateurs
Les récits utilisateurs sont généralement écrits en fonction des attributs fonctionnels. Par exemple, « en tant que client, je veux déposer un chèque par voie électronique, afin d’éviter de me rendre à la banque ou au distributeur automatique. » Cependant, il existe des caractéristiques non fonctionnelles, ou des contraintes techniques, qui sont également importantes. À l’aide de ce même exemple bancaire, les contraintes plus techniques peuvent être écrites ainsi : « En tant que client, je veux déposer 12 chèques en une seule transaction électronique. » Comprendre les détails spécifiques (qui peuvent sembler plus techniques) permet à l’équipe de développement de réfléchir aux contraintes qu’elle peut avoir à intégrer à un récit utilisateur ouvert pour le rendre réalisable.
Vous pouvez télécharger les modèles de récits utilisateurs et d’autres modèles Agile ici.
Les avantages du récit utilisateur
Les récits utilisateurs sont un élément commun du développement Agile, et les utiliser correctement offre des avantages importants aux personnes qui développent la solution et au client qui utilise le logiciel.
Avantage pour le client
Trouve un intérêt accru dans la solution logicielle.
Crée une relation positive et collaborative avec l'éditeur.
Améliore la satisfaction.
Élimine les détails techniques afin d’inclure les clients et les parties prenantes non techniques.
Se concentre sur les besoins du client.
Avantage pour l'éditeur du logiciel
Augmente l’avantage concurrentiel.
Encourage la collaboration et la coopération.
Encourage la transparence.
Réduit les risques.
Améliore la satisfaction du client.
Se concentre sur la valeur.
Évite les ajustements inutiles du backlog.
Élimine les détails techniques qui peuvent entraver la collaboration.
Développe des solutions créatives.
Soutient la flexibilité du développement Agile.
Les défis du récit utilisateur
Comme pour tout projet d’entreprise, des défis surviennent. Le livre de Mike Cohn, User Stories Applied for Agile Software, 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 processus de développement de récits utilisateurs est destiné à résoudre cette difficulté, mais l’augmentation de la communication peut sembler fastidieuse pour certaines parties prenantes internes. Défis de récits utilisateurs
Voici d'autres défis :
S'assurer que le récit utilisateur est assez complet pour prouver son intérêt, mais assez simple pour pouvoir être développé en une seule itération.
Se concentrer sur la construction et inclure des détails techniques inutiles à ce stade du développement.
Les conversations et la collaboration peuvent sembler chronophages et insurmontables.
Les récits utilisateurs aident les organisations de développement de logiciels à basculer d’une approche biaisée et axée sur les exigences, vers une approche collaborative et centrée sur les utilisateurs. Ils sont simples, directs et représentatifs des attentes du client. Cette tactique encourage les conversations entre les parties prenantes internes et les clients, ce qui conduit à un produit plus concurrentiel utile aux personnes les plus importantes dans vos affaires : vos utilisateurs.
Améliorer la visibilité des 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.