User Story
Auteur : Kent Beck
Source : 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 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énieure ergonomie et conceptrice 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 la story.
- 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'un fragment : La story doit pouvoir être terminée au cours de l'itération.
- 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 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".
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.
Kent
