Récits Utilisateurs

Références :

• https://medium.com/selleo/how-to-create-a-good-definition-of-done-in-5-steps-c1b104e92999
• https://appleneil.medium.com/quality-in-scrum-dod-7ea0c0d6fdda
• https://uxplanet.org/user-story-acceptance-criteria-daf0eca5ee50
• https://thestory.is/en/journal/user-story-acceptance-criteria/
• https://www.usabilis.com/empathy-map-carte-d-empathie-quest-dit-pense-ressent-l-utilisateur/
• https://careerfoundry.com/en/blog/ux-design/what-is-an-empathy-map/
• https://www.nngroup.com/articles/empathy-mapping/
• https://www.youtube.com/watch?v=CqyVKRSZWXw

Le récit utilisateur est une tentative pour décrire le comportement d’une fonctionnalité donnée, dans une situation donnée, et décrite du point de vue de l’utilisateur. Il est à destination des parties prenantes, au sein de l’équipe produit, donc les développeurs, les responsables de la qualification, les opérations, etc. (en fonction de la constitution de notre équipe produit).

Le récit utilisateur est le point d’entrée, choisit par le Product Owner, à partir duquel les équipes techniques travaillent sur la fonctionnalité. Il est le moyen par lequel on va suivre l’implémentation de cette fonctionnalité, jusqu’à son déploiement en production, en passant notamment par la qualification de la fonctionnalité.

Le modèle général en quelques mots :

• phrase d’introduction (“en tant que je souhaite afin de “),
• description du contexte, du comportement, et du résultat attendu avec Gherkin,
• une liste de critère d’acceptation à valider pour considérer le récit comme traité.

De plus, des critères communs aux récits utilisateurs, le “Definition of Done”, permettrons de garantir un niveau de qualité commun à tout les sujets produits traités par l’équipe.

Introduire le Récit Utilisateur

Le récit utilisateur défini, pour un profil utilisateur donné (souvent un persona), qu’est-ce qu’il veut accomplir (le “quoi”), et pourquoi il veut le faire.

On va donc généralement commencer par une phrase au format bien déterminé :

En tant que <utilisateur>, je souhaite <action à faire>, afin de <objectif>.

L’utilisateur

Remarque : ici, on pense souvent aux utilisateurs finaux de notre service. À personnel, j’accorde autant d’importances aux équipes chargé de maintenir le service opérationnel, celles en charge du support des clients, etc. Leur fournir une bonne qualité de service rend également service à nos clients, car la qualité finale du service rendu au client s’en retrouve améliorée.

Le récit utilisateur se concentre sur le rôle de l’utilisateur de notre fonctionnalité dans le contexte particulier à l’utilisation de cette fonctionnalité.

Persona

L’idée est d’identifier l’utilisateur type que l’on qualifie au travers d’un certains nombre d’attributs.

L’usage est de fournir les attributs suivants :

• une description de la personne (parfois une image, nom, age);
• des caractéristiques (caractère, personnalité, connaissances);
• son rôle, et son cadre de vie / de travail;
• ses attentes;
• ses problèmes, besoins et objectifs.

Remarque : La description peut paraître un peu surfaite. Certaines caractéristiques peuvent cependant être pertinentes, pour identifier les limites auxquelles l’utilisateur pourra être confronté. Par exemple, s’il est habitué à des outils informatiques, quel type d’outils, ou si ce sera plutôt un comptable, un responsable spécialisé dans son domaine (et que ce domaine n’a rien à voir avec le produit que l’on souhaite mettre entre ses mains), etc.

Carte d’empathie

Il s’agit d’un outil de “Design Thinking” permettant globalement de se “mettre dans la peau” de l’utilisateur, afin de comprendre son ressenti, ses pensées et ses actions. Cette carte permet d’identifier les points de friction ou de rupture dans le parcours utilisateur, et donc d’identifier des pistes d’amélioration du produit.

Cet outil est particulièrement utilisé pouar la conception de l’expérience utilisateur, lors de l’élaboration de notre solution. Il permet d’aligner les membres de l’équipe sur la compréhension de l’utilisateur.

D’un point de vue commercial, la carte d’empathie peut également être exploitée pour réfléchir au discours commercial et/ou publicitaire.

La carte d’empathie est généralement élaborée tôt dans le processus d’exploration de notre opportunité, pour piloter les réflexions sur les décisions.

La carte d’empathie peut cibler un utilisateur identifié au travers d’un persona (i.e. les deux méthodes sont compatibles). Autrement, on part de qui est notre utilisateur (sa situation, son rôle) et qu’est-ce qu’il veut faire (tâches à accomplir, les décisions qu’il doit prendre, à quoi sauras-t-il qu’il a aboutit). À noter également que la carte d’empathie peut également, et donc au contraire, permettre de concevoir le persona. Dans ces cas là, les informations collectées via cette cartographie permettrons de constituer le persona.

On va dans un premier temps identifier :

• ce que pense ou ressent l’utilisateur (satisfaction, exaspération, frustration, …),
• ce qu’il entend et/ou voit (ou plus généralement, ce qu’il perçoit; ce peut être les données à partir desquelles il travail, la documentation, etc.),
• ce qu’il dit ou fait (renvoi aux actions entreprises pour obtenir le résultat voulu).

À partir de là, nous chercherons à retrouver les bénéfices et pertes auxquelles il sera confronté, pour ensuite essayer d’optimiser les gains tout en réduisant les inconvénients.

Remarque : la carte d’empathie devrait finalement se placer bien en amont du récit utilisateur.

Découper notre récit utilisateur

Déjà ?

Le récit utilisateur exprime d’abord le besoin de notre utilisateur. Attendre de définir notre solution pour penser découpage nous amène à un écueil : découper une solution plutôt qu’un problème.

Découper la solution repose généralement sur un découpage selon le parcours de l’utilisateur dans le produit, ou selon différentes interfaces. Ces approches ne sont pas mauvaises en soit, elles permettent une implémentation incrémentales de la solution, mais pas idéales. Ce devrait être le dernier recours.

Découper le besoin permet de repérer les moindres petites variations qu’il peut avoir en fonction d’une identification plus précise des utilisateurs, de leurs besoins profonds, etc.

Par rapport au récit utilisateur, découper sur la solution ne permet de découper quer sur la base du souhait, ou besoin, de l’utilisateur, et non sur les autres éléments de notre récit utilisateur.

Selon le profil d’utilisateur

En reprenant notre persona, on peut déjà identifier plusieurs axes de découpage.

• Affiner ses caractéristiques va peut-être découler sur des relations différentes avec notre produit. Par exemple un utilisateur à profil technique sera plus habitué à travailler sur terminal, alors qu’un utilisateur non technique sera plus à l’aise avec une interface web ou applicative.
• son rôle et le cadre dans lequel il évolu peuvent impacter le temps qu’il peut investir sur l’application. Il aura peut-être besoin d’automatismes sur certains aspects, afin de se concentrer sur plus de personnalisation sur les autres aspects.

Selon le besoin de l’utilisateur

Remonter à un besoin plus fondamental peut nous amener à lui découvrir plusieurs aspects suffisamment distincts pour justifier plusieurs récits utilisateurs. On peut également choisir de se concentrer sur un aspect bien précis, saillant, de son besoin, et donc produire une solution plus ciblée.

Plusieurs récits, une épopée

Il n’y a pas de roman plus passionnant, que ceux mêlant habilement les intrigues …

L’épopée de notre utilisateur (enfin, “nos utilisateurs”, si leur profil sont assez variés), ne fait pas exception. Les différentes intrigues - enfin, récits utilisateurs - restent liés entre eux par le récit d’origine, qui décrit le comportement de la solution sur laquelle nous travaillons. Nous le garderons donc comme une synthèse de tout les parcours que nos utilisateurs pourrons faire par le biais de notre solution.

L’action

TODO : Il s’agit du parcours de l’utilisateur au sein de notre fonctionnalité.

L’action décrit le comportement du système à l’usage de la fonctionnalité, la façon dont on s’en sert, et la façon dont l’utilisateur interagit avec.

L’objectif

TODO : l’objectif de l’équipe est d’apporter de la valeur à l’utilisateur, c’est-à-dire un bénéfice par rapport au but qu’il vise lorsqu’il va se servir de notre fonctionnalité. L’action de l’utilisateur rentre forcément dans le cadre d’un besoin plus large, mais il est inutile de pousser le raisonnement trop loin, à l’échelle de notre récit utilisateur (c’est une démarche déjà entreprise à plus haut niveau).

L’objectif fournit également une synthèse des exigences de l’utilisateur vis-à-vis de ce qu’il pourra obtenir à l’usage de notre fonctionnalité.

Le parcours de l’utilisateur

Gherkin

TODO : l’intérêt du Gherkin ici est de fournir une description textuelle des conditions dans lequelles l’utilisateur va se servir de notre fonctionnalité, comment il va s’en servir, et quel en sera le résultat. Il nous permet de décrire le comportement avec des phrases claires et compréhensible par toutes les parties prenantes, et fournissent une bonne base à la fois au développement de la fonctionnalité et au développement des tests fonctionnels.

Une description plus complète de Gherkin est disponible dans un article dédié.

Encore besoin de découpage ?

Sur un récit utilisateur donné, on peut se retrouver avec une solution restant complexe à implémenter. Il s’agira donc de refaire un découpage, cette fois-ci pour permettre une implémentation incrémentale de notre solution.

Ce sont généralement les équipes techniques qui nous permettrons d’identifier les portions de l’application nécessitant le plus de travail. En effet, ce sont les contraintes techniques qui dessinnent le déroulé de l’implémentation, et les prendre en compte au plus tôt évitera à notre récit de rester un rêve éveillé.

Les aspects techniques remontant à la surface peuvent être de plusieurs sortes, dont en voici une liste non exhaustive.

• Les contraintes d’exploitation : nous devons penser à la façon dont notre solution sera “opérée”. Des récits utilisateurs spécifiques, mettant en scène les opérateurs et le support, peuvent être rédigés, et nous mener à créer, ou faire évoluer, nos outils d’administration.
• La dette technique : un article dédié est prévu, tellement ce peut être un vaste sujet. Ici, il suffit de dire que notre solution peut toucher à des parties du produit ayant un impact plus global, et qu’un travail de fond peut être requis avant même d’ajouter une quelconque fonctionnalité.

À noter que Gherkin peut également nous amener à identifier des récits spécifiques d’utilisation de l’application. À la rédaction, on peut en effet de rendre compte qu’il existe des parcours alternatifs à nos récits utilisateurs. Ce peut donc être l’occasion de découper notre récit en plusieurs intrigues plus précises.

Valider l’accomplissement du Récit Utilisateur

Definition of Done

Il s’agit d’une description formelle de l’état de notre incrément, lorsqu’il remplit les conditione de qualité voulu pour le produit.

L’équipe défini les critères selon lesquelles ses tâches pourrons être considérées comme achevées. Elles dépendent de l’environnement dans lequel l’équipe travaille. Une fonctionnalité peut être considérée comme prête à être intégrée dans une release à la condition que les critères du Definition of Done sont remplis.

L’objectif est de définir les conditions permettant à l’équipe de progresser dans la qualité, la transparence et la consistence dans le développement des fonctionnalités du produit. Correctement définis, ces critères permettent :

• de clarifier les responsabilités,
• d’assurer les délais de livraison,
• de faciliter l’estimation du travail à réaliser,
• d’avoir une bonne compréhension des fonctionntalités attendues par toute l’équipe, et
• de savoir exactement quand le travail peut être considéré comme achevé.

Les exemples les plus courants rassemblent les exigence de relecture du code, de respect de standards, de couvertures par les tests unitaires, d’intégration, etc. La définition exacte est spécifique à l’équipe et dépend de :

• comment l’équipe considère une fonctionnalité comme étant prête à l’emploi,
• quels sont ses contraintes à respecter, et
• quels sont les tests, la documentation, … les exigences de qualité que l’équipe se fixe.

C’est l’éaquipe qui défini ses critères, et pas une personne pour l’équipe. Idéalement, les critères se présentent sous la forme d’une série de cases à cocher, qui pourra être reproduite pour les différentes tâches. Chaque critère doit être clair et précis, et s’assurer qu’ils puissent être identiques d’une fonctionnalité à une autre (autrement dit, pas de contraintes spécifiques à une fonctionnalité donnée dans les DoD).

Critères d’acceptation

Ces critères servent à définir exactement les conditions à remplir pour que la fonctionnalité décrite rende le service attendu par l’utilisateur.

Ces critères doivent permettre aux membres de l’équipe de prioriser les aspects de la fonctionnalité à implémenter. Par exemple, si on met en place une nouvelle ressource à destination, nous commenceront par la création et la suppression de ressource, accompagnée d’un moyen rudimentaire pour visualiser les ressources disponibles. Ensuite, nous penserons à la façon dont notre ressource interagit avec les autres services et fonctionnalités du produit. Enfin, nous pourrons travailler à la modification des ressources, des mécanismes de filtrage sur la visualisation, etc.

Les critères d’acceptation permettent également de garantir que tout le monde est aligné sur le service rendu par la fonctionnalité. Tout le monde doit avoir la même compréhension de ce que l’utilisateur aura au final entre les mains, notamment les développeurs et les testeurs de la fonctionnatlité.

Il existe basiquement deux façons de rédiger les critères d’acceptation :

• orienté règle (liste de règles définissant la fonctionnatlité),
• orienté scénario (réfère au “Behavior Driven Development”, ou liste de scénarii décrivant la façon dont la fonctionnatlité pourra être utilisées).

Sous forme de scénario, les critères exprimeront les préconditions, et les résultats attendus à l’issue de l’action. Remarque : dans notre cas, on retrouve ce style au niveau du Gherkin. Cela nous paraissait quand même plus clair, en le complétant avec la liste de règle telle que décrite ci-dessous, car elle permet de fournir un système de “cases à cocher” pour valider la réalisation de notre récit.

Lorsqu’exprimé sous forme de règles, les critères d’acceptation doivent remplir quelques conditions (cf. modèles “INVEST” ou “SMART”) :

• phrases simples et courtes (sujet, verbe, complément, guère plus);
• facile à mesurer (idéalement via une réponse binaire fait / pas fait);
• chaque critère est “un” critère, et ne doit pas cacher plusieurs critères en une règle;
• la raison d’être de chaque critère est évidente;
• le critère ne doit pas être excessivement spécifique, mais garantir que la fonctionnalité … fonctionne (i.e. pas de détails techniques);
• enfin, il ne doit pas y avoir trop de critères, pour un récit donné, mais envisager de découper notre récit en plusieurs récits, le cas échéant.

Il est également bon de penser aux critères définissant ce qui est hors du cadre de notre récit utilisateur.

Les critères d’acceptation doivent être rédigés à l’élaboration de notre récit utilisateur, mais pourrons être revus au cours de la conception de notre solution. Il est également important que ces critères soient clairs pour toute l’équipe … avant d’attaquer l’implémentation de notre solution. Il ne doit rester aucune ambiguïté sur notre récit utilisateur avant son implémentation.

Questions ouvertes :

• si nous avons plusieurs récits utilisateurs correspondant à plusieurs déclinaisons d’un cas d’usage de la fonctionnalité, est-ce pertinent de reproduire les critères d’acceptation, sachant que le premier récit traité couvre déjà ces critères ?

Suivi de progression

Construire le récit utilisateur

Le Product Owner est responsable du contenu du récit utilisateur. Cependant, il n’est pas forcément obligé de l’alimenter seul : il peut préparer les grandes lignes, et alimenter en collaboration avec l’équipe produit, afin de bénéficier de l’intelligence collective. Cependant, il devra faire attention à ce que les contraintes techniques ne prennent le pas sur la discussion qui doit rester centrée sur l’utilisateur.

Cycle de vie du récit

• En attente : notre récit a été identifié à l’occasion de l’étude sur la fonctionnalité, et des échanges doivent être plannifiées avec les équipes techniques pour en débattre.
• Définition : les échanges sont en cours pour développer le parcours utilisateur, les critères d’acceptation, les éventuelles contraintes techniques à traiter, etc.
• Implémentation : c’est l’étape fatidique où la fonctionnalité est créée. Elle se termine lorsque les conditions fixées par le Definition of Done et les critères d’acceptation ont tous été cochés.
• Fini : un récit utilisateur est considéré comme fini lorsqu’il est arrivé entre les mains de l’utilisateur tel que décrit dans le document (bien entendu, la fonctionnalité elle-même continuera de vivre).

Tâches techniques

TODO : Le récit utilisateur entraîne la création de tâches techniques. Celles-ci doivent être découpés de sorte à être atomiques, faciles à réaliser (i.e. réduire la complexité), et être priorisés de sorte à maîtriser les dépendances.