Récit utilisateur

En 1999, Kent Beck publie en premier le principe des récits utilisateurs dans le cadre de la méthode « eXtreme Programming (XP) » [1] qu’il avait expérimentée depuis 1996 au sein du projet C3 chez Chrysler.  Celle-ci utilise une gestion et des tâches à base de cartes.  Des cartes de récit y sont utilisées pour désigner succinctement les fonctionnalités à développer.  

Ron Jeffries, impliqué avec Beck dans la mise au point de XP, publie en 2001 la règle des 3C qui veut qu’une carte de récit donne toujours lieu, d'une part à une conversation avec les utilisateurs pour en connaître les détails, et d'autre part à une confirmation, c’est-à-dire des critères qui permettront de vérifier que la fonctionnalité livrée correspond aux attentes[2].

Les récits utilisateurs sont largement adoptés par les méthodes agiles en raison de l’interactivité qu’ils permettent avec les utilisateurs, et du moindre formalisme documentaire, mais aussi en raison de leur adéquation avec des itérations courtes. En effet, un récit est en principe réalisable en une itération contrairement aux cas d'utilisation traditionnels[3].

Bill Wake, également un promoteur de XP[4], publie en 2003 un article sur les règles à respecter pour obtenir de bons récits en proposant l'acronyme INVEST pour les désigner[5]^,[6].

Mike Cohn publie en 2004 un ouvrage qui généralise le principe du récit utilisateur dans sa forme actuelle[7] et qui fait aujourd’hui office de standard en la matière[8].

Après un premier article en 2005[9], et un article de blog en 2008[10], Jeff Patton publie en 2014 la méthode de la cartographie des récits utilisateurs ( « user story mapping » en anglais ), qui vise par une approche systématique à donner une structure à un ensemble de récits liés, et parer par là au risque de manque de visibilité sur les contours du produit et les interdépendances entre ses fonctionnalités[11].

Carte de récit utilisateur recto-verso

Un récit utilisateur est une phrase simple dans le langage de tous les jours permettant de définir avec suffisamment de précision le contenu d'une fonctionnalité à développer. Elle contient généralement trois éléments descriptifs de la fonctionnalité, sous la forme :

 En tant que <qui>, je veux <quoi> afin de <pourquoi>

• Le qui indique l'utilisateur du point de vue duquel on se place. Il s'agit souvent d'un rôle dans l'usage du produit (par exemple « élève » ou « enseignant » dans le cas d'un système d'apprentissage). Pour mieux illustrer la diversité des besoins, on peut également utiliser le concept de persona, c'est-à-dire une personne fictive, représentative de catégories d'usagers du produit, et à laquelle on peut s'identifier pour mieux comprendre ses attentes. L'identification et la description des personas se fait alors avant de commencer l'écriture des récits utilisateurs (par exemple « Odile est une enseignante qui utilise pour la première fois le système » )[7].
• Le quoi décrit succinctement la fonctionnalité ou le comportement attendu. Le but du récit n'est pas d'en fournir une explication exhaustive. Cette dernière est obtenue de façon interactive au cours d'une conversation avec les utilisateurs concernés ou leurs représentants[2].
• Le pourquoi permet d'identifier l'intérêt de la fonctionnalité et d'en justifier le développement. Il permet également de mieux évaluer la priorité du récit.

Lorsque des points importants sont identifiés au moment d'écrire un récit, on peut faire une annotation. Ceci permet de garder la phrase simple, tout en gardant à l'esprit ces points[7].

Chaque récit utilisateur doit être complété avec des critères d'acceptation. C'est une liste d'éléments qui permettront à l'utilisateur de confirmer que la fonctionnalité, une fois livrée, correspond effectivement aux attentes[2]. Le fait de définir ces critères à l'avance permet aussi d'assurer que la description de la fonctionnalité est suffisamment précise pour être réalisable.

Le récit utilisateur est selon le SWEBOK une technique d'élicitation des exigences.

Caractéristiques d'un récit

L'acronyme INVEST est souvent utilisé comme mnémonique des principales qualités d'un bon récit[5]^,[7]^,[12]:

• I pour Indépendant, c'est-à-dire la description du récit est indépendante des autres, de sorte que la réalisation de la fonctionnalité puisse être planifiée de façon autonome ;
• N pour Négociable, c'est-à-dire que le contenu détaillé n'est pas gravé dans le marbre mais peut être négocié avec l'utilisateur ;
• V pour « Valeur », c'est-à-dire que la fonctionnalité a de la valeur (est utile) pour l'utilisateur ;
• E pour Estimable, c'est-à-dire que le travail pour réaliser le récit peut être estimé ;
• S pour « Small » (petit), car le récit doit pouvoir être réalisé au cours d'une itération ;
• T pour Testable, c'est dire que les critères d'acceptation doivent être vérifiables en pratique.

Utilisation de récits et d'épopées dans un tableau Kanban

Exemples

En tant que vendeur en succursale,
je veux pouvoir rechercher mes clients par leur prénom et leur nom de famille afin de les retrouver rapidement lorsque je reçois un appel de leur part.

Critères d'acceptation :

• je peux rechercher par prénom sans le nom de famille
• je peux rechercher par nom de famille sans le prénom
• je peux rechercher par prénom et nom de famille en même temps
• je peux avoir des suggestions proches si je fais une erreur en écrivant

Exemple de récits utilisateur classés.

Les récits peuvent être utilisés conjointement avec les épopées et les thèmes.

Une épopée (« epic » en anglais) décrit un grand récit qui sera composé de nombreux récits utilisateurs. Une épopée correspond souvent à une fonctionnalité principale du produit, ou une nouvelle idée, dont les détails ne seront précisés que lorsqu'ils seront nécessaires[13]^,[14]. Cette approche permet d'éviter aux équipes de perdre du temps à décrire à l'avance et en détail des besoins.

Il y a donc une hiérarchie de fait entre les épopées et les récits qui la composent. Par ailleurs, les épopées peuvent elle-même être regroupées en « initiatives ».

Un thème est un sujet transverse. Contrairement aux épopées, un thème ne définit pas une hiérarchie, mais permet de relier des récits ayant des points communs, y compris lorsqu'ils appartiennent à des épopées différentes.

Principe de cartographie des récits utilisateurs

La cartographie de récits utilisateurs, ou « user story mapping » est une technique qui structure les récits autour d'un axe narratif qui exprime une vision d'ensemble sur le produit. Elle a été mise au point par Jeff Patton de 2005 à 2014 pour remédier à la dérive de certains projets qui sont noyés dans un flux de récits trop détaillés sans que la vision du produit ne se dégage[11].

La technique consiste à développer sur un axe narratif horizontal les grandes lignes du produit. Pour cela, on identifie d'abord les activités métier principales que l'on souhaite réaliser et qui peuvent engager plusieurs utilisateurs. On définit alors un niveau de détail supplémentaire avec les principales tâches, chacune réalisée par un utilisateur individuel. À partir de là, on procède avec les récits utilisateurs classiques, en plaçant sur l'axe vertical les récits qui détaillent les fonctionnalités souhaitées pour chaque tâche. Patton combine ainsi une structuration par objectifs typique des cas d'utilisation, tout en conservant la flexibilité et l'interactivité des récits utilisateurs et en recommandant le recours au personas.

Cette technique peut être initiée lors d'ateliers de découverte au cours desquels une vision est développée de manière interactive avec les utilisateurs. Des post-its permettent de présenter l'organisation existante des tâches, puis de réorganiser celles-ci en fonction du produit qui est conçu. Les récits utilisateurs sont alors enrichis par des descriptifs complémentaires, généralement visuels (graphiques, « wireframes », ou « storyboards »), pour imaginer de manière consensuelle, dans une optique de « design thinking », les grandes lignes du futur logiciel et identifier le produit minimum viable[15].

Une « job story », c'est-à-dire un « récit d'emploi » en français, est une variante qui considère que les besoins tiennent davantage du rôle métier de l'utilisateur et de ses objectifs que de sa personnalité[16]^,[17]^,[18]. Dans cette approche utilitaire et fonctionnelle, les personas sont évités, et la collecte des récits est organisée par emploi. Ils sont regroupés par rôle et prennent la forme:

 Quand <situation>, je veux <motivation>, de sorte que je puisse <résultat>

Le récit d'abuseur (jeu de mot en anglais entre « user story » et « abuser story ») est une variante utilisée pour intégrer la sécurité dès le début des développements. Ce type de récit présente les intentions d'un utilisateur malveillant que l'on cherchera à tenir en échec[19].

Le cas d'utilisation est un concept voisin. Il cherche tout comme le récit utilisateur à identifier les exigences d'un système en se focalisant sur l'utilisateur. Toutefois, il correspond en général à des objectifs de l'utilisateur et met de ce fait en jeu des scénarios potentiellement plus complexes, qui ne sont généralement pas réalisables en une seule itération. Lorsque les cas sont utilisés avec des méthodes Agile, ils nécessitent donc, dans leur forme classique, d'être complémentés par des récits utilisateurs plus fins et plus orientés vers les fonctionnalités[3]. La méthode a toutefois été modernisée avec les cas d'utilisation 2.0, qui organisent le découpage des scénarios en tranches implémentables à l'instar des récits utilisateurs[20].

La cartographie du parcours d'utilisateur (en anglais « user journey mapping ») est un concept voisin de la cartographie de récits utilisateurs. Son but est de mieux appréhender l'expérience utilisateur et d'identifier les points de frictions et les besoins non satisfaits, en focalisant l'axe narratif sur la chronologie des phases et actions que suit un même utilisateur pour atteindre ses objectifs[21]. Cette approche est notamment utilisée dans la conception participative et l'amélioration d'applications[22].

Lorsque les récits utilisateurs sont nombreux et indépendants, il peut être difficile d'entrevoir la logique d'ensemble du système, de comprendre comment les récits s'articulent entre eux et de prioriser leur développement[11]. La cartographie des récits utilisateurs peut pallier cette limitation.

Contrairement aux cas d'utilisation qui peuvent mettre en regard les intérêts de plusieurs utilisateurs, les récits sont focalisés seulement sur les besoins de l'utilisateur qui les produit. Plusieurs récits peuvent ainsi se contredire, ou répondre à des objectifs qui s'opposent. Il est alors nécessaire de négocier avec l'ensemble des utilisateurs impliqués pour trouver un consensus[23].

Les récits sont collectés auprès des utilisateurs. Il y a de ce fait un risque de ne pas couvrir l'ensemble des cas de figure en raison d'une connaissance incomplète des utilisateurs présents lors des conversations. De plus, les utilisateurs risquent de privilégier leurs propres intérêts aux dépens de la mission du système ou des intérêts de parties prenantes ne faisant pas partie des utilisateurs. C'est l'une des raisons attribuées à l'échec du projet C3 chez Chrysler où ont été inventés les récits utilisateurs[24]. Ces risques peuvent être mitigés par une analyse des parties prenantes et une approche structurée comme la cartographie, ainsi qu'avec une expertise de la collecte des récits pour guider les utilisateurs dans l'expression de leurs récits[25].