qu’est-ce qu’une user story?
Les User stories sont des descriptions courtes et simples d’une fonctionnalité racontée du point de vue de la personne qui désire la nouvelle fonctionnalité, généralement un utilisateur ou un client du système. Ils suivent généralement un modèle simple:
en tant que , je veux que .
Les histoires D’utilisateurs sont souvent écrites sur des fiches ou des notes autocollantes, stockées dans une boîte à chaussures et disposées sur des murs ou des tables pour faciliter la planification et la discussion., En tant que tels, ils déplacent fortement l’accent de l’écriture sur les fonctionnalités pour en discuter. En fait, ces discussions sont plus importantes que n’importe quel texte.
pouvez-vous montrer quelques exemples d’histoire d’utilisateur?
l’un des avantages des user stories agiles est qu’elles peuvent être écrites à différents niveaux de détail. Nous pouvons écrire une histoire d’utilisateur pour couvrir de grandes quantités de fonctionnalités. Ces grandes histoires d’utilisateurs sont généralement connues sous le nom d’épopées. Voici un exemple Epic agile user story à partir d’un produit de sauvegarde de bureau:
- En tant qu’utilisateur, je peux sauvegarder l’intégralité de mon disque dur.,
étant donné qu’un epic est généralement trop volumineux pour être complété par une équipe agile en une seule itération, il est divisé en plusieurs histoires d’utilisateurs plus petites avant d’être travaillé. L’épopée ci-dessus pourrait être divisée en dizaines (voire des centaines), y compris ces deux:
- En tant qu’utilisateur expérimenté, je peux spécifier des fichiers ou des dossiers à sauvegarder en fonction de la taille du fichier, de la date de création et de la date de modification.
- En tant qu’utilisateur, je peux indiquer les dossiers à ne pas sauvegarder afin que mon lecteur de sauvegarde ne soit pas rempli de choses dont je n’ai pas besoin.
comment les détails sont-ils ajoutés aux user stories?,
Les détails peuvent être ajoutés aux user stories de deux façons:
- En divisant une user story en plusieurs user stories plus petites.
- en ajoutant « conditions de satisfaction. »
Lorsqu’une histoire relativement importante est divisée en plusieurs histoires d’utilisateurs agiles plus petites, il est naturel de supposer que des détails ont été ajoutés. Après tout, de plus a été écrit.
les conditions de satisfaction sont simplement un test d’acceptation de haut niveau qui sera vrai une fois l’histoire utilisateur agile terminée., Considérez ce qui suit comme un autre exemple d’expérience utilisateur agile:
en tant que vice-président du marketing, je souhaite sélectionner une période des fêtes à utiliser lors de l’examen des performances des campagnes publicitaires passées afin de pouvoir identifier celles qui sont rentables.
le détail pourrait être ajouté à cet exemple d’histoire d’utilisateur en ajoutant les conditions de satisfaction suivantes:
- assurez-vous que cela fonctionne avec les grandes fêtes de détail: Noël, Pâques, Fête du Président, Fête des Mères, Fête des pères, Fête du Travail, Jour de l’an.
- prend en charge les vacances qui s’étendent sur deux années civiles (aucune ne s’étend sur trois).,
- Les Saisons de vacances peuvent être définies d’un jour férié à L’autre (comme Thanksgiving à Noël).
- le temps des Fêtes peut être un certain nombre de jours avant les vacances.
qui écrit des histoires d’utilisateurs?
tout le monde peut écrire des histoires utilisateur. Il est de la responsabilité du product owner de s’assurer qu’un backlog produit d’histoires d’utilisateurs agiles existe, mais cela ne signifie pas que le product owner est celui qui les écrit. Au cours d’un bon projet agile, vous devez vous attendre à avoir des exemples d’histoire utilisateur écrits par chaque membre de l’équipe.,
notez également que qui écrit une histoire utilisateur est beaucoup moins important que qui est impliqué dans les discussions de celui-ci.
quand les User stories sont-elles écrites?
Les user stories sont écrites tout au long du projet agile. Habituellement, un atelier d’écriture d’histoires est organisé près du début du projet agile. Tous les membres de l’équipe participent dans le but de créer un backlog produit décrivant en détail les fonctionnalités à ajouter au cours du projet ou d’un cycle de publication de trois à six mois.
certaines de ces histoires d’utilisateurs agiles seront sans aucun doute des épopées., Les épopées seront plus tard décomposées en histoires plus petites qui s’intègrent plus facilement dans une seule itération. De plus, de nouvelles histoires peuvent être écrites et ajoutées au backlog produit à tout moment et par n’importe qui.
les user stories remplacent-elles un document d’exigences?
Les projets agiles, en particulier ceux Scrum, utilisent un backlog produit, qui est une liste hiérarchisée des fonctionnalités à développer dans un produit ou un service. Bien que les articles de backlog de produits puissent être ce que l’équipe désire, les histoires d’utilisateurs sont apparues comme la forme la meilleure et la plus populaire des articles de backlog de produits.,
alors qu’un backlog produit peut être considéré comme un remplacement du document d’exigences d’un projet traditionnel, il est important de se rappeler que la partie écrite d’une histoire utilisateur agile (« en tant qu’utilisateur, je veux …”) est incomplète jusqu’à ce que les discussions sur cette histoire se produisent.
Il est souvent préférable de considérer la partie écrite comme un pointeur vers l’exigence réelle. Les User stories peuvent pointer vers un diagramme représentant un flux de travail, une feuille de calcul montrant comment effectuer un calcul ou tout autre artefact souhaité par le product owner ou l’équipe.,
ressources recommandées liées aux User Stories
- avantages du modèle user story « en tant qu’utilisateur, je veux”.,
- Un format D’échantillon pour un Backlog produit basé sur une feuille de calcul
- avantages des User Stories pour les exigences
- exigences non fonctionnelles en tant que User Stories
- Introduction aux User Stories
Leave a Reply