Récit utilisateur
Un récit utilisateur, ou « user story » en anglais, est une description simple d’un besoin ou d’une attente exprimée par un utilisateur et utilisée dans le domaine du développement de logiciels et de la conception de nouveaux produits pour déterminer les fonctionnalités à développer.
Origine modifier
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].
Principes modifier
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 modifier
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 dans les méthodes agiles modifier
Dans les méthodes agiles, les récits utilisateurs servent d'éléments du « backlog », qui est une liste qui définit de manière dynamique le « reste à faire ».
L'estimation des récits est utilisée pour planifier le travail d'une itération. Les techniques habituellement utilisées sont collectives et basées sur:
- le temps idéal[1], c'est-à-dire une durée de travail théorique si le(s) développeur pouvait travailler à plein temps sur le récit sans jamais être interrompu par aucune autre obligation;
- en points de récit[7] ( « story points » en anglais). Ceux-ci sont une mesure abstraite représentative de la complexité d'un récit, par exemple un nombre dans une échelle progressive, ou sous forme de taille de T-shirt, de XS à XXL.
S'il apparaît que le récit est trop complexe pour une seule itération, il est alors scindé en plusieurs récits plus petits.
Exemples modifier
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
Épopée et thèmes modifier
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.
Cartographie de récits utilisateurs modifier
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].
Variantes et concepts voisins modifier
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 mots 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].
Critiques modifier
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].
Références modifier
- (en) Beck, Kent., Extreme programming eXplained : embrace change, Boston, Addison-Wesley, , 190 p. (ISBN 0-201-61641-6 et 9780201616415, OCLC 41834882, lire en ligne)
- (en) « Essential XP: Card, Conversation, Confirmation », sur ronjeffries.com, (consulté le ).
- (en) Martin Fowler, « Use Cases And Stories », sur martinfowler.com, (consulté le ).
- (en) Wake, William C., Extreme programming explored, Boston, Addison Wesley, , 159 p. (ISBN 0-201-73397-8 et 9780201733976, OCLC 46937693, lire en ligne)
- (en-US) Bill Wake, « INVEST in Good Stories, and SMART Tasks », sur XP123, (consulté le ).
- Mike Cohn, qui popularisera l'acronyme INVEST, attribue dans son ouvrage la paternité de INVEST à Bill Wake.
- (en) Cohn, Mike, User stories applied : for agile software development, Addison-Wesley, (ISBN 0-321-20568-5 et 9780321205681, OCLC 54365622, lire en ligne)
- (en) Martin Fowler, « User Story », sur martinfowler.com, (consulté le ).
- (en) Jeff Patton, « t's All In How You Slice It », Better Software Magazine, , p. 16-22,40 (lire en ligne)
- « The New User Story Backlog is a Map », sur pattonassociates.com, .
- (en) Patton, Jeff, et Economy, Peter (préf. Martin Fowler, Alan Cooper, et Marty Cagan), User story mapping : Discover the Whole Story, Build the Right Product, O'Reilly, , 276 p. (ISBN 978-1-4919-0490-9, 1491904909 et 1491904860, OCLC 880566740, lire en ligne)
- (en) U.S. General Services Administration, « Writing Effective User Stories - Tech at GSA », sur tech.gsa.gov (consulté le ).
- (en) U.S. General Services Administration, « Glossary - Tech at GSA », sur tech.gsa.gov (consulté le ).
- Constantin Guay, « Différences entre épiques, histoires, thèmes et fonctionnalités », sur const.fr, (consulté le ).
- (en) U.S. General Services Administration, « 18F: Digital service delivery | Buying better digital products part 3: Mapping user stories », sur 18f.gsa.gov (consulté le ).
- « Une méthode différente des User Stories pour raconter les besoins utilisateurs », sur Newflux, Actualité UX & UI Design, (consulté le ).
- (en) Katherine Lazarevich, « How to Document Chatbot Requirements - Chatbots Magazine », sur Medium, (consulté le ).
- (en) « User and job stories - Digital Guides », sur guides.service.gov.au (consulté le ).
- Agence Nationale de la Sécurité des Systèmes d'Information, « Agilité et sécurité numériques : méthode et outils à l’usage des équipes projet (publication téléchargeable) », sur ANSSI, (consulté le ).
- (en) Dr. Ivar Jacobson, Ian Spence et Kurt Bittner, « Use-Case 2.0 ebook », sur Ivar Jacobson International, (consulté le ).
- Walter, Stéphanie, « Introduction aux « User Journey Maps » », sur stephaniewalter.design, Blog, (consulté le ).
- (en) « Subversive participatory design | Proceedings of the 14th Participatory Design Conference: Short Papers, Interactive Exhibitions, Workshops - Volume 2 », sur dl.acm.org (DOI 10.1145/2948076.2948085, consulté le ).
- « User Story », sur c2.com (consulté le ).
- (en) Stephens, Matt,, Extreme programming refactored : the case against XP, Apress, ©2003, 432 p. (ISBN 978-1-4302-0810-5 et 1430208104, OCLC 63181890, lire en ligne)
- (en) Oz, Effy., Management information systems, Thomson Course Technology, (ISBN 1-4188-3597-8, 9781418835972 et 1418836699, OCLC 69672643, lire en ligne), p.400
Voir aussi modifier
Bibliographie modifier
- (en) Mike Cohn, User stories applied : For Agile Software Development, Addison-Wesley, , 268 p. (ISBN 978-0-321-20568-1, lire en ligne)
- Jeff Patton (trad. de l'anglais), Le story mapping : Visualisez vos user stories pour développer le bon produit [« User Story Mapping »], Paris, Dunod, , 247 p. (ISBN 978-2-10-074030-7)
