Dans ce tutoriel, vous apprendrez une partie importante de l’approche Agile dans le développement logiciel : les histoires d’utilisateur.

Je vais vous expliquer ce que sont les histoires d’utilisateur, les pièges courants que j’ai rencontrés lors de la création d’histoires d’utilisateur, et les cadres qui existent pour valider si votre histoire d’utilisateur est « bonne ».

Voici ce que nous allons couvrir :

Les débuts de l’Agile

Il est probable que vous ayez entendu parler du Développement Agile et des User Stories. Mais si ce n’est pas le cas, permettez-moi de vous donner une brève leçon d’histoire :

Les User Stories font partie d’un concept plus large appelé méthodologies Agile.

Les méthodologies Agile existent depuis 2001, lorsque 17 ingénieurs logiciels respectés se sont réunis dans une station de ski de l’Utah et ont créé le désormais célèbre Manifeste Agile.

Si les noms tels que Robert Martin, Martin Fowler et Kent Beck ne vous disent rien, une fois que vous aurez terminé cet article, allez les chercher. Ils possèdent une mine de connaissances et ont offert au monde du logiciel une manière plus fluide de livrer des projets, appelée Agile.

Qu’est-ce que l’Agile ?

L’Agile est plus une façon de penser qu’une méthode prescrite. Des méthodes prescrites existent, telles que Scrum et Kanban, mais l’Agile est un concept.

L’Agile favorise la collaboration, les retours rapides et la livraison fréquente de valeur à l’utilisateur.

La pensée Agile encourage la flexibilité dans la planification des projets, ce qui contraste fortement avec son concurrent de l’époque, la planification de projet en cascade, qui était très rigide quant à ce qui était livré et quand.

Les méthodologies Agile encouragent à faire juste assez de recherches au début pour lancer le projet, puis à apprendre, itérer et modifier la conception et le livrable au besoin tout au long du projet jusqu’à ce que le code final soit livré. Cette approche de « changer et apprendre au fur et à mesure » est appelée « planification adaptative ».

Agile promeut la livraison rapide et fréquente de quelque chose de valeur, généralement sous la forme de livraison de code en production à la fin de chaque « sprint » de deux semaines. Cela, encore une fois, est très différent de la planification traditionnelle en cascade qui nécessiterait souvent des mois de développement avant qu’un changement visible par l’utilisateur puisse être livré en production.

Un autre aspect clé de l’Agile est l’accent qu’il met sur la collaboration étroite et fréquente entre les parties prenantes. Produit, QA, Ingénierie et Ventes contribuent largement et fournissent un retour constant sur le projet tout au long de son cycle de vie.

Maintenant que vous en savez un peu plus sur le fonctionnement de l’Agile, plongeons plus profondément dans la manière dont nous validons la valeur pour l’utilisateur.

Entrez dans l’Histoire Utilisateur.

Qu’est-ce qu’une Histoire Utilisateur ?

Une histoire utilisateur est une manière en anglais simple de relier l’ingénieur à l’objectif final du logiciel.

Elle est conçue pour qu’une personne non technique puisse la lire et comprendre ce qui est livré, et pour qu’un ingénieur puisse la consulter et voir la valeur et comment valider que cette valeur a été livrée.

Structure d’une Histoire Utilisateur

En tant que [type d’utilisateur], quand je [effectue une action], [résultat attendu]

Au plus basique, c’est tout.

Vous mettez l’accent sur l’utilisateur final et la « valeur » que vous allez délivrer.

Explorons les entrées :

  • Type d’utilisateur : Il n’y a pas de « utilisateur » unique qui convient à tous. Vous avez des « utilisateurs administrateurs », vous avez des « utilisateurs connectés », vous avez des « utilisateurs avec la permission X » ou des « utilisateurs dans le rôle Y ». Il s’agit de préciser qui effectue l’action.

  • Effectuer une action : Que fait l’utilisateur ? Clique-t-il sur le bouton « connexion » ? Supprime-t-il un enregistrement ? Soumet-il un formulaire ?

  • Résultat attendu : Une fois que votre utilisateur a effectué l’action, que devrait-il se passer ? S’il a cliqué sur « connexion » avec l’adresse email et le mot de passe corrects, où devrait-il être dirigé ? S’il a cliqué sur « connexion » avec une adresse email et un mot de passe incorrects, que devrait-il se passer ?

Exemple d’histoires d’utilisateur :

Regardons des exemples d’histoires d’utilisateur pour une page de connexion.

Il n’y a rien de mieux que des exemples.

Mettons en place le contexte. Vous avez une page de connexion avec une zone de texte pour une adresse e-mail et une zone de texte pour un mot de passe. Vous avez un bouton de soumission. C’est tout.

Quelles sont les différentes permutations qui peuvent se produire sur cette page du point de vue de l’utilisateur ?

En tant qu’utilisateur connecté, lorsque la page se charge, je suis redirigé vers la page d’accueil des utilisateurs connectés.

Si je suis déjà connecté, je ne veux pas avoir à ressaisir mes informations, redirigez-moi simplement vers la page d’accueil des utilisateurs connectés.

En tant qu’utilisateur non connecté, lorsque j’entre l’adresse e-mail correcte mais le mot de passe incorrect et que je clique sur Connexion, un message d’erreur apparaît.

Je suis un utilisateur qui n’est pas déjà connecté, et j’ai saisi des informations incorrectes. Je ne devrais pas être connecté.

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail et un mot de passe incorrects et que je clique sur connexion, un message d’erreur apparaît.

Encore une fois. Je ne suis pas un utilisateur connecté. J’ai saisi des informations incorrectes, je ne devrais pas être connecté.

En tant qu’utilisateur non connecté, lorsque j’entre l’adresse e-mail et le mot de passe corrects et que je clique sur connexion, je suis redirigé vers la page d’accueil des utilisateurs connectés.

Cette fois, je ne suis pas déjà connecté, j’entre les bonnes informations et je clique sur connexion. Je suis connecté au système.

Pouvez-vous voir comment tout cela est centré sur l’utilisateur ?

Vous remarquerez peut-être que certains des « comportements attendus » ci-dessus ne sont pas entièrement définis. Nous aborderons cela plus tard dans les critères d’acceptation.

Comment créer de bonnes User Stories

Il existe un bon modèle appelé le modèle INVEST qui montre très simplement comment savoir si vos user stories sont de qualité.

Modèle INVEST:

  • Indépendant : Peut être développé séparément.

  • Négociable : Ouvert à la discussion et au changement.

  • Valeureux : Apporte de la valeur à l’utilisateur.

  • Estimable : Peut être estimé en termes d’effort.

  • Small : S’inscrit dans un sprint.

  • Testable : A des critères d’acceptation clairs.

Appliquons ce modèle INVEST à l’un des exemples de user stories ci-dessus :

En tant qu’utilisateur non connecté, lorsque je saisis la bonne adresse e-mail et le mot de passe puis clique sur connexion, je suis redirigé vers la page d’accueil des utilisateurs connectés.

(Je vais faire quelques hypothèses ici, car il s’agit d’une base de code théorique et d’un projet théorique)

Cette histoire est-elle indépendante? Je dirais que oui. C’est une petite histoire qui implique seulement quelques composants qui existent probablement déjà. Cependant, si la base de données n’a pas encore été créée pour le projet, cela nous donnerait une dépendance. Cela ne serait plus indépendant.

Est-elle négociable? Eh bien, encore une fois, oui. Cette histoire pourrait facilement être modifiée pour rediriger vers la page de profil de l’utilisateur plutôt que vers sa page d’accueil.

Cette histoire est certainement valable. Une fois mise en œuvre, l’utilisateur peut se connecter. Si l’histoire était :

En tant qu’utilisateur non connecté, lorsque j’entre l’adresse email et le mot de passe corrects et que je clique sur se connecter, rien ne se passe

Cela ne serait pas valable. L’utilisateur n’en tirerait rien.

L’histoire est-elle estimable? Encore une fois, nous devons faire certaines hypothèses dans ce scénario fictif, mais j’espère certainement que cela serait facilement estimé. C’est une histoire concise, impliquant peu de composants, dans un domaine que tout le monde connaît et avec des critères d’acceptation clairs.

L’histoire est certainement petite. Il y a peu d’ambiguïté sur ce qui doit être fait, il n’y a qu’un seul chemin utilisateur et des résultats clairs. Regardons une histoire qui serait trop grande :

En tant qu’utilisateur non connecté, la page de connexion devrait fonctionner comme prévu.

Comme discuté plus haut dans cet article, il existe de nombreuses façons dont la page de connexion peut et devrait fonctionner. « Devrait fonctionner comme prévu » semble couvrir toutes ces permutations. Cela serait trop grand pour être efficacement dimensionné en tant qu’histoire, et probablement trop grand pour être complété en un seul sprint.

L’histoire est certainement testable. Il existe des actions claires à entreprendre par l’utilisateur qui ont un résultat clair. Cette histoire utilisateur peut être couverte par des tests unitaires, des tests d’intégration et des tests manuels.

On dirait que nous avons créé une bonne histoire utilisateur!

Si vous utilisez la structure que j’ai définie ci-dessus, et que l’histoire répond aux critères du modèle INVEST, c’est probablement une bonne histoire.

Écueils courants dans la création d’histoires utilisateur

J’ai vu des histoires utilisateur mal tourner par le passé où les gens ont omis quelques aspects cruciaux de l’histoire utilisateur:

Se concentrer sur les aspects techniques

Comme mes exemples le montrent ci-dessus, l’histoire utilisateur est non technique.

Il ne devrait y avoir aucune référence à un nom de service, un nom de base de données, ou une validation basée sur quelque chose que l’utilisateur ne peut pas voir.

Dès que votre histoire n’est plus compréhensible par l’utilisateur final, vous avez fait une erreur.

Concentrez-vous sur ce que l’utilisateur va faire, et sur ce que l’utilisateur va voir.

Regardons un exemple d’histoire axée sur la technique:

En tant qu’utilisateur non connecté, lorsque je clique sur le lien mot de passe oublié avec une adresse e-mail correcte, un enregistrement est ajouté dans une table de base de données indiquant que le lien de réinitialisation du mot de passe a été envoyé.

Cette histoire ne peut pas être vérifiée par un utilisateur et les utilisateurs non techniques peuvent ne pas comprendre ce que cela signifie.

Corrigeons cela:

En tant qu’utilisateur non connecté, lorsque je clique sur le lien mot de passe oublié avec une adresse e-mail correcte, un e-mail est envoyé à l’adresse e-mail fournie avec un lien de réinitialisation de mot de passe oublié

Les utilisateurs non techniques peuvent comprendre cela et cela met l’accent sur l’utilisateur, pas sur le produit.

Collaboration des parties prenantes

L’Agile est collaboratif.

Les user stories ont besoin de l’apport du produit, des BA, des QA, des ingénieurs et, surtout, des utilisateurs.

C’est ainsi que vous vous assurerez de livrer ce que l’utilisateur veut. Beaucoup de mains rendent le travail léger.

Si, par exemple, seule une équipe d’ingénierie venait avec des user stories, elles pourraient ressembler à ceci :

En tant qu’utilisateur connecté, lorsque la page se charge, je suis redirigé vers la page d’accueil pour les utilisateurs connectés

En tant qu’utilisateur non connecté, lorsque j’entre l’adresse e-mail correcte mais le mot de passe incorrect et que je clique sur Connexion, un message d’erreur apparaît

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail et un mot de passe incorrects et que je clique sur connexion, un message d’erreur apparaît.

Et c’est génial. Mais maintenant, impliquons le QA, qui vient d’une perspective différente car ils ont des expériences différentes avec le logiciel :

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail correcte en hébreu et un mot de passe correct, je suis redirigé vers la page d’accueil

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail et un mot de passe corrects et que je clique plusieurs fois sur connexion, je suis redirigé vers la page d’accueil

Génial. Nous obtenons maintenant un ensemble de user stories plus complet qui couvre plus de situations. Mais que se passe-t-il si nous impliquons le produit ?

En tant qu’utilisateur non connecté, lorsque la page se charge, mon gestionnaire de mots de passe devrait précharger mon nom d’utilisateur et mon mot de passe, lorsque je clique sur connexion, je suis redirigé vers la page d’accueil

L’équipe produit connaît les utilisateurs. Ils savent que les gens utilisent vraiment des gestionnaires de mots de passe. Nous devons nous assurer que lorsque l’utilisateur ne tape rien (puisque le texte est chargé par le gestionnaire de mots de passe), la connexion fonctionne toujours correctement.

Histoires Utilisateur Vagues

L’idée derrière une bonne histoire utilisateur est que tout le monde, quel que soit son niveau d’expertise, peut la comprendre.

Si vous avez rédigé une histoire utilisateur qui peut être interprétée de 10 manières différentes par 10 personnes différentes, vous êtes un peu dans l’erreur.

J’ai mentionné ci-dessus que je toucherais aux critères d’acceptation, et maintenant est le moment de le faire.

Réexaminons la suivante histoire utilisateur :

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail et un mot de passe incorrects et que je clique sur connexion, un message d’erreur apparaît.

Il y a de la vague là-dedans.

Quel message doit apparaître ? Lorsque la page se recharge après une tentative de connexion invalide, la zone de texte du nom d’utilisateur doit-elle être réinitialisée à vide, ou préremplie avec la valeur précédemment saisie ? Que signifie « adresse e-mail incorrecte » ? Une adresse e-mail qui n’a jamais été vue auparavant, ou une adresse e-mail qui n’est pas valide pour le moment (non payée, abonnement annulé, etc.)

Comme vous pouvez le voir, les détails comptent.

Cette histoire utilisateur est un exemple simple assez artificiel et j’ai réussi à trouver beaucoup de questions à ce sujet.

Résolvons le problème :

En tant qu’utilisateur non connecté, lorsque j’entre une adresse e-mail qui n’est pas enregistrée dans le système, lorsque je clique sur connexion, un message d’erreur apparaît.

Cela a éliminé les questions concernant l’action de l’utilisateur mais n’a pas résolu le problème du message d’erreur attendu.

Entrez les critères d’acceptation.

Dans l’histoire utilisateur, vous devez avoir un ensemble de critères d’acceptation qui définit si la mise en œuvre de l’histoire utilisateur est conforme aux attentes.

Des choses comme :

  • Message d’erreur : « Adresse e-mail ou mot de passe invalide »

  • La zone de texte de l’adresse e-mail et du mot de passe est réinitialisée à vide lors du rechargement

  • L’utilisateur ne peut pas accéder aux pages où la connexion est requise

  • L’utilisateur se voit proposer une suggestion de « mot de passe oublié ».

Les critères d’acceptation indiquent ce qui est attendu de la mise en œuvre.

Comment commencer avec les histoires utilisateurs

Commencez petit.

Vous ne serez pas parfait dans l’affinement et la création d’histoires utilisateurs au départ.

Créer des histoires utilisateurs est autant un art qu’une science. La pratique rend parfait.

La création d’histoires utilisateurs devrait se faire en groupe. Souvent, cela se fait avec l’approche des « 3 Amigoes », où vous aurez un ingénieur, une personne produit et un QA qui s’assoiront ensemble et réfléchiront à différentes permutations que vous devez prendre en charge.

Une fois que vous avez livré votre projet, faites un retour en arrière. Examinez ce qui manque dans vos récits utilisateurs. Il y aura des bugs que les utilisateurs trouveront, que l’assurance qualité (AQ) et les tests utilisateurs (UAT) découvriront, et ceux-ci sont soit dus à des lacunes dans vos récits utilisateurs, soit à des lacunes dans vos tests. Dans tous les cas, vous devriez en tirer des leçons pour la prochaine fois.

Conclusion

L’Agile est collaboratif. Le Scrum est collaboratif. Créer des récits utilisateurs est collaboratif. N’oubliez pas cela.

Plus vous avez de personnes provenant de différents domaines d’expertise qui participent à la création de récits utilisateurs, plus vous êtes susceptibles de couvrir l’ensemble des workflows.

L’utilisateur est au centre. Si vous incluez un jargon que votre utilisateur ne comprend pas, repensez le récit utilisateur.

Vous ne serez pas parfait dès le départ, mais au fur et à mesure que vous en ferez de plus en plus, vous deviendrez plus rapide et plus efficace. Prenez cela d’une personne qui fait cela depuis plus de 10 ans. La différence de vitesse et de qualité de ma création de récits utilisateurs aujourd’hui par rapport à il y a 10 ans est énorme.

Consultez mes articles de blog sur mon site web, Just Another Tech Lead, ou inscrivez-vous à ma newsletter hebdomadaire ici.