l’un des plus grands défis du développement logiciel est la tâche presque impossible de rassembler des exigences claires et de les faire rester inchangées pendant le développement du code. Dans l’approche en cascade du développement logiciel-malgré les efforts pour définir, documenter et approuver toutes les éventualités possibles avant le début du développement—le produit livré est rarement ce que le client veut.
La méthode agile de solution de rechange? Création d’histoire utilisateur.,
l’un des plus grands avantages de l’utilisation d’une approche agile pour le développement de logiciels est que les exigences ne sont pas gravées dans le marbre, mais devraient plutôt changer, avec un retour constant des parties prenantes et de l’entreprise. Les méthodologies agiles telles que Scrum et extreme programming (XP) remplacent les longs documents d’exigences traditionnels par un backlog produit hiérarchisé composé d’histoires utilisateur concises, dont les détails apparaissent plus près du moment où l’histoire est prête à être mise en œuvre.,
bien que la création d’histoires utilisateur soit plus artistique que scientifique, ce tutoriel vous donnera les informations, les exemples et les étapes dont vous aurez besoin pour créer des histoires utilisateur de haute qualité.
historique des user stories
XP a introduit le concept des user stories en 1998, en les comparant à des cas d’utilisation. Dans Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson a présenté les cas d’utilisation comme un moyen de documenter les exigences en définissant les interactions entre un rôle (une personne utilisant le système) et le système lui-même pour atteindre un objectif en utilisant le langage de modélisation unifié (UML).,
cette approche était populaire dans le développement orienté objet et est toujours utilisée comme processus clé dans les frameworks de développement logiciel, tels que le processus unifié (UP), le processus unifié IBM Rational (RUP) et la méthode unifiée Oracle (Oum). L’utilisation de cas d’utilisation, plutôt que de user stories, permet un développement itératif et incrémental et est considérée comme une approche agile de la définition des exigences.,
avec l’introduction des user stories beaucoup plus courtes et la popularité de XP et Scrum, un backlog produit composé d’user stories est devenu l’approche la plus connue de la définition des exigences agiles. De nombreux praticiens pensent encore que les User stories sont la seule approche agile acceptable. Cependant, Alistair Cockburn, l’un des signataires du Manifeste Agile, préfère les cas d’utilisation aux histoires d’utilisateurs.
bien qu’il existe de nombreuses opinions tranchées sur la signification de « agile », les cas d’utilisation et les user stories sont compatibles avec cette approche., Certains disent que les histoires d’utilisateurs finissent par devenir similaires aux cas d’utilisation une fois que l’équipe est d’accord sur les détails de la mise en œuvre. Au début, l’histoire de l’utilisateur est simplement une courte phrase, mais elle n’est pas complète tant que les détails et les critères d’acceptation ne sont pas définis.
créer des user stories
Il existe différentes opinions sur la définition d’une user story et sur la meilleure façon d’en créer une., Voici quelques lignes directrices pour une bonne histoire d’utilisateur:
- Il devrait être écrit par quelqu’un qui représente les utilisateurs professionnels (généralement le propriétaire du produit)
- Il devrait initialement inclure de brèves descriptions du « Qui, quoi et pourquoi », mais pas du « comment »
- Il devrait produire une tranche verticale de code de travail
- Il devrait être suffisamment petit pour pouvoir être codé et testé en une itération (généralement une période d’une à quatre semaines)
divers modèles, techniques et acronymes sont utilisés pour aider les propriétaires de produits à écrire des histoires d’utilisateurs., Trois des techniques les plus courantes sont le modèle role-feature-reason, les trois C (Carte, conversation, confirmation) et INVEST (indépendant, négociable, précieux, estimable, petit, testable).
exemples
dites que vous développez une application qui permettrait aux formateurs de télécharger des didacticiels et d’attirer des étudiants intéressés à suivre un cours. Voici comment appliquer les techniques de l’histoire de l’utilisateur.,
role-Feature-Reason
comme L’explique Mike Cohn de Mountain Goat Software, le modèle role-feature-reason, ou RGB (role, goal, benefit), ressemble à ceci:
« Comme je le veux . »
bien qu’il existe des variations, cette structure de phrase courte garde l’accent sur le Qui, quoi et pourquoi. Cela empêche le product owner de donner trop d’informations à l’équipe de développement sur la façon dont elle doit implémenter une solution. En se concentrant sur qui, quoi et pourquoi, l’équipe de développement est habilitée à trouver la meilleure solution technique.,
exemple 1: offrir à un formateur la possibilité d’ajouter un cours
en tant que formateur, j’aimerais pouvoir ajouter un nouveau cours, afin d’avoir le potentiel d’attirer de nouveaux étudiants.
exemple 2: offrir à un étudiant la possibilité de rechercher un cours
en tant qu’étudiant, j’aimerais pouvoir rechercher les offres de cours, afin de pouvoir trouver une offre qui m’intéresse le plus.
Le rôle (qui)
Le rôle décrit les personnes qui bénéficieront de cette fonction. Notez que le rôle n’est pas simplement « l’utilisateur.,” Il existe différents types d’utilisateurs, et nous voulons donc que le rôle soit plus spécifique que « Utilisateur”, mais décrivez le type d’utilisateur qui bénéficiera de l’histoire. Les propriétaires de produit sont souvent chargés dans l’esprit de leurs utilisateurs afin de comprendre ce qui serait le plus précieux pour eux.
Exemple 1 Role = trainer
Exemple 2 Role = étudiant
La fonction (ce)
Cette étape très brièvement décrit ce que l’utilisateur veut. Cela représente le plus étroitement l’exigence que vous décrivez dans le développement de logiciels traditionnels., Cependant, vous voulez faire attention à ne pas être trop spécifique ou décrire comment écrire le code. Cela sera déterminé éventuellement, mais pas lors de la première création de l’histoire utilisateur. L’histoire de l’utilisateur doit être écrite du point de vue de l’utilisateur qui bénéficiera de la fonction, et non du point de vue du développeur qui la codera.
Exemple 1 Feature = ajouter un nouveau cours
Exemple 2 Feature = recherche les offres de cours
La raison (pourquoi)
Enfin, nous voulons indiquer pourquoi l’utilisateur veut cette fonctionnalité. Quelle valeur l’utilisateur en tirera-t-il?, Cela aide le product owner à évaluer comment hiérarchiser l’histoire de l’utilisateur sur le backlog. Si la valeur ou l’avantage ne peut pas être articulé, il pourrait être quelque chose qui n’est pas nécessaire. Comprendre la valeur aide souvent l’équipe de développement à trouver des moyens innovants d’implémenter le code afin de résoudre l’objectif—des moyens qui peuvent être différents de ce que le propriétaire du produit a en tête.,
exemple 1 Reason = attirer de nouveaux étudiants
exemple 2 Reason = trouver une offre qui m’intéresse le plus
les trois C: Carte, Conversation, Confirmation
la formule des trois C, développée par Ron Jeffries, permet de parvenir à un accord entre l’entreprise et l’équipe technique sur le sens de Les Trois C de les guider dans l’élaboration progressive d’une histoire, d’une brève déclaration à un article de l’utilisateur.,
Card
l’histoire de l’utilisateur commence volontairement brève, avec une déclaration simple qui pourrait tenir sur une carte d’index 3×5, généralement en suivant le format rôle-fonctionnalité-avantage que je viens de couvrir. Par exemple:
en tant que formateur, j’aimerais pouvoir ajouter un nouveau cours, afin d’avoir le potentiel d’attirer de nouveaux étudiants.
la Conversation
Si l’utilisateur histoire commence comme une simple déclaration, les détails doivent émerger avant que l’équipe commence à travailler sur l’histoire., Plutôt que de décrire ce qui est nécessaire dans la documentation, l’équipe comprendra 1) une représentation de l’entreprise (généralement le propriétaire du produit) et 2) l’équipe de développement elle-même, y compris les développeurs, les testeurs, les analystes commerciaux ou toute autre personne de l’équipe.
cette conversation permet à l’équipe de développement de poser des questions pour s’assurer qu’elle comprend bien ce qui est demandé et la valeur fournie. Par exemple:
Développeur: le formateur devez télécharger le didacticiel sur un site web?,
Product owner: non, le formateur ajoutera simplement des informations sur le cours qui sera offert, et la fonctionnalité devrait inclure un moyen pour l’étudiant de figurer sur une liste d’intérêt. Cette histoire donne au formateur la possibilité d’annoncer un cours.
Développeur: Quels champs doivent être inclus?
Product owner: titre du cours, résumé, dates et heures, lieu.
développeur: cela ne sera-t-il que pour la publicité des cours en face à face?
propriétaire du Produit: Oui., Nous pouvons ajouter une option de classe virtuelle plus tard, mais cette histoire ne couvrira que l’ajout d’informations de cours pour les offres de cours en face à face.
développeur: Quelles informations devraient être recueillies lorsqu’un étudiant potentiel demande à figurer sur une liste d’intérêt?
Propriétaire du Produit: Nom, numéro de téléphone et adresse e-mail.
L’équipe mettra à jour l’histoire de l’utilisateur avec les informations qu’ils ont recueillies de la conversation, et ils discuteront de la mise en œuvre—ou le « comment »—qui crée souvent des tâches spécifiques qui doivent être effectuées afin de terminer l’histoire., Bien que l’utilisateur histoire est écrite du point de vue de l’utilisateur, l’équipe de développement écrit les tâches pour les développeurs et inclut la mise en œuvre technique détails.
Confirmation
L’équipe de développement doit avoir une compréhension claire de la façon dont la fonctionnalité fonctionnera dans différentes situations, y compris les conditions d’erreur. Ils doivent obtenir une confirmation concernant les critères d’acceptation du propriétaire du produit. Ce sont les critères qui doivent être remplis pour que l’histoire soit considérée comme faite et acceptée., Voici un exemple de critères d’acceptation:
- un formateur peut ajouter un nouveau cours en entrant le titre du cours, le résumé, les dates et heures et l’emplacement dans un formulaire et en appuyant sur un bouton « Ajouter un cours”.
- Si des champs sont manquants ou si des dates ou des heures ne sont pas valides, des messages d’erreur apparaîtront.
- Une fois que le cours a été correctement ajouté, il sera affiché publiquement sur le site Web du cours et il y aura un bouton pour qu’un étudiant exprime son intérêt.,
- le bouton d’intérêt permettra à un utilisateur d’entrer son nom, son adresse e-mail et son numéro de téléphone, et ces données seront stockées et associées au nouveau cours.
INVEST: les attributs d’une histoire utilisateur solide
INVEST est un acronyme qui permet d’évaluer si vous avez une histoire utilisateur de haute qualité. Voici comment les attributs de l’acronyme s’appliquer à l’histoire que nous avons travaillé.
I = Independent-cette histoire peut-elle être complétée par l’équipe? Nous voulons que l’équipe soit capable de compléter l’histoire entière plutôt que de dépendre d’une autre équipe pour faire L’interface graphique, par exemple.,
N = négociable—L’histoire n’est pas si détaillée que de décrire exactement combien de temps les champs doivent être ou donner des détails sur les formats de date et autres. Très probablement, il y aura des routines ou des bibliothèques communes qui permettront à l’équipe de développement de mettre en œuvre de la manière qui leur convient le mieux.
V = Valuable-le product owner décrit que la valeur recherchée est la capacité pour le formateur de pouvoir annoncer les cours à venir. Cela est clair dans le » pourquoi » de la déclaration originale et re-souligné dans la conversation.,
E = Estimable—l’équipe posera suffisamment de questions et rassemblera les détails pour se sentir confiante dans sa capacité à estimer l’histoire.
S = Small—L’équipe doit avoir confiance qu’elle sera en mesure de compléter l’histoire au cours d’un sprint. S’ils ne le font pas, ils pourraient diviser l’histoire. Par exemple, dans notre exemple d’histoire, ils peuvent décider de faire en sorte que la capacité de recueillir les informations sur les élèves soit une histoire différente et d’afficher simplement des informations sur la classe pour cette histoire.
T = Testable—avec des critères d’acceptation clairs, les conditions happy path et error peuvent être testées.,
alignement sur une vision
j’ai couvert les bases de la création d’une histoire utilisateur, mais vous devez toujours comprendre la grande image avant de créer vos propres histoires utilisateur. Il y a beaucoup de travail que vous devez faire à l’avance, à un niveau supérieur, pour déterminer quelles sont les fonctionnalités les plus importantes qui devraient être livrées aux clients. Ceux-ci sont finalement décomposés en user stories.
Il est important pour l’équipe de comprendre d’abord la vision de haut niveau et de s’assurer que les fonctionnalités, et finalement les histoires d’utilisateurs, s’alignent sur cette vision de haut niveau.,
généralement, vous décomposez le produit en groupes qui portent des noms tels que « thèmes » ou « fonctionnalités ». »Bien que l’étiquetage de ces éléments de backlog puisse différer selon la méthode agile et les outils que vous utilisez pour les décrire, l’idée est de vous assurer qu’ils s’alignent de sorte que le travail puisse être retracé jusqu’à votre vision, ce qui garantira que vous atteignez les objectifs et les valeurs de la vision du produit.
encore une fois, ne démarrez pas un projet en créant des user stories; commencez par créer une vision., Pour notre exemple, je montre simplement un exemple d’énoncé de vision, ce qui conduit à des exemples de fonctionnalités, qui peuvent être décomposés en histoires d’utilisateurs.
Vision
fournir un site Web de haute qualité qui permettra aux formateurs d’annoncer des cours et de permettre aux étudiants de suivre ces cours.
caractéristiques
- fournir une page d’offre de cours qui permettra aux étudiants de s’inscrire à des cours.
- fournir une page d’accueil qui indiquera aux utilisateurs ce que notre site est tout au sujet.
- fournir un processus d’inscription permettant aux utilisateurs de se connecter, de créer un profil et de garder une trace de leurs classes.,
- fournir un blog qui aidera à faire connaître nos offres et à obtenir de la publicité pour notre site web.
User stories
- Fournir formateur avec possibilité d’ajouter un cours sur la gamme de cours page.
- fournir aux étudiants la possibilité de rechercher un cours.
Dans l’exemple ci-dessus, vous pouvez voir comment les articles de l’utilisateur à l’origine. Les user stories faisaient partie d’une fonctionnalité pour « fournir une page d’offre de cours » qui s’aligne sur la vision de haut niveau.,
cartographie D’Impact
bien que l’alignement sur une vision vous aide à remplir votre arriéré initial, ce n’est pas la seule façon de le faire. Il existe de nombreux outils et techniques que les chefs de produit peuvent utiliser pour créer les histoires qui vont dans un nouveau carnet de commandes et qui correspondent à la vision.
Une technique de planification stratégique utilisée pour aider à comprendre la grande image, la cartographie d’impact, a été popularisée par Gojko Adzic, auteur de cinquante idées rapides pour améliorer vos histoires D’utilisateurs et la cartographie D’Impact: faire un grand impact avec des produits et des projets logiciels., La cartographie d’Impact est une carte mentale qui commence par l’objectif, qui devrait aborder la question de la valeur et pourquoi vous construisez le produit.
le niveau suivant répertorie les « acteurs » ou les personnes qui aideront à atteindre l’objectif. Ensuite, la carte répertorie les comportements, ou « impacts », que les acteurs effectueront pour aider à atteindre cet objectif. Le dernier niveau de la carte présente les « livrables » que l’équipe peut mettre en œuvre. Ceux-ci permettent et soutiennent les acteurs de créer les impacts souhaités. C’est à partir de ces livrables que vous dérivez les fonctionnalités et les histoires du logiciel.,
- objectif: rendre largement disponibles les cours que les étudiants voudront suivre
- acteurs: formateurs, étudiants
- Impacts: les formateurs fourniront des cours de haute qualité qui intéressent les étudiants; les étudiants fourniront des références et des recommandations
- livrables: des cours de haute qualité accessibles aux étudiants
- histoires potentielles:
- « En tant que formateur, je veux annoncer des cours, afin que je puisse obtenir des étudiants.
- » En tant que formateur, je veux obtenir les commentaires des étudiants, afin de pouvoir m’améliorer continuellement., »
- » En tant que formateur, je veux savoir ce que les étudiants veulent, afin que je puisse ajouter à mon programme. »
- » En tant qu’étudiant, je veux trouver des cours qui m’intéressent le plus. »
- » En tant qu’étudiant, je veux trouver des cours que je peux suivre en ligne, afin de ne pas avoir besoin de voyager. »
- » En tant qu’étudiant, je veux lire les commentaires des autres, afin de pouvoir décider quelles classes me conviendront le mieux. »
La cartographie des histoires d’utilisateurs de cette manière permet une traçabilité dans le processus de pensée de la façon dont les histoires créent finalement de la valeur et comment vous les utilisez pour atteindre l’objectif final., L’idée n’est pas de tout mettre en œuvre, mais de trouver le chemin le plus court à travers la carte pour atteindre votre objectif.
fractionnement d’histoires
l’un des problèmes les plus courants rencontrés par les équipes agiles est lorsque les histoires sont trop grandes et ne peuvent pas être complétées en une itération. Lorsque l’équipe crée les tâches associées à l’histoire, elle se rend compte qu’il y a trop d’inconnues, ou que les tâches impliquées prendront plus de temps que ce que l’équipe a Disponible en une seule itération. Les équipes abordent parfois ce problème en divisant une histoire plus grande en histoires plus petites.,
N’oubliez pas, cependant, que vous souhaitez qu’un user story fournisse un logiciel fonctionnel qui ajoutera de la valeur à l’utilisateur. Plutôt que de créer une histoire utilisateur qui ne remplira que partiellement une fonction, divisez les histoires en « tranches verticales” qui fourniront des fonctionnalités de bout en bout.
faites appel à la communauté pour un apprentissage plus approfondi
des solutions détaillées sur la façon de résoudre les problèmes les plus difficiles liés aux exigences et aux histoires d’utilisateurs sont uniques à chaque situation. Cependant, un trait commun des praticiens agiles qui réussissent est qu’ils sont désireux d’aider les autres et de partager ce qu’ils savent.,
le site web userStories de Cohn permet à ceux qui travaillent avec des backlogs de produits et des user stories de partager des produits, des ressources et des connaissances. La page des produits comprend une liste impressionnante d’outils, dont beaucoup sont disponibles gratuitement, avec des possibilités d’avis et de commentaires des utilisateurs. Cohn note sur le site qu’il espère étendre le site afin que les arriérés de produits puissent être partagés.
Il n’y aura jamais de réponse unique sur la façon d’écrire des histoires d’utilisateurs parfaites., Cependant, avec le temps, avec un mélange sain d’expérience, de conseils des experts et d’expérimentation avec des outils et des techniques suggérés, vous pouvez continuellement vous améliorer.