Récits utilisateur

Les récits utilisateur ne sont pas des documents d'exigences. Ce sont des espaces réservés pour des conversations.

Ron Jeffries a capturé cela sous la forme des « 3 C » :

Carte : Une brève description qui tient sur une fiche. « En tant qu'utilisateur, je veux réinitialiser mon mot de passe afin de pouvoir retrouver l'accès à mon compte. »

Conversation : Le dialogue entre les développeurs et les clients qui étoffe les détails. Que signifie « réinitialiser » ? Lien par courriel ? Code par texto ? Questions de sécurité ?

Confirmation : Les critères d'acceptation qui vous indiquent quand le récit est terminé. « Étant donné un courriel valide, lorsque je clique sur "réinitialiser le mot de passe", alors je reçois un courriel avec un lien de réinitialisation dans la minute. »

La carte n'est pas l'exigence. La conversation est l'exigence. La carte est juste un rappel pour avoir la conversation.

Le format classique du récit est :

En tant que [type d'utilisateur] Je veux [une capacité] Afin de [valeur métier]

Par exemple :

• En tant qu'acheteur, je veux filtrer les produits par prix afin de pouvoir trouver des articles dans mon budget.
• En tant qu'administrateur, je veux exporter les données utilisateur en CSV afin de pouvoir analyser les tendances dans Excel.
• En tant qu'invité, je veux passer à la caisse sans créer de compte afin de pouvoir acheter rapidement.

La clause « afin de » est cruciale. Elle explique pourquoi la fonctionnalité compte. Cela aide les développeurs à prendre de bonnes décisions concernant l'implémentation et aide les propriétaires de produit à prioriser.

Les mauvais récits omettent le pourquoi :

• « En tant qu'utilisateur, je veux un bouton bleu. » (Pourquoi ? Que fait-il ?)
• « Implémenter la fonctionnalité de recherche. » (Pour qui ? Quelle valeur ?)

Les bons récits relient les fonctionnalités à la valeur :

• « En tant que client régulier, je veux recommander mon dernier achat afin de pouvoir acheter à nouveau sans chercher. »

L'acronyme INVEST décrit les qualités de bons récits :

Indépendant : Les récits peuvent être développés dans n'importe quel ordre. Aucune dépendance entre les récits.

Négociable : La portée est flexible. Les détails sont négociés par la conversation.

Valeur : Chaque récit apporte de la valeur aux utilisateurs. Pas de « récits techniques » sans bénéfice utilisateur.

Estimable : L'équipe peut estimer sa taille. Sinon, le récit nécessite une clarification ou une division.

Small (Petit) : Un récit devrait prendre moins d'une semaine de travail. Idéalement quelques jours.

Testable : Il y a des critères d'acceptation clairs. Vous pouvez vérifier quand c'est terminé.

Lorsqu'un récit viole INVEST, corrigez-le :

• Récits dépendants : Combinez-les ou brisez la dépendance
• Récits volumineux : Divisez en morceaux plus petits
• Récits non estimables : Faites d'abord un spike pour réduire l'incertitude
• Récits non testables : Clarifiez les critères d'acceptation

Les récits volumineux doivent être divisés. Mais comment ?

Diviser par étape de flux de travail : « L'utilisateur peut compléter la caisse » →

• L'utilisateur peut ajouter des articles au panier
• L'utilisateur peut entrer l'adresse de livraison
• L'utilisateur peut entrer les informations de paiement
• L'utilisateur peut confirmer et passer la commande

Diviser par variation de données : « L'utilisateur peut payer pour la commande » →

• L'utilisateur peut payer par carte de crédit
• L'utilisateur peut payer par PayPal
• L'utilisateur peut payer par carte-cadeau

Diviser par opération : « L'utilisateur peut gérer son profil » →

• L'utilisateur peut voir son profil
• L'utilisateur peut modifier son nom
• L'utilisateur peut changer son courriel
• L'utilisateur peut supprimer son compte

Diviser par performance : « La recherche retourne des résultats rapidement » →

• La recherche retourne des résultats (n'importe quelle vitesse)
• La recherche retourne des résultats en moins de 2 secondes

Chaque récit divisé devrait être déployable indépendamment. Si vous ne pouvez pas déployer un support partiel de carte de crédit (seulement Visa, pas Mastercard), c'est quand même une division — vous livrez de la valeur de manière incrémentale.

Cela vaut la peine de répéter : les récits ne sont pas des spécifications.

Les documents d'exigences traditionnels tentent de spécifier chaque détail à l'avance. Cela échoue parce que :

• Vous ne pouvez pas connaître tous les détails avant de commencer
• Les documents écrits sont interprétés différemment par différents lecteurs
• Les spécifications deviennent obsolètes à mesure que la compréhension change
• Elles découragent la conversation

Les récits embrassent l'incertitude. La carte capture l'intention. La conversation remplit les détails juste à temps. La confirmation vérifie la compréhension.

Le client reste impliqué tout au long. Lorsque les développeurs ont des questions, ils demandent au client — pas au document. Cela maintient l'équipe alignée et s'adapte à l'apprentissage.

Les récits encouragent également le report des décisions. Vous n'avez pas à décider de chaque cas limite à l'avance. Gérez d'abord le chemin principal. Lorsque vous rencontrez un cas limite, ayez une conversation à ce moment-là.

C'est l'approche XP des exigences : juste assez, juste à temps, par la conversation.