Témoignage d’utilisateur : 3C

Le concept de user story

Les user stories sont une méthode légère pour capturer rapidement le « qui », le « quoi » et le « pourquoi » des exigences du produit. En termes simples, les user stories sont des idées qui expriment les besoins souhaités par les utilisateurs. Les user stories sont courtes et chaque élément contient généralement moins de 10 ou 15 mots. Les user stories sont des listes de tâches qui vous aident à identifier les étapes le long du chemin du projet. Ils aident à garantir que votre processus et le produit qui en résulte répondent à vos exigences.

Concept de ce genre de chose, j’aime dire la façon de comprendre et d’expliquer le mot;

user story = utilisateur + story = personne + story + événement

Autrement dit, ce qu’une personne veut faire pour quelle raison, distiller les trois éléments est qui, pourquoi, quoi. du point de vue de l’utilisateur est une brève description utilisée pour confirmer l’utilisateur et les besoins de l’utilisateur.

Les trois éléments de la user story

Les user stories sont utilisées dans le processus de développement logiciel comme une forme d’expression pour décrire les exigences. Afin d’uniformiser l’expression des user stories et de faciliter la communication, les user stories sont généralement exprimées au format suivant :

En tant que <rôle d’utilisateur>, je veux <terminer l’activité>, afin de <réaliser la valeur>.

Une user story complète contient trois éléments.

1. persona ( who? ): qui veut l’utiliser
2. action ( quoi? ): quelle action accomplir
3. Valeur : ( pourquoi ? ) faire cela et quelle valeur peut être apportée en faisant cela

Trois principes 3C

Les informations descriptives des user stories sont écrites sur des cartes papier de manière manuscrite traditionnelle, ainsi Ron Jeffries (2001) appelle ces trois aspects 3C :

1. carte (Carte ) ,
2. conversation (conversation ) et
3. confirmation ( Confirmation ).

Carte : Les user stories sont généralement écrites sur de petites cartes avec une brève description de l’histoire, des règles et des critères d’achèvement.

Le recto de la carte contient la description de l’histoire au format : En tant que <rôle>, je veux <terminer l’activité> afin de <réaliser la valeur> décrire le besoin ; le verso de la carte contient les règles et les critères d’achèvement pour compléter la user story au format : Étant donné…Quand…Alors.

Conversation : Les détails derrière la user story proviennent de la communication avec le client ou le propriétaire du produit ; assurez-vous que toutes les parties comprennent correctement l’histoire.

Confirmation : confirmez que la user story a été complétée correctement via les tests d’acceptation.

• Rédaction de user stories générales
• Qu’est-ce que la cartographie des histoires d’utilisateurs ?
• Comment gérer les User Stories avec Story Map ?
• Prioriser les user stories