User Story vs exigence

User Story capture ce que l'utilisateur veut faire avec le système à un niveau élevé. Je comprends que la user story conduirait davantage à un nombre d'exigences de bas niveau. La user story est-elle la même chose que l'exigence de haut niveau pour le système?

Pour être honnête, après avoir passé près de deux ans dans le développement Agile, je pense toujours que "user story" n’est qu’un terme sophistiqué pour "exigence fonctionnelle".

C'est différent à un niveau superficiel , par exemple, 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 raison d'être - sont également inhérents au bien. exigences fonctionnelles écrites. Il est tout aussi facile d'écrire une mauvaise histoire d'utilisateur que d'écrire une mauvaise exigence ( "en tant que [nom de notre société], je veux [caractéristique vague] pour pouvoir faire [quelque chose qui fait évidemment partie de mon travail, comme 'vendre plus aux clients'] " ).

D'après mon expérience, les histoires d'utilisateurs ne capturent presque jamais les besoins non fonctionnels comme les performances et la sécurité. Il est très difficile d’écrire correctement ces types d’exigences et le format de la user story n’est tout simplement pas très bon pour les capturer, car il s’agit davantage de la qualité générale du produit et de la réduction (sans la suppression) des risques que de la satisfaction d’un utilisateur spécifique. avoir besoin.

Donc, je pense vraiment aux histoires d'utilisateurs comme à un sous - ensemble d'exigences, avec une formule spécifique, et j'utilise toujours les termes à peu près de manière interchangeable.

Le principal avantage des histoires d'utilisateurs par rapport aux exigences est que le mot "exigence" suggère qu'une fonctionnalité est requise là où elle est souvent simplement souhaitée . Les histoires d'utilisateurs peuvent théoriquement être classées par ordre de priorité et insérées dans n'importe quelle version, alors que les exigences semblent être une condition préalable à chaque version.

Bien entendu, pour que la distinction susmentionnée ait de l'importance, vos clients et / ou vos dirigeants doivent l'accepter; cela ne sert à rien si vous avez 30 user stories regroupées dans un "projet" qui doivent toutes être terminé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 des user stories ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) en mettant l'accent sur une carte (brève description), une conversation entre les clients et l'équipe de livraison une fois une user story. devient une action, et la confirmation convenue d'une histoire après cette conversation.

essentiellement, avant la conversation, les histoires 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 complète. Ainsi, selon le moment où vous regardez l'histoire dans cette chronologie, une histoire peut être simplement une idée générale de la portée ou une exigence détaillée.

De nos jours, la signification de "user story" semble être réduite à 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 conditions requises.

Vous pouvez trouver une tonne de pépites d'or de sagesse sur les user stories 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 présupposent que la conception de l'application est faite à l'avance et que le développement correspond à la mise en œuvre de cette conception. Les exigences portent donc sur la manière de mettre en œuvre une fonctionnalité.

Exemple de besoin:

• Créez un formulaire de contact utilisateur avec les champs suivants: nom, prénom, email, texte libre et un bouton d'envoi. Lorsque vous cliquez sur le bouton d'envoi, un courrier électronique est envoyé à notre équipe d'assistance.

Histoires d'utilisateurs

Les histoires d'utilisateurs se concentrent sur les objectifs à atteindre et insistent sur le fait que la conception du produit est réalisée à la dernière minute et qu'il s'agit d'une collaboration entre une personne chargée du produit et une personne chargée du développement. 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 pour pouvoir m'aider.

Quelle est la différence?

Comme vous pouvez le constater, le nombre de détails fournis est certes différent, mais de nombreuses informations ne sont disponibles que dans le récit, à savoir le but que nous essayons d'atteindre avec cette fonctionnalité.

Même s'il peut sembler que l'objectif est relativement peu important, il s'agit d'une hypothèse erronée dans le développement agile. Il existe généralement deux cas dans lesquels connaître le but est très important: réduire le coût des opportunités et permettre l’agilité.

Coût d'opportunité

S'il existe des hypothèses cachées dans l'exigence, cela pourrait être très difficile à réaliser. Par exemple: un serveur de messagerie est-il disponible? Si ce n’est pas le cas, l’exigence risque de prendre beaucoup plus de temps à être développée. Dans d’autres cas, il est possible que la conception ne permette pas d’atteindre un objectif plus simple.

En revanche, la user story concerne un utilisateur qui contacte notre service de support. Si l'envoi d'un courrier est impossible ou trop coûteux, nous pouvons concevoir une solution différente sur-le-champ: écrire dans une base de données, par exemple, utiliser un formulaire via Google Documents ou simplement mettre une adresse e-mail à la place du formulaire. Cela ne peut pas être facilement fait avec une exigence, mais c'est facile avec une histoire et une personne 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’ya 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 différence énorme entre les histoires et les exigences qui est la hiérarchie . Comme je l'ai expliqué plus haut, les exigences doivent, de par leur nature, être ordonnées selon une hiérarchie naturelle afin que les dépendances soient satisfaites. Les histoires, par contre, se concentrent sur le but recherché et n’ont aucune contrainte de ce type.

Ceci est voulu par la conception, car dans l'agilité, il est d'une importance fondamentale d'ajouter, de supprimer, de replanifier et de modifier les récits 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 pénible 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 mise en œuvre agile en souffrira, ou ne le sera probablement pas du tout, en ce sens qu’il sera capable d’accepter le changement.

Pour moi, un élément essentiel d’une User Story est qu’il capture le pourquoi et le comment un utilisateur utilise le système. Ceci est particulièrement utile car il ne spécifie pas grand-chose sur la manière dont le système fournit les fonctionnalités requises. Lorsque des tests d'interface utilisateur et d'utilisabilité sont nécessaires, la User Story peut être le document le plus important.

Bien sûr, vous pouvez demander au sélénium de vérifier que certains nœuds sont présents dans le code HTML ou de faire des captures d’écran, ou de vérifier que certains pixels sont là où vous espérez. Mais s'il y a un texte trompeur, ou si on ne voit pas comment l'utilisateur devrait utiliser le système ou s'il est difficile pour un utilisateur de trouver comment atteindre son objectif, soudain, vous ne disposez plus d'un 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.

Un état d’esprit capturé dans des scénarios d’utilisateur / scénarios devrait influencer de nombreuses décisions de conception détaillées concernant la mise en œuvre. À moins que les développeurs ne parlent directement aux utilisateurs ou ne les regardent pas utiliser le système, le scénario utilisateur peut être le seul lien leur permettant de comprendre les besoins de l'utilisateur.

Enfin, ils permettent aux gens d’affaires de spécifier 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 la suivante: "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 inclure aucun détail sur la manière dont le système devrait être mis en place. Il devrait 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 dans lequel il a saisi des données non valides et ne réalise pas le problème pendant des semaines." Il ne faut pas dire: "Le système doit accepter un fichier CSV latin1 au moins une fois par mois et émettre 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 du test, revenez au scénario pour vous assurer que la solution répond aux besoins. Les exigences peuvent associer certains besoins à certaines solutions, voire se concentrer entièrement sur des solutions.

Je suis tombé par hasard sur cela lors d’une recherche sur Google et j’ai pensé que jetterais mon opinion dans

Il n'y a vraiment pas de 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 manière dont cet objectif ou résultat est capturé par un analyste métier. Dans ce cas, c'est dans la formulation.

Exemple:

En tant que chef d'équipe, je souhaite voir les membres de mon équipe qui travaillent sur des dossiers de prêt hypothécaire afin de pouvoir surveiller leur performance.

La solution doit afficher les membres de l'équipe travaillant sur des dossiers hypothécaires.

Les deux réponses ci-dessus pourraient être interprétées 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 principalement est de savoir jusqu'où la définition de la solution ira avant que nous ayons quitté le monde des exigences et le monde de la conception fonctionnelle. L’analyste commercial doit-il indiquer «Liste des utilisateurs connectés par nom et prénom dans le menu principal de l’application» ou est-ce trop d’informations? Lorsque nous sommes assis et que nous discutons avec nos parties prenantes, nous connaissons tous la solution et pouvons interpréter son apparence. Même le langage de code sur lequel il sera probablement construit et la manière dont il sera déployé nécessitent réellement de jouer le jeu puriste de " définissons des objectifs et non des solutions ". C’est là que je sens vraiment la confusion.

Les exigences supposent souvent que nous ne savons rien de la solution mais des résultats souhaités. Oui, cela rend toute solution agnostique, mais est-ce que cela nous aide vraiment dans le cycle de développement? Si nous pouvons définir avec précision quelque chose au début, pourquoi ne pas le faire?

Dans l'ensemble, je ne voudrais pas m'inquiéter des histoires d'utilisateurs et des différences d'exigences. En fin de compte, vous souhaitez définir suffisamment d’informations pour qu'une personne puisse développer une solution. Une user story de niveau trop élevé sera simplement annulée et demandée pour être décomposée en user stories plus petites. Identique à "Le système doit" à la mode. Les exigences seront probablement considérées comme trop ambiguës si elles ne sont pas suffisamment détaillées.

En fin de compte, allez avec ce que vos développeurs et parties prenantes aiment voir et travailler à partir de cela.

Je pense qu'il y a beaucoup d'incohérences dans la signification du mot exigences, même dans les manuels classiques. La même incohérence s'applique aux user stories. Différents organismes et manuels traitent ces termes différemment. Par exemple, comment le manuel classique du génie logiciel de Roger Pressman parle des exigences est assez différent du livre Agile Software Requirements de Dean Leffingwell. Je les respecte tous les deux et ils peuvent tous les deux être valables.

Les exigences peuvent être des éléments que nous codons qui ont une spécificité extraordinaire avec très peu d'imagination. D'un autre côté, on peut faire valoir que les exigences doivent spécifier quel est le problème de l'entreprise et non la solution. Je pense cependant qu’il est plus nuancé et que la réponse se situe quelque part dans un spectre unique à chaque entreprise et à chaque secteur d’activité (tous les développements logiciels ne se produisent pas en informatique).

On m'a appris que l' élicitation d' exigences conduit à une analyse, à une conception, à une architecture conduisant à une élaboration ou à une spécification d' exigences , à une codification. Je ne crois pas que cela disparaisse avec agilité. Le moment auquel ces événements se produisent change, et c’est la différence la plus importante. Dans le modèle en cascade, la sollicitation et l'élaboration se produisent tôt. En lean and scrum, l'élicitation et l'élaboration se produisent à différentes étapes, avec plus d'élaboration à mesure que vous approchez de la mise en œuvre dans un sprint. De même que le travail de conception émergent.

Dans notre organisation, nous nous orientons vers le modèle de Leffingwell: Epics, Features and Stories, non pas en tant qu’exigences, mais en tant que répartition du travail et hiérarchisation des priorités. Les exigences sont une chose différente. 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 au sein des histoires d'utilisateurs lors de l'incrémentation du programme et de la planification du sprint.

Les exigences fonctionnelles sont généralement une spécification formelle qui vous permet de savoir exactement si votre logiciel fonctionne ou non. Les user stories sont généralement un moyen beaucoup plus informel de décrire un besoin de votre user story. Il ne spécifie pas de spécification rigide pour déterminer si le logiciel est "valide" ou "non valide". Bien que vous puissiez en tester une partie, le véritable accomplissement d’une histoire d’utilisateur (si vous le faites correctement) c’est lorsque votre utilisateur dit "ouais, ça résoudra 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 précise que certaines choses ne correspondent pas à une user story et que vous n'êtes pas obligé de l'utiliser uniquement .

Dans ma propre équipe, nous utilisons les éléments suivants:

• User story : un besoin professionnel d'un 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, mais de plonger dans le besoin réel de l’utilisateur (ex: il n’a pas besoin de visualiser les données dans une table, il a besoin de voir la valeur exacte du données, et il est familier avec table pour faire exactement cela).
• Bug : comportement inattendu du logiciel qui gêne l'utilisation normale. Vient généralement avec une "importance" (indépendante de la priorité du développement) qui évalue à quel point cela 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 à l'avenir, développeurs. Exemple: certaines classes sont difficiles à lire, la construction est lente, certains codes ne sont pas testés à l'unité, l'IDE affiche des avertissements étranges ...
• Amélioration : une modification du logiciel qui ne permet pas de nouveaux scénarios, mais offre une expérience plus agréable. Exemple: changer les polices, redéfinir un formulaire pour le rendre plus clair, ajouter des valeurs par défaut sensibles à l'application, etc.

Les exigences fonctionnelles ne nous permettraient pas de comprendre qu'une fonctionnalité que nous avons implémentée ne répond pas au besoin d'un utilisateur, même si notre test de concombre a réussi et que nous avons implémenté chaque mot écrit. Une histoire est une discussion et elle est informelle. Le but est que les responsables de la mise en œuvre comprennent 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 pas de différence.

Ce n’est pas l’histoire de l’utilisateur, mais bien l’énorme changement de paradigme dans la façon dont vous abordez le travail à accomplir. 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 des outils de discussion avec un utilisateur réel , vous n'utilisez pas les user stories, vous utilisez une syntaxe géniale avec les exigences .

Le reste, à mon avis, une histoire d'utilisateur ne peut jamais réussir de manière unilatérale. Vous avez besoin de votre client pour travailler avec elle. La chute d'eau est vouée à devenir un gâchis bizarre, mais pas obligatoire. Si vous avez un contrat à soumission fixe avec des exigences spécifiques, n'utilisez pas d'itérations et de user story, cela ne sert à rien . Utilisez le reste de la boîte à outils agile: test unitaire / fonctionnel automatisé, révision du code, intégration continue, refactorisation, etc. Assurez-vous que votre logiciel fonctionne en permanence et que vous pouvez l'expédier à tout moment. Rendez-le disponible sous sa forme brute au client afin qu'il puisse donner le plus de commentaires possible. Si vous faisiez cela, mon ami, même si vous n'aviez pas fait "User story" et "Scrum", vous auriez été plus agile que beaucoup de gens dits "agiles".

Je pense que tout le monde va mettre en œuvre et étiqueter chaque chose différemment en fonction de l'expérience passée et la langue employée par cette entreprise ne doit pas être discutée.

Cependant, IMO, A User Story suit l'approche Agile de "un client dans l'immeuble ou le client est immédiatement disponible", où la documentation n'est pas nécessairement nécessaire, car les détails sont dans la tête du client et facilement disponibles afin qu'un SRS formel puisse ne pas être nécessaire. Maintenant, une "tâche" d'une "user story" est comment un développeur va construire les user stories en digestible.

Un exemple de user story pourrait ê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:

1. Créer une grille qui liste les données à afficher

2. Activer le tri sur la grille qui va trier la colonne sélectionnée

Chacune des tâches est maintenant estimée et complétée dans son sprint respectif.

D'un point de vue "traditionnel", où "le client est difficile à trouver, nous devons l'écrire pour qu'il puisse confirmer que tout est en ordre avant de commencer à planifier / coder", la spécification des exigences logicielles est la suivante: Ce sont les idées qui étaient dans la tête des clients et qui ont été suscitées, puis écrites et formalisées, puis définies et gérées.

Dans ce cas, une "exigence fonctionnelle" est le détail essentiel de ce SRS, et une partie de l'idée plus large. Donc, à mon avis, une user story pourrait être considérée comme une (partie de) "l'exigence" formelle, et la tâche de cette user story est une (ou une des nombreuses) exigences fonctionnelles.

Dans l'exemple d'utilisateur, le "besoin" formel serait un document volumineux avec des organigrammes et sera généralement centré 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 ressembler à un document de 10 pages décrivant la section d'administration de l'application qui indique que des listes seront nécessaires, une sécurité basée sur les rôles, etc., puis une partie de la fonctionnalité. les exigences seront "les grilles de listage doivent permettre le tri", "les informations utilisateur doivent être répertoriées dans une grille", etc.

et je crois que ces jours-ci les termes sont tous mélangés et mélangés .. qui n'a pas d'importance du tout