User Story (bis)
Auteur : Martin Fowler
Source : User Story
Date : 22/04/2013
Traducteur : Fabrice Aimetti
Date : 17/09/2024
Traduction :
Les User Stories sont des fragments du comportement souhaité d'un système logiciel. Elles sont largement utilisées dans les approches logicielles agiles pour diviser une grande quantité de fonctionnalités en plus petits fragments à des fins de planification. Le même concept est également appelé "fonctionnalité / feature", mais le terme "story" ou ”user story" est devenu courant dans les cercles agiles de nos jours.
Kent Beck a introduit ce terme pour la première fois dans le cadre de l'Extreme Programming afin d'encourager un style plus informel et conversationnel pour la définition des besoins, plutôt que de longues spécifications écrites. L'essence d'une story peut être écrite sur une simple note cartonnée (Kent et moi préférons le format "3 par 5"). Les stories ne sont délibérément pas détaillées jusqu'à ce qu'elles soient prêtes à être développées, il suffit de les comprendre suffisamment pour pouvoir les prioriser par rapport à d'autres stories.
Bill Wake a inventé le moyen mnémotechnique INVEST pour décrire les caractéristiques de bonnes stories :
- Indépendantes : les stories peuvent être livrées dans n'importe quel ordre.
- Négociables : les détails du contenu d'une story sont co-créés par les développeurs et le client au cours du développement.
- Valorisables : la fonctionnalité est considérée comme ayant de la valeur par les clients ou les utilisateurs du logiciel.
- Estimables : les développeurs peuvent proposer une estimation raisonnable pour la construction de la story.
- Suffisamment petites : les stories doivent être construites en peu de temps, généralement en quelques jours-homme. Il est évident que vous devriez être en mesure de construire plusieurs stories au cours d'une itération.
- Testables : vous devez être en mesure d'écrire des tests pour vérifier que le logiciel de cette story fonctionne correctement.
Une façon courante de formuler les stories est la forme « En tant que ... Je veux ... Pour que ... ». La clause « En tant que » renvoie à la personne qui souhaite la story, « Je veux » décrit la fonctionnalité, « Pour que » décrit la raison pour laquelle le client souhaite cette fonctionnalité. La partie « pour que » fournit un contexte important à comprendre pour aider à passer de ce que le client pense demander à avoir de ce dont il a réellement besoin.
Mike Cohn a écrit ce qui est aujourd'hui le manuel standard sur la rédaction des user stories. Pour comprendre les racines des user stories dans XP, regardez le livre blanc, ou le savoureux livre vert. Dans un article précédent de bliki, j'explique pourquoi les UseCasesAndStories sont différents.
