Qu’est-ce qu’une histoire d’utilisateur ?

Qu’est-ce qu’une histoire d’utilisateur ?

Une histoire d’utilisateur est une note qui capture ce que utilisateurfait ou a besoin de faire dans le cadre de son travail. Chaque histoire d’utilisateur se compose d’une brève description rédigée du point de vue de l’utilisateur, en langage naturel. Contrairement à la capture traditionnelle des exigences, l’histoire d’utilisateur se concentre sur ce dont l’utilisateur a besoin plutôt que sur ce que le système devrait livrer. Cela laisse de la place à une discussion plus approfondie sur les solutions, et aboutit à un système qui s’intègre réellement au flux de travail des clients, résolvant leurs problèmes opérationnels et, surtout, ajoutant de la valeur à l’organisation.

Concept des 3C

Les 3C se réfèrent aux trois aspects essentiels des bonnes histoires d’utilisateur. Ce concept a été proposé par Ron Jeffries, co-inventeur de la pratique des histoires d’utilisateur. Aujourd’hui, lorsque nous parlons d’histoires d’utilisateur, nous faisons généralement référence à ce type d’histoires composées de ces trois aspects.

1. Carte – Les histoires d’utilisateur sont rédigées sous forme de cartes. Chaque carte d’histoire d’utilisateur contient une courte phrase avec juste assez de texte pour rappeler à tous de quoi parle l’histoire.
2. Conversation – Les exigences sont trouvées et affinées grâce à des conversations continues entre les clients et l’équipe de développement tout au long du projet logiciel. Des idées et décisions importantes seront découvertes et enregistrées lors des réunions avec les parties prenantes.
   
3. Confirmation – ou encore appelé critères d’acceptation de l’histoire d’utilisateur. Lors de la discussion des exigences, le client indique non seulement ce qu’il souhaite, mais aussi les conditions et critères selon lesquels le logiciel fonctionnel sera accepté ou rejeté. Les cas définis sont rédigés sous forme de confirmation. Notez que la confirmation se concentre sur la vérification de la correction du travail correspondant à l’histoire d’utilisateur. Ce n’est pas un test d’intégration.
   

Comment identifier une histoire d’utilisateur ?

Les histoires d’utilisateur doivent être identifiées conjointement avec les parties prenantes, idéalement lors d’une réunion en personne. L’histoire d’utilisateur est un processus de découverte des exigences, et non un processus d’analyse préalable des exigences. Dans les approches traditionnelles de capture des exigences, l’analyste système essaie de comprendre les besoins des clients, puis prépare une spécification détaillée des exigences du système. Ce n’est pas ainsi que fonctionne l’approche des histoires d’utilisateur. Plutôt que de se concentrer sur la documentation, l’identification des histoires d’utilisateur ressemble davantage à un processus de prise de notes. À travers les discussions avec les utilisateurs, nous écoutons et comprenons leurs problèmes et besoins, puis notons leurs besoins sous forme d’histoires d’utilisateur en même temps. Ces histoires d’utilisateur deviendront la source des exigences. Les détails pourront être complétés au moment opportun, fournissant ainsi à l’équipe des références d’exigences « juste-assez » tout au long du processus de développement du projet.

Cartographie des processus métiers avec les histoires d’utilisateur

BPMN est l’un des outils les plus puissants pour l’analyse et la modélisation des processus métiers. Non seulement nous pouvons l’utiliser pour améliorer les processus, mais nous pouvons également identifier des histoires d’utilisateur à partir de ces processus destinés à être automatisés à travers les étapes suivantes :

1. Modélisez simplement le flux de travail de l’utilisateur à l’aide d’un diagramme de processus métier BPMN.
2. Parcourez le modèle de processus avec les utilisateurs.
3. Ensuite, analysez les activités métiers du problème, puis identifiez les histoires d’utilisateur liées au processus devant être automatisé, ce qui est également connu sous le nom de cartographie du processus métier vers l’histoire d’utilisateur.

Comment rédiger une histoire d’utilisateur ?

Lors de la rédaction d’une histoire d’utilisateur, essayez d’écrire dans la voix de l’utilisateur selon le modèle ci-dessous (ou du moins, assurez-vous que ce que vous avez écrit correspond à l’énoncé suivant) :

En tant que <rôle>, je veux <objectif métier> afin de <valeur métier/raison>.

Par exemple, en tant que client, je veux recevoir un SMS lorsque l’article est arrivé afin que je puisse va le chercher.

où :

1. <rôle> représente la personne, le système, le sous-système ou toute autre entité qui interagira avec le système à implémenter afin d’atteindre un objectif. Il ou elle tirera des valeurs de l’interaction avec le système.
2. <objectif métier> représente l’attente d’un utilisateur pouvant être réalisée grâce à l’interaction avec le système.
3. <valeur métier> représente la valeur derrière l’interaction avec le système.

Ce n’est pas une règle, mais une orientation qui vous aide à réfléchir à une histoire utilisateur en tenant compte des éléments suivants :

1. L’histoire utilisateur apportera de la valeur à quelqu’un ou à un groupe spécifique (par exemple, les clients).
2. L’histoire utilisateur répond à un besoin de l’utilisateur (par exemple, recevoir un SMS lors de l’arrivée de l’article)
3. Il existe une raison de soutenir la mise en œuvre de cette histoire utilisateur (par exemple, le client peut venir chercher l’article qu’il a acheté)

Chaque histoire utilisateur doit apporter de la valeur à quelqu’un. Mais parfois, la valeur est suffisamment évidente en lisant simplement l’objectif métier. Écrire la valeur comme partie de l’énoncé est fastidieux. Dans ce cas, nous allons simplement l’omettre. Voici quelques exemples :

En tant que client, je souhaite régler mon paiement en utilisant une carte de créditafin que je puisse utiliser ma carte de crédit pour les achats en ligne.

En tant qu’utilisateur, je souhaite effectuer une recherche en saisissant le nom de mon amiafin que je puisse trouver mon ami grâce à son nom.

Peu importe la manière dont vous écrivez une histoire utilisateur, il y a deux points que vous devez garder à l’esprit. Premièrement, une histoire utilisateur doit être rédigée du point de vue de l’utilisateur. Deuxièmement, gardez la description « juste assez ». Évitez d’ajouter trop de détails au début d’un projet logiciel. Plus tard, vous aurez l’occasion de raffiner et de préciser l’histoire utilisateur afin qu’elle devienne quelque chose que les développeurs peuvent utiliser dans la conception et la mise en œuvre.

Cycle de vie d’une histoire utilisateur

Dans un sens large, il existe six états principaux pour chaque histoire utilisateur tout au long d’un projet logiciel :

1. En attente – À travers la communication entre l’utilisateur et l’équipe projet, les histoires utilisateurs sont identifiées. À cet état, les histoires utilisateurs ne comportent rien de plus qu’une brève description du besoin de l’utilisateur. Aucune discussion détaillée sur les exigences, aucune logique système et aucun design d’écran n’ont encore été établis. En réalité, le seul objectif de l’histoire utilisateur, pour l’instant, est simplement de rappeler à toutes les parties d’une discussion future concernant la demande de l’utilisateur écrite dans cette histoire (fiche). Il est possible que l’histoire utilisateur soit abandonnée à l’avenir.
2. À faire – Suite à une discussion entre différents intervenants, les histoires utilisateurs à traiter au cours des prochaines semaines sont déterminées, puis placées dans une période limitée appelée sprint. Ces histoires utilisateurs sont dites être dans l’état À faire. Aucune discussion détaillée n’a encore été menée à cet état.
3. En discussion – Lorsqu’une histoire utilisateur est dans l’état En discussion, l’utilisateur final communique avec l’équipe de développement afin de confirmer les exigences et de définir les critères d’acceptation. L’équipe de développement consignera les exigences ou toute décision prise sous forme de notes de conversation. Un spécialiste UX peut créer des maquettes ou des storyboards pour permettre à l’utilisateur de prévisualiser les fonctionnalités proposées dans des maquettes visuelles, et de les ressentir. Ce processus est connu sous le nom de conception de l’expérience utilisateur (UX design).
   
4. En développement – Une fois que les exigences sont clarifiées, l’équipe de développement concevra et mettra en œuvre les fonctionnalités pour répondre aux demandes de l’utilisateur.
5. Confirmation – Une fois que l’équipe de développement a mis en œuvre une histoire utilisateur, celle-ci sera confirmée par l’utilisateur final. Il/elle aura accès à l’environnement de test ou à un produit logiciel partiellement achevé (parfois appelé version alpha) afin de confirmer la fonctionnalité. La confirmation sera effectuée sur la base des éléments de confirmation rédigés lors de la détaillisation de l’histoire utilisateur. Jusqu’à ce que la confirmation soit effectuée, l’histoire utilisateur est considérée comme étant dans l’état de Confirmation.
6. Terminé – Enfin, lorsque la fonctionnalité est confirmée comme terminée, l’histoire utilisateur est considérée comme étant dans l’état Terminé. Généralement, c’est la fin de l’histoire utilisateur. Si l’utilisateur a une nouvelle exigence, qu’il s’agisse d’une nouvelle fonctionnalité ou d’une amélioration de l’histoire utilisateur terminée, l’équipe créera une nouvelle histoire utilisateur pour la prochaine itération.

Détailler l’histoire utilisateur – Quand et pourquoi ?

Un élément clé qui distingue l’histoire utilisateur des approches traditionnelles de capture des exigences est que l’approche des histoires utilisateurs divise l’identification du problème et de la solution en deux étapes, réalisées à différentes phases d’un projet logiciel. Alors que les problèmes et une compréhension sommaire des demandes des utilisateurs sont identifiés au début du projet logiciel, les détails des exigences du système ne sont déterminés qu’avant le début de la conception et de la mise en œuvre. Voici certains avantages de cette organisation :

1. Capable de répondre aux besoins les plus récents des utilisateurs, car les exigences sont détaillées juste avant la mise en œuvre, plutôt que de tout conclure dès le début.
2. Capable d’identifier plus facilement les bonnes exigences, car à la fois les problèmes et les solutions feront l’objet de discussions détaillées. Dans les approches traditionnelles, comme les détails de toutes les exigences doivent être trouvés dès le début du projet, les « exigences préalables » pourraient avoir évolué au fil du temps, entraînant une grande perte d’efforts d’analyse.
3. – D’un autre côté, les histoires utilisateurs jugées non valides peuvent être facilement abandonnées. Vous ne perdez pas beaucoup de temps à des études et documents préalables.

Comment utiliser efficacement l’histoire utilisateur ?

Tout comme de nombreuses autres méthodologies de développement logiciel, si vous appliquez correctement l’histoire utilisateur dans votre projet logiciel, vous serez en mesure de produire un système logiciel de qualité tout en gagnant la confiance et la satisfaction des clients. Voici quelques points à garder à l’esprit lors de l’utilisation de l’histoire utilisateur :

1. Gardez la description de l’histoire utilisateur brève.
2. Pensez du point de vue de l’utilisateur final lors de l’écriture d’une histoire utilisateur.
3. Un cas d’utilisation (UML) représente un objectif métier. La capacité à regrouper les histoires utilisateurs sous des cas d’utilisation vous permet de vous assurer qu’une histoire utilisateur satisfait un objectif métier, autrement dit, qu’elles partagent le même objectif système. Elle sert de placeholder pour vous permettre de gérer, planifier et prioriser les histoires utilisateurs de manière plus aisée.
4. Les éléments de confirmation doivent être définis avant de commencer le développement
5. Estimez l’histoire utilisateur avant la mise en œuvre pour vous assurer que la charge de travail de votre équipe reste maîtrisée.
6. Les exigences sont trouvées avec les utilisateurs finaux, et non par l’utilisateur final ou uniquement par l’équipe de développement. Entretenir une bonne relation avec les utilisateurs finaux constitue une situation gagnant-gagnant pour les deux parties.
7. La communication est toujours importante pour comprendre ce que l’utilisateur final souhaite.

Visual Paradigm fournit tous les outils dont vous avez besoin dans développement logiciel agile, qui inclut outil de diagramme de cas d’utilisation UML, (agile) histoire utilisateur, sprint, storyboard et maquettes pour la conception UX, outil de gestion des tâches, etc.