« User Stories » : différence entre les versions
Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck<br /> Source : [http://www.extremeprogramming.org/rules/userstories.html User Stories]<br /... » |
Aucun résumé des modifications |
||
| (7 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: User Story]] | [[Category: User Story]] | ||
[[Category: Use Case]] | |||
[[Catégorie:Kent Beck]] | |||
[[Category: Portail Product Owner]] | [[Category: Portail Product Owner]] | ||
Auteur : Kent Beck<br /> | Auteur : Kent Beck<br /> | ||
| Ligne 10 : | Ligne 12 : | ||
Traduction :<br /> | Traduction :<br /> | ||
<br /> | <br /> | ||
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 [http://www.extremeprogramming.org/rules/planninggame.html réunion de planification de la version]. Elles sont également utilisées en lieu et place d'un gros document de besoins. Les user stories sont écrites par [http://www.extremeprogramming.org/rules/customer.html 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.<br/> | 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 [http://www.extremeprogramming.org/rules/planninggame.html 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 [http://www.extremeprogramming.org/rules/customer.html 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.<br/> | ||
<br/> | <br/> | ||
Les user stories sont également à la base de la création des [http://www.extremeprogramming.org/rules/functionaltests.html 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.<br/> | |||
<br/> | <br/> | ||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Xp-project.gif]]<br/> | [[Fichier:Xp-project.gif|link=|border]]<br/> | ||
<br/> | <br/> | ||
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 [http://www.extremeprogramming.org/rules/commit.html plan de release] pendant la planification de la release.<br/> | |||
<br/> | |||
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.<br/> | |||
<br/> | |||
Liens : | |||
* [[User Story|User Stories (fr)]] | |||
* [[Planning Poker ou Comment éviter la paralysie lors de la planification de version|Planning Poker (fr)]] | |||
Dernière version du 18 octobre 2022 à 10:19
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 :