User Stories
Auteur : Kent Beck
Source : User Stories
Date : 1999
Traducteur : Fabrice Aimetti
Date : 23/04/2019
Traduction :
Les User stories servent le même but que les cas d'utilisation, mais ce n'est pas la même chose. Elles sont utilisés pour créer des estimations de temps pour la réunion de planification de la version (release planning). Elles sont également utilisées en lieu et place d'un gros document de besoins. Les user stories sont écrites par les clients comme des choses que le système doit faire pour eux. Elles sont similaires aux scénarios d'utilisation, sauf qu'elles ne se limitent pas à décrire une interface utilisateur. Elles se présentent sous la forme d'environ trois phrases de texte rédigées par le client dans la terminologie du client sans syntaxe technique.
Les user stories sont également à la base de la création des tests d'acceptation. Un ou plusieurs tests d'acceptation automatisés doivent être créés pour vérifier que la user story a été correctement mise en oeuvre.
L'un des plus gros malentendus avec les user stories est la manière dont elles diffèrent des traditionnelles spécifications des exigences. La plus grande différence réside dans le niveau de détail. Les user stories ne devraient fournir suffisamment de détails que pour permettre une raisonnable estimation portant un faible risque quant à la durée de leur mise en oeuvre. Lorsque le moment sera venu de mettre en oeuvre la story, les développeurs iront voir le client qui leur fera une description détaillée des exigences en face à face.
Les développeurs estiment le temps nécessaire à la mise en oeuvre de ces stories. Chaque histoire fera l'objet d'une estimation de 1, 2 ou 3 semaines en "temps de développement idéal". Ce temps de développement idéal est le temps qu'il faudra pour implémenter la story sous forme de code sans être distrait, en ayant pas d'autres tâches, et que vous savez exactement quoi faire. Plus de 3 semaines signifie que vous devez décomposer la story plus en détail. Moins d'une semaine et vous êtes à un niveau trop détaillé, combinez quelques stories. Un chiffre d'environ 80 user stories, plus ou moins 20, est un chiffres parfait pour créer un plan de release pendant la planification de la release.
Une autre différence entre des stories et un cahier des charges c'est l'accent mis sur les besoins des utilisateurs. Vous devriez essayer d'éviter les détails spécifiques à la technologie, la configuration de la base de données et les algorithmes. Vous devriez essayer de garder les stories centrées sur les besoins et les bénéfices des utilisateurs plutôt que de spécifier la mise en page de l'interface graphique.
Liens :
