User Stories - Historique des versions

Fabrice Aimetti le 18 octobre 2022 à 10:19

Fabrice Aimetti — Tue, 18 Oct 2022 10:19:17 GMT

← Version précédente		Version du 18 octobre 2022 à 10:19
Ligne 18 :		Ligne 18 :
	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\|link=]]<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/>		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/>

Fabrice Aimetti le 24 mars 2021 à 19:04

Fabrice Aimetti — Wed, 24 Mar 2021 19:04:04 GMT

← Version précédente		Version du 24 mars 2021 à 19:04
Ligne 1 :		Ligne 1 :
	[[Category: User Story]]		[[Category: User Story]]
	[[Category: Use Case]]		[[Category: Use Case]]
			[[Catégorie:Kent Beck]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	Auteur : Kent Beck<br />		Auteur : Kent Beck<br />

Fabrice Aimetti le 22 avril 2020 à 21:24

Fabrice Aimetti — Wed, 22 Apr 2020 21:24:21 GMT

← Version précédente		Version du 22 avril 2020 à 21:24
Ligne 17 :		Ligne 17 :
	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=]]<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/>		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/>

Fabrice Aimetti le 23 avril 2019 à 09:06

Fabrice Aimetti — Tue, 23 Apr 2019 09:06:06 GMT

← Version précédente		Version du 23 avril 2019 à 09:06
Ligne 1 :		Ligne 1 :
	[[Category: User Story]]		[[Category: User Story]]
			[[Category: Use Case]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
	Auteur : Kent Beck<br />		Auteur : Kent Beck<br />

Fabrice Aimetti le 23 avril 2019 à 09:05

Fabrice Aimetti — Tue, 23 Apr 2019 09:05:11 GMT

← Version précédente		Version du 23 avril 2019 à 09:05
Ligne 20 :		Ligne 20 :
	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/>		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/>		<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.		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)]]

Fabrice Aimetti le 23 avril 2019 à 09:02

Fabrice Aimetti — Tue, 23 Apr 2019 09:02:39 GMT

← Version précédente		Version du 23 avril 2019 à 09:02
Ligne 10 :		Ligne 10 :
	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/>		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/>
Ligne 18 :		Ligne 18 :
	[[Fichier:Xp-project.gif]]<br/>		[[Fichier:Xp-project.gif]]<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. ~~Environ~~ 80 user stories, plus ou moins 20, ~~sont des~~ chiffres ~~parfaits~~ pour créer un plan de ~~libération~~ pendant la planification de la ~~libération~~.		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/>
	Une autre différence entre ~~un article~~ et un cahier des charges est l'accent mis sur les besoins des utilisateurs. Vous devriez essayer d'éviter les détails de la technologie ~~spécifique~~, la ~~disposition~~ de la base de données et les algorithmes. Vous devriez essayer de garder les ~~histoires~~ centrées sur les besoins et les ~~avantages~~ des utilisateurs plutôt que de spécifier la mise en page de l'interface graphique.		<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.

Fabrice Aimetti le 23 avril 2019 à 08:57

Fabrice Aimetti — Tue, 23 Apr 2019 08:57:30 GMT

← Version précédente		Version du 23 avril 2019 à 08:57
Ligne 18 :		Ligne 18 :
	[[Fichier:Xp-project.gif]]<br/>		[[Fichier:Xp-project.gif]]<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. Environ 80 user stories, plus ou moins 20, sont des chiffres parfaits pour créer un plan de libération pendant la planification de la libération.
			Une autre différence entre un article et un cahier des charges est l'accent mis sur les besoins des utilisateurs. Vous devriez essayer d'éviter les détails de la technologie spécifique, la disposition de la base de données et les algorithmes. Vous devriez essayer de garder les histoires centrées sur les besoins et les avantages des utilisateurs plutôt que de spécifier la mise en page de l'interface graphique.

Fabrice Aimetti le 23 avril 2019 à 08:54

Fabrice Aimetti — Tue, 23 Apr 2019 08:54:08 GMT

← Version précédente		Version du 23 avril 2019 à 08:54
Ligne 12 :		Ligne 12 :
	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]. 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/>		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/>

Fabrice Aimetti : Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck
Source : [http://www.extremeprogramming.org/rules/userstories.html User Stories]

Fabrice Aimetti — Tue, 23 Apr 2019 08:53:55 GMT

Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck Source : [http://www.extremeprogramming.org/rules/userstories.html User Stories] 
Source : [http://www.extremeprogramming.org/rules/userstories.html 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 [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. 
 
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. 
 
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. 
 
[[Fichier:Xp-project.gif]]