User Story vs Exigence
User Story capture ce que l'utilisateur veut faire avec le système à un niveau élevé. Je comprends que l'histoire de l'utilisateur entraînerait davantage un certain nombre d'exigences de bas niveau. L'histoire de l'utilisateur est-elle identique à l'exigence de haut niveau pour le système?
Pour être honnête, après avoir passé près de deux ans immergé dans le développement Agile, je pense toujours que "user story" n'est qu'un terme de fantaisie pour "exigence fonctionnelle".
C'est différent à un niveau superficiel, par ex. il prend toujours une certaine forme ("en tant que X, je veux Y pour que Z ..."), mais les éléments clés - l'identification de la partie prenante et la justification - sont également inhérents à des textes bien écrits exigences fonctionnelles. Il est tout aussi facile d'écrire une mauvaise histoire d'utilisateur que d'écrire une mauvaise exigence ("comme [nom de notre entreprise], je veux [une caractéristique vague] pour que je puisse [faire quelque chose qui fait évidemment partie de mon travail, comme "vendre plus aux clients"] ").
Quelles histoires d'utilisateurs captent presque jamais, d'après mon expérience, sont non fonctionnelles des exigences telles que les performances et la sécurité. Ces types d'exigences sont très difficiles à écrire correctement et le format de la user story n'est tout simplement pas très bon pour les capturer, car ils concernent davantage la qualité générale du produit et l'atténuation (mais pas l'élimination) des risques plutôt que la satisfaction d'un utilisateur spécifique avoir besoin.
Donc, je pense vraiment aux user stories comme sous-ensemble d'exigences, avec une formule spécifique, et j'utilise toujours les termes de manière assez interchangeable.
Le seul avantage majeur des user stories sur les exigences est que le mot "exigence" suggère qu'une fonctionnalité est obligatoire où elle est souvent juste souhaitée. Les user stories peuvent en théorie être hiérarchisées et insérées dans n'importe quelle version, alors que les exigences semblent être une condition préalable pour chaque version.
Bien sûr, pour que la distinction susmentionnée soit importante, vos clients et/ou la haute direction doivent l'adopter; cela ne sert à rien si vous avez 30 histoires d'utilisateurs regroupées dans un "projet" qui doivent toutes être achevées en même temps. Vous pourriez aussi bien les appeler "exigences" dans ce cas, car elles sont en fait obligatoires.
Ron Jeffries a écrit il y a longtemps sur les 3C d'histoires d'utilisateurs ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) en mettant l'accent sur une carte (brève description), la conversation entre les clients et l'équipe de livraison une fois qu'une user story devient exploitable, et la confirmation convenue d'une story après cette conversation.
essentiellement, avant la conversation, les récits d'utilisateurs ne sont qu'une portée planifiée - des idées approximatives sur ce que nous pourrions faire. après la conversation, vous devriez avoir un moyen de confirmer que l'histoire est terminée. Donc, selon le moment où vous regardez l'histoire dans cette chronologie, une histoire peut être juste une idée générale de la portée ou une exigence détaillée.
de nos jours, le sens de "user story" semble être limité à la partie "carte" des 3C de Jeffries. dans ce cas, une user story n'est pas une exigence mais une promesse de tenir une conversation sur les exigences.
Vous pouvez trouver une tonne de pépites d'or de sagesse sur les histoires d'utilisateurs sur le wiki c2 ( http://xp.c2.com/UserStory.html )
Les histoires d'utilisateurs et les exigences sont des bêtes très différentes.
Exigences
Les exigences supposent que la conception de l'application soit effectuée à l'avance et que le développement soit la mise en œuvre de cette conception. Les exigences se concentrent donc sur comment pour implémenter une fonctionnalité.
Exemple d'exigence:
- Créez un formulaire de contact utilisateur avec les champs suivants: nom, prénom, email, texte libre et un bouton de soumission. Lorsque vous appuyez sur le bouton Soumettre, un e-mail est envoyé à notre équipe d'assistance.
Histoires d'utilisateurs
Les histoires d'utilisateurs se concentrent sur quoi à réaliser, et insistent sur le fait que la conception du produit se fait à la dernière minute et qu'il s'agit d'une collaboration entre une personne du produit et une personne développeur. Les détails sont décidés lors de la mise en œuvre en fonction des opportunités.
Exemple d'histoire:
- En tant qu'utilisateur Jimmy, je souhaite contacter votre équipe d'assistance lorsque je ne peux pas utiliser le site correctement afin qu'ils puissent m'aider.
Quelle est la différence?
Comme vous pouvez le voir, il y a certainement une différence dans la quantité de détails fournis, mais il y a aussi beaucoup d'informations qui ne sont disponibles que dans l'histoire, à savoir le but ce que nous essayons à réaliser avec cette fonctionnalité.
Bien qu'il puisse sembler que l'objectif soit relativement peu important, il s'agit d'une hypothèse erronée dans le développement agile. Il y a généralement deux cas dans lesquels connaître l'objectif est très important: réduire le coût d'opportunité et permettre l'agilité.
Coût d'opportunité
S'il y a des hypothèses cachées dans l'exigence, cela pourrait être très difficile à réaliser. Par exemple: existe-t-il un serveur de messagerie disponible? Sinon, l'exigence pourrait prendre beaucoup plus de temps à être développée. Dans certains autres cas, un moyen plus simple d'atteindre le même objectif peut être manqué en raison de la conception.
En revanche, l'histoire de l'utilisateur concerne un utilisateur qui contacte notre service d'assistance. Si l'envoi d'un mail est impossible ou trop coûteux, nous pouvons imaginer une solution différente sur place: écrire dans une base de données, par exemple, ou utiliser un formulaire via Google docs, ou simplement mettre une adresse e-mail à la place du formulaire. Cela ne peut pas être fait facilement avec une exigence, mais cela se fait facilement avec une histoire et une personne du produit présente.
Agilité
Pour cette raison, avec les exigences, nous avons généralement tendance à penser à ces hypothèses cachées à l'avance et à nous assurer qu'il n'y a pas de problèmes. Donc, dans ce cas, il pourrait y avoir une exigence différente, planifiée à l'avance, qui garantissait la présence d'un serveur de messagerie.
Cela nous amène à une autre énorme différence entre les histoires et les exigences qui est hiérarchie. Comme je l'ai illustré ci-dessus, les exigences doivent, par leur propre nature, être ordonnées dans une certaine hiérarchie naturelle afin que les dépendances soient respectées. Les histoires, en revanche, se concentrent sur le but et n'ont pas de telles contraintes.
C'est par conception, car en agile, il est d'une importance fondamentale d'ajouter, de supprimer, de replanifier et de modifier les histoires selon les besoins pendant l'exécution du projet. Les exigences peuvent généralement être ajoutées, parfois modifiées ou supprimées, mais il est généralement très difficile de les déplacer en raison de toutes les dépendances. Ce n'est tout simplement pas fait très souvent. Si vous travaillez avec des exigences, votre implémentation agile souffrira, ou ne sera probablement pas très agile du tout, dans le sens d'être capable d'embrasser le changement.
Pour moi, un élément critique d'une User Story est qu'elle capture pourquoi et comment un utilisateur utilise le système. Il est particulièrement utile car il ne spécifie pas beaucoup sur la manière dont le système fournit les fonctionnalités requises. Lorsque des tests d'interface utilisateur et de convivialité sont nécessaires, la User Story peut être le document le plus important.
Bien sûr, vous pouvez demander à Selenium de vérifier que certains nœuds sont présents dans le code HTML ou de prendre des captures d'écran, ou de vérifier que certains pixels sont là où vous espérez qu'ils se trouvent. Mais s'il y a du texte trompeur, ou si on ne sait pas comment l'utilisateur doit utiliser le système ou s'il est difficile pour un utilisateur de comprendre comment atteindre son objectif, du coup, vous n'avez plus de système complet. Maintenant, une formation est nécessaire pour utiliser le système. L'examen du système terminé par rapport aux scénarios utilisateur est un élément essentiel des tests manuels.
Il y a un état d'esprit capturé dans les user stories/scénarios qui devrait influencer de nombreuses décisions de conception détaillées sur la mise en œuvre. À moins que les développeurs ne parlent directement aux utilisateurs ou ne les regardent utiliser le système, le scénario utilisateur peut être le seul lien pour leur permettre de comprendre les besoins des utilisateurs.
Enfin, ils permettent aux gens d'affaires de préciser ce dont ils ont besoin sans suggérer comment cela devrait être réalisé. Il est beaucoup plus facile de décrire une solution qu'un besoin et les scénarios utilisateur fournissent un cadre pour décrire les besoins sans proposer de solution spécifique. L'exigence commerciale la plus courante que j'ai entendue est: "Je veux que ce soit comme Excel, mais sur le Web", ce qui n'a jamais été ce dont ils avaient réellement besoin.
Je dirais donc qu'une bonne histoire ne devrait pas contenir de détails spécifiques sur la façon dont le système devrait être mis en œuvre. Il doit indiquer: "Une fois par mois, le système A doit être mis à jour avec toutes les nouvelles données du système B. Ces données peuvent nécessiter des corrections. Le client a un historique de saisie de données non valides et ne se rend pas compte du problème pendant des semaines." Il ne doit pas dire: "Le système doit accepter un fichier CSV latin1 au moins une fois par mois et lever une exception NumberFormatException si la colonne 3 n'est pas un nombre." Voyez-vous la différence? Le scénario décrit le besoin, pas une solution spécifique. Ensuite, lors des tests, vous revenez au scénario pour vous assurer que la solution correspond au besoin. Les exigences peuvent mélanger certains besoins avec certaines solutions, ou même se concentrer entièrement sur des solutions.
Je suis tombé dessus lors d'une recherche sur Google et j'ai pensé que je donnerais mon avis.
Il n'y a vraiment aucune différence entre une exigence et une user story. Les deux indiquent le résultat ou l'objectif souhaité du point de vue de l'utilisateur.
La seule différence est la façon dont cet objectif ou ce résultat est capturé par un analyste commercial. Dans ce cas, c'est dans le libellé.
Exemple:
En tant que chef d'équipe, je veux voir laquelle de mes équipes travaille sur des dossiers hypothécaires afin de pouvoir surveiller leurs performances.
La solution affichera les membres de l'équipe travaillant sur des dossiers hypothécaires.
Les deux éléments ci-dessus pourraient être interprétés de la même manière, mais les deux ont également beaucoup d'ambiguïté. Le point principal ici est une différence de style. Je pense que le problème que nous voyons le plus est de savoir jusqu'où dans la définition de la solution allons-nous avant de sortir du monde des exigences et du monde de la conception fonctionnelle. Est-ce à l'analyste commercial de déclarer "lister les utilisateurs connectés par prénom et deuxième nom dans le menu principal de l'application" ou est-ce trop d'informations? Lorsque nous discutons avec nos parties prenantes et que nous connaissons tous la solution et pouvons interpréter à quoi elle ressemblera, même le langage de code probable sur lequel elle sera construite et la façon dont elle sera déployée nous faut-il vraiment jouer le jeu puriste de " définissons des objectifs et non des solutions ". C'est là que je ressens vraiment la confusion.
Les exigences supposent souvent que nous ne savons rien de la solution, juste les résultats souhaités. Oui, cela rend la solution tout indépendante, mais cela nous aide-t-il vraiment dans le cycle de développement? Si nous pouvons définir avec précision quelque chose au début, alors pourquoi ne pas le faire?
Dans l'ensemble, je ne m'inquiéterais pas des histoires d'utilisateurs et des différences d'exigences. En fin de compte, vous souhaitez définir suffisamment d'informations pour que quelqu'un puisse développer une solution. Une user story trop élevée sera simplement repoussée et demandée à être décomposée en user stories plus petites. Identique à un style "le système doit". L'exigence sera probablement repoussée comme étant trop ambiguë si elle n'a pas suffisamment de détails.
À la fin, allez avec ce que vos développeurs et vos parties prenantes aiment voir et travailler à partir de cela.
Je pense qu'il y a beaucoup d'incohérence sur la signification des exigences de Word, même dans les manuels classiques. La même incohérence s'applique aux user stories. Différentes organisations et manuels traitent ces termes différemment. Par exemple, la façon dont le manuel classique de Roger Pressman sur le génie logiciel parle des exigences est assez différente de celle du livre Agile Software Requirements de Dean Leffingwell. Je les respecte tous les deux et ils peuvent tous deux être valides.
Les exigences peuvent être des choses que nous codons et qui ont une spécificité extraordinaire avec peu de place à l'imagination. D'un autre côté, on peut affirmer que les exigences doivent spécifier quel est le problème commercial et non spécifier la solution. Je pense que c'est plus nuancé cependant et la réponse se situe quelque part sur un spectre qui est unique à chaque entreprise et industrie (tous les développements de logiciels ne se produisent pas en informatique).
On m'a appris que les exigences la sollicitation conduisent à l'analyse, cela mène à la conception, cela mène à l'architecture qui mène aux exigences - élaboration ou spécification, qui mène à quelque chose qui peut être codé. Je ne pense pas que cela disparaisse avec l'agilité. Le moment où ces choses se produisent change et c'est la différence la plus importante. Dans le modèle en cascade, l'élicitation et l'élaboration se produisent tôt. Dans le maigre et le scrum, l'élicitation et l'élaboration se produisent à différentes étapes avec plus d'élaboration à mesure que vous vous rapprochez de la mise en œuvre dans un sprint. Tout comme les travaux de conception émergents.
Dans notre organisation, nous nous penchons vers le modèle Leffingwell des épopées, des fonctionnalités et des histoires, non pas comme des exigences mais comme une répartition du travail et une priorisation. Les exigences sont différentes. Les exigences sont gérées séparément, car nous sommes tenus de le faire pour les organismes de réglementation. Et pourtant, certaines équipes développent certainement des exigences dans les user stories lors de l'incrémentation du programme et de la planification du sprint.
Je crois que tout le monde mettra en œuvre et étiquettera tout différemment selon l'expérience passée et quelle que soit la langue qui fonctionne pour cette entreprise qui fait le travail ne vaut pas la peine d'être débattue.
Cependant, IMO, A User Story suit l'approche Agile de "un client dans le bâtiment ou le client est immédiatement disponible", où la documentation n'est pas nécessairement nécessaire parce que les détails sont dans la tête du client et facilement disponibles afin qu'un SRS formel puisse pas nécessaire. Maintenant, une "tâche" d'une "User story" est de savoir comment un développeur va construire les user stories en digestible.
Un exemple d'utilisateur peut être:
En tant qu'administrateur, je souhaite afficher les données de mes clients répertoriées dans une grille
et une "tâche" pourrait être:
Créer une grille qui répertorie les données à afficher
Activer le tri sur la grille qui triera la colonne sélectionnée
Maintenant, chacune des tâches est estimée et terminée dans son sprint respectif.
Du point de vue "traditionnel", où "le client est difficile à saisir, nous devons l'écrire afin qu'il puisse confirmer que nous avons bien compris avant de commencer la planification/le codage", la spécification des exigences logicielles est va être les idées qui étaient dans la tête des clients et suscitées, puis écrites et formalisées, puis référencées et gérées.
Dans ce cas, une "exigence fonctionnelle" est le détail minutieux de ce SRS, et une partie de l'idée plus large. Donc, à mon avis, une user story peut être considérée comme une (partie de) l'exigence formelle, et la tâche de cette user story est une (ou l'une des nombreuses) exigences fonctionnelles.
Dans l'exemple de la user story, l'exigence formelle serait un long document avec des organigrammes et sera généralement centrée sur la documentation, par opposition à l'approche plus "agile" qui est centrée sur le client.
La différence étant que l'exigence formelle va être dans le sens d'un document de 10 pages décrivant la section d'administration de l'application qui indique que certaines listes seront nécessaires, une sécurité basée sur les rôles, etc., puis une partie des fonctionnalités les exigences seront "les grilles de listage doivent permettre le tri", "les informations utilisateur doivent être listées dans une grille", etc.
et je crois que ces jours-ci, les termes sont tous mélangés et mélangés .. ce qui n'a pas d'importance du tout
Les exigences fonctionnelles sont généralement une spécification formelle qui vous permet de savoir exactement si votre logiciel fonctionne ou non. La user story est généralement un moyen beaucoup plus informel de décrire le besoin d'une de vos user stories. Il ne spécifie pas de spécification rigide pour déterminer si le logiciel est "valide" ou "invalide". Bien que vous puissiez en tester une partie, l'achèvement réel d'une user story (si vous les faites correctement) est lorsque votre utilisateur dit "oui, cela résout mon problème!". Rappelez-vous le manifeste agile:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Dans son livre "User Story Applied", Mike Cohn dit spécifiquement que certaines choses ne correspondent pas à la user story et que vous n'avez pas à utiliser uniquement cette.
Dans ma propre équipe, nous utilisons les éléments suivants:
- ser story: un besoin commercial d'une sorte d'utilisateur. L'accent est mis ici sur le besoin , et pourquoi en a-t-il besoin. Comme d'autres l'ont dit, l'important ici n'est pas de spécifier comment cela se fait, et d'aller au fond des besoins réels de l'utilisateur (ex: il n'a pas besoin pour afficher les données dans un tableau, il doit voir la valeur exacte des données, et il est familier avec le tableau pour faire exactement cela).
- Bug: Un comportement inattendu du logiciel qui nuit à une utilisation normale. Habituellement, il y a une "importance" (indépendante de la priorité de développement) qui évalue dans quelle mesure elle affecte le flux de travail de l'utilisateur.
- Dette technique. Quelque chose qui n'empêche pas l'utilisation du logiciel mais qui nous gênera , les développeurs, à l'avenir . Exemple: certaines classes sont difficiles à lire, la construction est lente, certains codes ne sont pas testés à l'unité, les IDE affichent des avertissements étranges ...
- Amélioration: un changement dans le logiciel qui ne permet pas de nouveaux scénarios, mais en fait une expérience plus agréable. Exemple: changer les polices, repenser un formulaire pour le rendre plus clair, ajouter un défaut sensible à l'application, etc.
Les exigences fonctionnelles ne nous permettraient pas de réaliser qu'une fonctionnalité que nous avons implémentée ne résout pas le besoin d'un utilisateur, même si notre test de concombre réussit et que nous avons implémenté chaque mot écrit. Une histoire est une discussion, et c'est informel. Le point est pour les gars de la mise en œuvre de comprendre quelle est la problématique. Ils ne sont pas un outil contractuel. Si vous faites "scrum but ..." et que votre histoire est simplement une façon amusante d'écrire les exigences du logiciel, alors oui, il n'y a non différence.
Le point n'est pas l'histoire de l'utilisateur, le point est l'énorme changement de paradigme dans la façon dont vous approchez le travail à faire. Vous ne faites pas de contrat, vous aidez certains de vos utilisateurs à résoudre un problème. Si vous ne voyez pas vos user stories comme un outil de discussion avec un vrai utilisateur, alors vous n'utilisez pas user histoires, vous utilisez une syntaxe d'exigences funky .
Le reste ici est mon avis: la user story ne pourra jamais réussir de façon unilatérale. Vous avez besoin de votre client pour travailler avec lui. La chute d'eau est vouée à être un gâchis étrange mais pas obligatoire. Si vous avez un contrat d'enchère fixe avec des exigences spécifiques, n'utilisez pas d'itérations et de user story, il n'y a aucun point . Utilisez le reste de la boîte à outils agile: test unitaire/fonctionnel automatisé, révision de code, intégration continue, refactoring, etc. Assurez-vous que votre logiciel fonctionne en permanence et que vous pouvez l'expédier à tout moment. Mettez-le à la disposition du client dans sa forme inachevée afin qu'il puisse donner autant de commentaires que possible. Si vous faites ça mon ami, même si vous n'avez pas fait "User story" et "Scrum", vous auriez été plus agile que beaucoup de soi-disant "Agile" boutique.