User Story - Historique des versions

Fabrice Aimetti le 24 mars 2021 à 19:01

Fabrice Aimetti — Wed, 24 Mar 2021 19:01:44 GMT

← Version précédente		Version du 24 mars 2021 à 19:01
Ligne 1 :		Ligne 1 :
	[[Category: User Story]]		[[Category: User Story]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]
			[[Catégorie:Kent Beck]]
	Auteur : Kent Beck<br />		Auteur : Kent Beck<br />
	Source : [http://wiki.c2.com/?UserStory User Story]<br />		Source : [http://wiki.c2.com/?UserStory User Story]<br />

Fabrice Aimetti le 23 avril 2019 à 08:29

Fabrice Aimetti — Tue, 23 Apr 2019 08:29:34 GMT

← Version précédente		Version du 23 avril 2019 à 08:29
Ligne 30 :		Ligne 30 :
	Que pensez-vous de ça Kent ? Y a-t-il quelqu'un d'autre qui soit à l'aise avec ce concept de '''User Story''' et de '''User Tasks''' ?<br/>		Que pensez-vous de ça Kent ? Y a-t-il quelqu'un d'autre qui soit à l'aise avec ce concept de '''User Story''' et de '''User Tasks''' ?<br/>
	<br/>		<br/>
	''-- Martha Roden, ~~Ingénieur~~ ergonomie et ~~concepteur~~ d'interactions''<br/>		''-- Martha Roden, Ingénieure ergonomie et conceptrice d'interactions''<br/>
	<br/>		<br/>
	Ce que vous décrivez ci-dessus sont toutes des choses sensées, mais ce n'est pas une Story avec un S masjuscule. Une Story avec un S majuscule est :		Ce que vous décrivez ci-dessus sont toutes des choses sensées, mais ce n'est pas une Story avec un S masjuscule. Une Story avec un S majuscule est :

Fabrice Aimetti le 23 avril 2019 à 08:28

Fabrice Aimetti — Tue, 23 Apr 2019 08:28:50 GMT

← Version précédente		Version du 23 avril 2019 à 08:28
Ligne 33 :		Ligne 33 :
	<br/>		<br/>
	Ce que vous décrivez ci-dessus sont toutes des choses sensées, mais ce n'est pas une Story avec un S masjuscule. Une Story avec un S majuscule est :		Ce que vous décrivez ci-dessus sont toutes des choses sensées, mais ce n'est pas une Story avec un S masjuscule. Une Story avec un S majuscule est :
	* Testable -- Vous pouvez écrire des tests automatiques pour détecter la présence de ~~l'histoire~~.		* Testable : Vous pouvez écrire des tests automatiques pour détecter la présence de la story.
	* ~~Progrès -- Le~~ côté client ~~de l'équipe~~ est prêt à accepter ~~l'histoire~~ comme un signe de ~~progrès~~ vers leur objectif plus large.		* Progression : L'équipe du côté client est prêt à accepter la story comme un signe de progression vers leur objectif plus large.
	* De la taille d'~~une bouchée -- L'histoire~~ doit pouvoir être ~~complétée~~ au cours de l'itération.		* De la taille d'un fragment : La story doit pouvoir être terminée au cours de l'itération.
	* ~~Estimation -- Le~~ côté technique ~~de l'équipe~~ doit être capable de ~~deviner~~ combien de temps ~~l'histoire de~~ l'équipe prendra pour ~~commencer à travailler~~.		* Estimable : L'équipe du côté technique doit être capable de d'estimer combien de temps l'équipe prendra pour réaliser la story.
	Au fur et à mesure que les itérations sont devenues plus courtes (je commence toujours par une semaine) et que les équipes sont devenues plus petites, la portée d'une seule ~~histoire~~ a diminué. Je ressens certainement le besoin de mécanismes structurants à plus grande échelle. Certaines personnes utilisent "thème", ~~d'autres~~ "~~grande histoire~~" ou "initiative".<br/>		Au fur et à mesure que les itérations sont devenues plus courtes (je commence toujours par une semaine) et que les équipes sont devenues plus petites, la portée d'une seule story a diminué. Je ressens certainement le besoin de mécanismes structurants à plus grande échelle. Certaines personnes utilisent la notion de "thème", de "grosse story" ou d'"initiative".<br/>
	<br/>		<br/>
	Re : les détails ci-dessus. Ce qui manque dans tout cela, c'est le "pourquoi". Pourquoi l'utilisateur veut-il faire cela ? L'écriture d'une ~~histoire~~ doit être l'occasion pour les clients de réfléchir sur leur métier et ~~de l~~'affiner.<br/>		Re : concernant les détails ci-dessus. Ce qui manque dans tout cela, c'est le "pourquoi". Pourquoi l'utilisateur veut-il faire cela ? L'écriture d'une story doit être l'occasion pour les clients de réfléchir sur leur métier et d'affiner leur savoir-faire.<br/>
	<br/>		<br/>
	Kent		Kent

Fabrice Aimetti : Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck
Source : [http://wiki.c2.com/?UserStory User Story]
Date : 08/01/2014
---... »

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

Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck Source : [http://wiki.c2.com/?UserStory User Story] Date : 08/01/2014 ---... »

Nouvelle page

[[Category: User Story]]
[[Category: Portail Product Owner]]
Auteur : Kent Beck 
Source : [http://wiki.c2.com/?UserStory User Story] 
Date : 08/01/2014 
----
Traducteur : Fabrice Aimetti 
Date : 23/04/2019 
----
Traduction : 
 
J'ai lu tous les différents commentaires sur les user stories et j'ai le sentiment qu'il y a un sérieux manque de consensus sur ce qu'est une [http://wiki.c2.com/?UserStory UserStory]. Les anglophones considèrent généralement une '''histoire/story''' comme une sorte de récit qui décrit un scénario QUI, QUOI et POURQUOI. Donc, de ce point de vue, j'ai un doute sur le fait qu'une histoire/story soit au niveau concis et fonctionnel dont un programmeur a besoin pour développer du code. 
 
Par conséquent, je suggère que la '''USER STORY''' soit effectivement un récit qu'un utilisateur raconte de son propre point de vue. Cette histoire/story décrit typiquement une sorte de scénario ou de situation dans laquelle l'utilisateur se trouve. Les programmeurs doivent ensuite travailler avec l'utilisateur pour dériver de ce récit les '''USER TASKS''' spécifiques que l'utilisateur devra effectuer avec le logiciel pour accomplir l'histoire. 
 
Par exemple, voici une véritable '''USER STORY''' : 
 
Un chef de projet doit mettre en place un site Web dans lequel tous les membres de son équipe peuvent accéder aux dessins techniques, aux modèles, aux résultats des recherches, aux procès-verbaux des réunions et aux calendriers associés à leur dernier projet. Cela aidera l'équipe à rester en phase avec l'avancement du projet. Cela évitera également le problème actuel du stockage des données dans différents endroits auxquels tout le monde n'a pas accès. 
 
Et voici les '''USER TASKS''' que nous tirons de la story :
# Créer un projet sur le site web.
# Créer des dossiers dans le projet.
# Transférer les fichiers dans ces dossiers.
Et si l'utilisateur fait des erreurs concernant le nom ou l'emplacement d'un projet, dossier ou fichier, il doit pouvoir faire les choses suivantes :
# Renommer un projet, un dossier ou un fichier.
# Déplacer un dossier ou un fichier.
# Supprimer un projet, un dossier ou un fichier.
Je pense que vous pouvez voir que ce sont les '''TASKS''' de l'utilisateur, et ''NON'' la '''STORY''', qui représentent ces morceaux de fonctionnalité qui peuvent être estimés, priorisés, et ensuite mis en oeuvre par les programmeurs. 
 
Que pensez-vous de ça Kent ? Y a-t-il quelqu'un d'autre qui soit à l'aise avec ce concept de '''User Story''' et de '''User Tasks''' ? 
 
''-- Martha Roden, Ingénieur ergonomie et concepteur d'interactions'' 
 
Ce que vous décrivez ci-dessus sont toutes des choses sensées, mais ce n'est pas une Story avec un S masjuscule. Une Story avec un S majuscule est :
* Testable -- Vous pouvez écrire des tests automatiques pour détecter la présence de l'histoire.
* Progrès -- Le côté client de l'équipe est prêt à accepter l'histoire comme un signe de progrès vers leur objectif plus large.
* De la taille d'une bouchée -- L'histoire doit pouvoir être complétée au cours de l'itération.
* Estimation -- Le côté technique de l'équipe doit être capable de deviner combien de temps l'histoire de l'équipe prendra pour commencer à travailler.
Au fur et à mesure que les itérations sont devenues plus courtes (je commence toujours par une semaine) et que les équipes sont devenues plus petites, la portée d'une seule histoire a diminué. Je ressens certainement le besoin de mécanismes structurants à plus grande échelle. Certaines personnes utilisent "thème", d'autres "grande histoire" ou "initiative". 
 
Re : les détails ci-dessus. Ce qui manque dans tout cela, c'est le "pourquoi". Pourquoi l'utilisateur veut-il faire cela ? L'écriture d'une histoire doit être l'occasion pour les clients de réfléchir sur leur métier et de l'affiner. 
 
Kent

User Story - Historique des versions

Fabrice Aimetti le 24 mars 2021 à 19:01

Fabrice Aimetti le 23 avril 2019 à 08:29

Fabrice Aimetti le 23 avril 2019 à 08:28

Fabrice Aimetti : Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck Source : [http://wiki.c2.com/?UserStory User Story] Date : 08/01/2014 ---... »

Fabrice Aimetti : Page créée avec « Category: User Story Category: Portail Product Owner Auteur : Kent Beck
Source : [http://wiki.c2.com/?UserStory User Story]
Date : 08/01/2014
---... »