Une Introduction aux Histoires d’Utilisateur

5 Sep

Qui les écrit? Comment? A quoi servent-elles? Comment les regrouper et les structurer?

An Introduction to User Stories https://www.scrumalliance.org/community/articles/2016/september/an-introduction-to-user-stories par Adrian Sita

Les histoires d’utilisateur sont un artefact de développement crucial en programmation extrême (XP) ou projet Scrum. Elles sont les définitions de haut niveau d’exigences qui incluent juste assez d’information pour que les développeurs puissent produire des évaluations raisonnables de l’effort nécessaire pour les mettre en œuvre. Une autre façon de penser aux histoires d’utilisateur consiste en ce qu’elles peuvent rappeler aux développeurs d’avoir une conversion avec le client ou le propriétaire de produit pour obtenir des informations plus détaillées quand viendra le moment de mettre en œuvre l’histoire.

Le client ou le propriétaire de produit écrivent des histoires d’utilisateur comme des fonctions et options que le système doit exécuter. Elles sont semblables à des scénarios d’usage, sauf qu’elles ne sont pas limitées à la description d’une interface utilisateur. Une histoire d’utilisateur est courte (deux ou trois phrases) et elle utilise seulement la terminologie du client. Les histoires d’utilisateur peuvent être écrites de façon informelle, comme suit : les étudiants peuvent acheter un forfait de stationnement mensuel en ligne, ou de façon plus formelle, en suivant ce modèle :

En tant que < rôle > je veux < quelque chose >pour < ce bénéfice >.

Donc, notre exemple pourrait être écrit comme suit :

En tant qu’ étudiant, je veux acheter un forfait de stationnement pour que je puisse venir en voiture à l’école.

Méta Projets Management est partenaire de DantotsuPM

La manière plus formelle aide les développeurs à identifier clairement les acteurs, la fonction exigée et « le pourquoi » (la valeur business/client) qui soutient l’exigence. Avec la manière informelle, tous ces détails ne sont pas si évidents.

Les histoires d’utilisateur conduisent aussi la création des tests d’acceptation. Des contrôles d’acceptation plus automatisés doivent être créés pour vérifier que l’histoire d’utilisateur a été correctement mise en œuvre. Une bonne approche est de faire spécifier par le client les critères d’acceptation pour aider à créer les tests de recette.

Si l’estimation est trop importante et ne peut pas entrer dans une itération, l’histoire doit être décomposée. Pendant la réunion de livraison, de nouvelles histoires d’utilisateur pourraient apparaitre en en divisant d’autres. XP et Scrum ont des vues légèrement différentes de comment les histoires d’utilisateur sont évaluées.

  • XP utilise le concept de temps de développement idéal, combien de temps cela nécessiterait pour mettre en œuvre l’histoire dans le code s’il n’y avait aucune distraction, aucune autre tâche allouée et que vous saviez exactement que faire. En comparaison.
  • Scrum utilise le concept plus abstrait de points d’histoire (ou de complexité), qui est basé sur l’assignation de valeurs différentes — des points d’histoire — à chaque histoire d’utilisateur, en considérant sa complexité relative par rapport aux autres histoires.

En se basant sur la valeur métier (celles de plus grande valeur viennent d’abord) et les estimations fournies, les histoires d’utilisateur sont priorisées et planifiées pour une certaine itération/livraison. Quand il est temps de mettre en œuvre l’histoire d’utilisateur, le développeur et le client ou le propriétaire de produit s’assoient ensemble pour détailler les exigences; Juste suffisamment pour que l’équipe de développement puisse la mettre en œuvre.

 Les épopées (epics) sont de grandes histoires d’utilisateur, typiquement celles qui sont trop grosses pour une mise en œuvre en une seule itération et doivent donc être décomposées en histoires utilisateur plus petites. Les épopées sont typiquement des histoires utilisateur de priorité inférieure, qui sont vagues, mais deviendront plus claires avec le temps. Cela n’a aucun sens de décomposer une épopée de basse priorité, parce que vous investiriez du temps sur quelque chose que vous ne pourriez ne jamais parvenir à adresser, à moins qu’une partie de l’épopée ne soit de forte priorité et doive être regardée.

Un thème est une collection d’histoires utilisateur reliées. Les thèmes sont souvent utilisés pour organiser des histoires dans des itérations/releases ou les organiser pour que des sous-équipes différentes puissent travailler dessus.

CertYou est partenaire de DantotsuPM

Vidéo de Lyssa Adkins sur le Scrum Framework

Agile coaches need to be able to teach the agile framework their teams will use in 10 minutes or less.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

déposer un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :