Stratégie mobile et conseils: User Stories

Quels sont les objectifs de l'application ?

Les propriétaires de produits formulent les souhaits des utilisateurs en matière de logiciels ou d'autres services dans des User Stories.

Les User Stories sont l'outil le plus important pour gérer le contenu des projets agiles. Les User Stories décrivent les exigences du client pour un produit logiciel ou une solution commerciale. Les développeurs apprennent, grâce aux témoignages des utilisateurs, ce que le client ou l'utilisateur veut exactement et pourquoi il le veut.

Que sont les User Stories ?

Les User Stories sont des histoires d'utilisateurs. Dans une histoire d'utilisateur, le propriétaire du produit décrit les exigences du point de vue de l'utilisateur : Comment les utilisateurs veulent-ils un logiciel ou les clients veulent-ils un produit pour atteindre leurs objectifs commerciaux ?

Bien que le terme "user story" n'apparaisse pas dans le Scrum Guide, les techniques de travail agile l'utilisent fréquemment. Les récits des utilisateurs figurent dans l'arriéré, à côté des épopées et des tâches, des exigences de qualité, des défauts et des améliorations. Les témoignages d'utilisateurs se composent de quelques phrases faciles à comprendre. Ils sont courts, mais spécifiques et détaillés du point de vue du client.

Les témoignages d'utilisateurs ne transmettent pas seulement les attentes concernant les futurs systèmes informatiques, mais aussi les exigences en matière de livrables permettant de réaliser des projets agiles. Les témoignages d'utilisateurs se déplacent dans l'espace des besoins sans se déplacer dans l'espace des solutions. Ils ne fournissent pas de solutions techniques qui obligent les développeurs à s'obstiner à les réaliser.

Epic, Story & Task

Epic

Epic est une User Story au plus haut niveau d'abstraction. Il est trop grand pour un seul sprint. Le propriétaire du produit le décompose donc en plusieurs petites User Stories.

Story

La Story est une User Story et fait partie d'une Epic. Une Story contient les exigences, rédigées sous forme de petits textes gérables. Sur cette base, l'équipe estime l'effort de mise en œuvre.

Task

Les développeurs et les testeurs décomposent une Story en tâches individuelles. Si une tâche dépasse un délai convenu, elle peut être divisée en tâches supplémentaires. Une Story est complète lorsque toutes les tâches de la Story ont été accomplies.

Comment formuler une User Story ?

Une User Story doit être simple et facile à comprendre. Cela peut être réalisé avec des constructions de phrases simples : Sujet, verbe, objet. Les termes ambigus n'ont pas leur place dans une User Story.

La User Story doit également se concentrer sur l'essentiel. Rachel Davie, co-auteur du livre "Agile Coaching", recommande de formuler la User Story selon les lignes suivantes :

"En tant que [rôle], je veux [fonction] dans le but [avantage]".

Ici, le rôle, la fonction et l'avantage ressortent des réponses aux questions suivantes :

Qui demande quelque chose ? (=rôle)

Le demandeur est généralement le dernier utilisateur du système ou le bénéficiaire de la solution à développer.

Que veut le demandeur ? (=fonction)

Le demandeur veut que quelque chose de précis se produise. Plus le souhait est clair et précis dans l'histoire de l'utilisateur, plus cette histoire est utile à l'équipe de développement pour réaliser les exigences.

Pourquoi est-ce important pour l'analyse de rentabilité ? (=avantage)

Cette exigence vise à atteindre un objectif. Le demandeur en attend un bénéfice. La description de la raison de l'exigence fournit des informations supplémentaires à l'équipe de développeurs pour l'exécuter correctement.

Exemple de formulation d'une User Story

Un portail d'apprentissage en ligne qui propose des séminaires pour les chefs de projet pourrait formuler cette User Story pour l'enregistrement d'un nouveau client :

"En tant que nouveau client, je souhaite m'inscrire sur le portail d'apprentissage en ligne pour préparer la certification du PMI".

La Story Card

C'est au propriétaire du produit qu'il revient de décider comment il va saisir et gérer les User Stories. Le Guide SCRUM ne prescrit rien. Dans la pratique, cependant, il s'est avéré utile d'écrire la User Story sur une Story Card.

Carte, Conversation, Confirmation

En plus des critères "INVEST", il existe d'autres règles pour la création de User Story. Ron Jeffries énumère trois aspects essentiels à prendre en compte lors de la création de User Story : Carte, Conversation et Confirmation.

Carte

Les Stories sont traditionnellement écrites sur des cartes. Par conséquent, les propriétaires de produits doivent être brefs et ne pas utiliser plus d'espace que ce que la carte permet.

Conversation

Les exigences ne doivent pas être jetées "par-dessus la barrière" à l'équipe de développement. Le client et le développeur doivent se parler au sujet des cartes afin d'aiguiser la compréhension de chacun. Parce que le diable est dans les détails. Ce n'est que dans la conversation qu'il devient clair si les développeurs comprennent vraiment ce qu'ils sont censés construire.

Confirmation

Une User Story est complète lorsque les critères d'acceptation sont remplis. Ils décrivent ce que l'on attend de la Story afin de la rapporter comme "terminée". Les critères d'acceptation sont flexibles et sont ajustés selon les besoins jusqu'à ce que l'équipe commence à construire la User Story. Le maître SCRUM et l'équipe de développement clarifient dans les discussions s'il y a une compréhension commune. Cela permet d'éviter des malentendus qui prendraient beaucoup de temps à dissiper par la suite.

Obtenez gratuitement un devis