Comment les user stories ne contiennent-elles pas d'exigences (lorsqu'elles sont écrites sur une carte) et peuvent-elles être mises en œuvre

On m'a dit « Les histoires d'utilisateurs ne sont pas exigences, il est juste un rappel de ce que le client veut, vous ne pouvez pas définir des exigences dans une histoire ». Mais prenons l'exemple d'un client qui souhaite un traitement différent pour différentes cartes de crédit. Il existe des exigences strictes qui doivent être implémentées et connues pour que les cas de test puissent être écrits. Où devraient aller les exigences sinon dans la user story?

Comment les développeurs peuvent-ils développer à partir d'une histoire s'il n'y a pas d'exigences inférieures? Comment les testeurs peuvent-ils écrire des cas de test (détaillés) basés sur une user story? Où se situent les exigences telles que les contraintes de base de données, la validation des champs, etc. en dehors de la user story?

Cette réponse mettra l'accent sur la façon de travailler avec Histoires et exigences des utilisateurs de niveau inférieur. Je ne discuterai les mérites, ou l'absence, de Scrum ou Agiles. Je ne vais pas parler de gourous soit.

Cette réponse suppose que vous êtes à bord avec Scrum mais pas encore trouvé un moyen de le faire fonctionner pour vous.

Comme d' autres l' ont mentionné, User Stories sont destinées à couvrir la manière dont les utilisateurs souhaitent que le logiciel soit. Du fait que les utilisateurs ne se soucient pas des choses à faible niveau de mise en œuvre comme base de données, tables de contraintes, modèles architecturaux, etc., vous ne trouverez pas ces informations dans une histoire d'utilisateur.

Cependant, cela ne signifie pas que ces informations ne doivent pas être enregistrés n'importe où.

Lorsque les développeurs mettent en oeuvre Témoignages d'utilisateurs qu'ils doivent être conscients des informations de niveau inférieur Les utilisateurs typiques ne savent. Ces renseignements peuvent provenir des PME, Bas, le propriétaire du produit, votre architecte, ou tout autre expert ou férus de technique.

Est-ce que cela signifie détail bas niveau doivent être enregistrés dans les histoires de l'utilisateur? Non et oui).

À un moment donné, entre le moment où l'histoire est créée et mise en œuvre, quelqu'un devra déterminer comment la mettre en œuvre. Cela prend généralement la forme de conversations avec les personnes impliquées dans l'histoire (User, architecte, développeur, etc). Ces conversations devraient aboutir à univoques Critères d'acceptation qui définissent clairement la portée de la mise en œuvre de l'histoire de l' utilisateur. Ces détails devront être enregistrés quelque part et où cela dépend vraiment de vous. La clé ici est que ces détails sont obtenus après la création de la User Story. Je pense que c'est ce que votre gourou essaie de souligner.

En tant que développeur, il est clair que vous aurez besoin d'un moyen d'associer des exigences plus spécifiques à votre User Story. La façon dont vous procédez dépend entièrement de votre équipe.

Si des membres de votre équipe souhaitent garder ces détails hors des User Stories, vous devrez peut-être respecter cela. Il y a des avantages à garder vos User Stories de haut niveau sans détails de mise en œuvre. Il les maintient allégés et votre carnet de commandes peut être lu comme un historique de ce que vos utilisateurs et propriétaires de produits voulaient. Faites également connaître vos besoins en tant que développeur. Vous devriez être en mesure de trouver un compromis où un simple lien vers la User Story rend tout le monde heureux.

Yup, son BS. Et Scrum n'est pas agile.

Je déteste la rigidité des soi-disant pratiquants agiles qui vous disent qu'il y a une façon de faire agile et que vous devez suivre toutes les règles énoncées dans les saintes écritures de la méthodologie 'agile' qu'ils utilisent. C'est tout BS.

Agile, c'est être agile.

Agile est sur le point d'obtenir des choses fait avec un minimum de frais généraux. Cela ne signifie pas «pas de documentation» car vous finissez généralement par documenter davantage dans un rôle agile, vous continuez simplement la documentation sans avoir à planifier un processus pour faire la documentation. De même pour le codage, les tests et la capture des exigences. Les seules choses qui comptent dans un processus agile sont celles qui vous aident à faire votre travail, rapidement et efficacement sans aucune BS.

Donc, dans ce cas, si mettre des exigences utilisateur dans les cartes vous aide à écrire, tester, documenter et démontrer le code qui est nécessaire ... mettez les exigences sur la carte et dites aux gourous que l'équipe a toujours raison.

Qu'est-ce que le reste de votre équipe de développement pense? Dans une véritable méthodologie agile, s'ils pensent que toutes les exigences doivent être rédigées à l'avant sans « conversations utilisateur » puis qui devrait être, vous faites ce que l'équipe pense que fonctionne le mieux pour eux de faire leur travail. Si l'équipe pense que les conversations des utilisateurs sont une bonne chose, alors écoutez-les et comprenez pourquoi ils pensent cela et introduisez-vous dans leur façon de travailler.

N'appelez pas cela une User Story et tout le monde sera content.

Je pense que la réponse est, vous pouvez écrire cela où vous voulez.

En général, les implémentations spécifiques ne sont pas inclus dans une histoire d'utilisateur pour quelques raisons:

1. Vous savez ce que le client veut, mais vous ne savez pas comment cela va être mis en œuvre.
2. Le client est conscient qu'il ya des exigences plus spécifiques en jeu, mais vraiment ne se soucient pas et / ou les comprennent de toute façon.
3. Tout le monde pense qu'ils sont pleinement conscients des implémentations spécifiques en ce moment, mais personne ne veut les écrire car selon leur expérience, tout va changer de toute façon et personne ne voudra le réécrire.

Il n'y a pas de règles qui omettent des documents supplémentaires si nécessaire. Peut-être que le client a besoin d'y accéder et peut-être pas. Si vous espérez générer une sorte de contrat entre vous et le client sur l'implémentation spécifique, comme si vous pouviez la suivre et quand cela ne fonctionnait pas, blâmer le client de l'accepter, vous vous trompez. Si le client comprend les détails techniques de traitement de carte de crédit, vous devez partager ces documents avec eux et peut-être faire une partie de la conversation.

Je pense que si vos consultants Scrum vous disent que Scrum ne nécessite pas d'exigences, vous avez des consultants très pauvres. Ils ont même tort de vous dire qu'une user story n'est pas du tout une exigence, il s'agit simplement d'un type d'exigence.

Quels sont les différents types de besoins logiciels?

Besoins de l'entreprise

Il s'agit généralement d'un besoin commercial de haut niveau, ce qui équivaut généralement à une sorte de déclaration de style exécutif sur un système. Il est délibérément de haut niveau et large et ne peut en soi être mis en œuvre sans beaucoup plus de détails.

Besoins des utilisateurs

Ce sont les exigences de l'utilisateur Story que vous connaissez. Ils peuvent généralement tenir sur une note collante.

• Acteur - En général , un utilisateur ou une partie prenante.
• Besoin - Un élément ou une fonctionnalité générale dont l'utilisateur a besoin
• Motif - Motif ou contexte expliquant pourquoi ce besoin existe
• Critères d'acceptation - Tel est le cadre pour les tests d'acceptation des utilisateurs et pendant Sprint Demo comment le propriétaire du produit sera en mesure de décider si une histoire d'utilisateur est acceptée ou non.

Exigences fonctionnelles ou système

Cela semble être la pièce manquante de votre puzzle. Chassés des exigences de niveau utilisateur, une exigence fonctionnelle définit les acteurs au niveau du système et les propriétés d'un système, ainsi que les comportements et les fonctions d'un système. Cela pourrait également être fait dans un format d'histoire et inclus dans votre carnet de commandes. Ces éléments doivent être autonomes et peuvent être mis en œuvre indépendamment de toute exigence d'un utilisateur.

• Acteur - Un système ou un composant quelconque.
• Besoin - Besoin, propriété ou déclaration de comportement d'un système qui devrait exister.
• Motif - Un contexte expliquant pourquoi cela est nécessaire dans le système
• Critères d'acceptation - Scénarios, comportements, fonctions et flux qui sont nécessaires pour communiquer comment les tests du système et de l'intégration doivent être effectués. Lorsque ces types de tests sont réussis pour l'exigence, nous savons que cette exigence fonctionnelle est terminée. Ceux-ci peuvent exister dans la documentation externe de vos user stories mais doivent être complétés avant que ces stories soient affectées dans un sprint.

Les exigences fonctionnelles définissent votre solution, ce qui ressemble à ce que vous décrivez comme une lacune dans votre processus.

Types d'exigences notables qui doivent être mentionnés mais qui sont sans conséquence pour votre question: exigences non fonctionnelles, exigences techniques, etc.

Une User Story est un type d'artefact spécifique dans le but de décrire l'interface que l'utilisateur attend du système et c'est pourquoi les détails de bas niveau n'y appartiennent tout simplement pas. Si vous les mettez là, vous changez l'intention de l'artefact et il ne correspond plus à la définition des États-Unis.

Utilisez d'autres formes de spécifications pour capturer les exigences de niveau inférieur et les décisions de conception. La nature exacte de ces autres formulaires doit être résolue dans votre organisation et adaptée à votre environnement spécifique.

Votre question ressemble beaucoup à quelque chose comme

J'ai cette CarFactory et je dois aussi la faire fabriquer des vélos, mais notre OOD "Guru" dit que je ne suis pas autorisé à le faire. Qu'est-ce que ce BS!?!

Respectez la séparation des préoccupations et la cohésion de vos artefacts, à la fois ceux de votre code et ceux de vos processus.

Je pense que le but de cette approche n'est pas de contraindre les user stories, mais d'empêcher de mauvaises exigences.

D'après mon expérience, les utilisateurs sont généralement incapables d'écrire des exigences. Les développeurs sont généralement incapables d'écrire des exigences. Heck, admettons-le tout de suite: les exigences sont difficiles à écrire!

Je pense qu'il serait valable pour un utilisateur d'écrire quelque chose dans le jargon des exigences dans le cadre d'une histoire d'utilisation. Cependant, cela ne devrait pas automatiquement en faire une exigence. Le fait d'avoir deux histoires d'utilisation conflictuelles est un problème mineur; avoir deux exigences contradictoires est un problème majeur de rupture de contrat. Cela n'a aucun sens de faire la promotion de l'un avant l'autre.

Je pense que le point de vue draconien vient d'une reconnaissance de la nature humaine. Si les gens commencent à penser aux user stories comme un endroit où mettre des exigences, ils commenceront à le faire. Le véritable avantage de l'utilisation d'histoires par rapport à d'autres moyens de recueillir des exigences telles que des informations est qu'elles sont formulées dans les termes et la notation naturels de l'utilisateur. Cela rend plus probable que les développeurs pensent du point de vue du client. Dans un monde parfait, le jargon des exigences froides pourrait également y aller. En réalité, de tels mots ont tendance à inciter les développeurs à s'accrocher aux exigences faciles à comprendre et à manquer les formulations et les nuances subtiles que le développement agile veut découvrir à l'aide d'histoires d'utilisation.

Prenez vos propres décisions

La réponse à "Alors, comment les développeurs peuvent-ils réellement développer une histoire s'il n'y a pas d'exigences plus faibles?" est très simple - les exigences détaillées qui sont orthogonales aux besoins de l'utilisateur final (par exemple les contraintes de base de données, la validation des champs, etc.) n'ont pas vraiment d'importance pour l'utilisateur. Si les besoins des utilisateurs peuvent être satisfaits par une validation des champs très différente, des structures de base de données très différentes ou peut-être même pas de base de données traditionnelle du tout, il serait contre-productif de demander aux utilisateurs de créer ces informations avec une implémentation particulière à l'esprit, ce qui peut être très différent de la façon dont le système est mis en œuvre à la fin.

Vous êtes des développeurs professionnels, alors prenez des décisions professionnelles au mieux de vos capacités concernant les détails de mise en œuvre. Un utilisateur qui veut une table peut dire à un menuisier quel type de bois il souhaite, mais le menuisier doit décider de l'épaisseur des pieds de la table pour gérer des charges raisonnables. Si vous manquez d'informations pour prendre une décision significative, cela doit être discuté avec l'utilisateur, mais environ 90% du contenu d'un document d'exigences détaillé n'a en fait besoin d'aucune information en dehors du vague bon sens des histoires d'utilisateurs et des meilleures pratiques de l'industrie. .

Tous ces détails ne sont pas arbitraires - il y a de mauvais choix et de meilleurs choix, et ils doivent être documentés car ils affectent d'autres parties de la mise en œuvre, mais à la fin ce sont toujours des détails de mise en œuvre qui peuvent et doivent être décidés par l'équipe de mise en œuvre en fonction aux besoins des utilisateurs et aux meilleures pratiques.

Une analogie standard avec la voiture - si un client veut que la voiture soit peinte en rouge, alors une clarification appropriée pour l'histoire de l'utilisateur serait de demander quelle nuance de rouge serait la meilleure, mais pas la composition chimique de la peinture; néanmoins, on s'attendrait à ce qu'ils ne choisissent pas de peindre la voiture avec des aquarelles qui se laveraient sous la pluie, car il est préférable de ne pas le faire.

TL; DR

Les user stories servent à documenter la valeur à ajouter au produit et pourquoi. Les détails de la mise en œuvre (par exemple, comment la valeur doit être ajoutée, testée, mesurée ou validée) sont contraints par l'histoire, mais n'y figurent pas. Ils sont délibérément laissés comme des artefacts séparés pour maintenir la flexibilité et l'agilité dans le cadre.

Les spécifications et les détails d'implémentation sont le plus souvent capturés dans d'autres artefacts tels que les scripts et scénarios de développement piloté par l'acceptation (ATDD), le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD). Ces artefacts particuliers ne sont pas mandatés par le framework Scrum, mais ils vous donneront certainement un bon point de départ si vous n'avez pas déjà d'autres contrôles de processus efficaces en place.

Les témoignages d'utilisateurs ne sont pas des spécifications

L'affiche originale (OP) posait la question suivante :

[Un] client veut un traitement différent pour différentes cartes de crédit, il y a des exigences strictes qui doivent être mises en œuvre et connues pour que les cas de test puissent être écrits ... OERE DOIS-JE LE METTRE SI PAS DANS L'HISTOIRE?

Une user story est une fonctionnalité qui apporte de la valeur , fournit un contexte pour guider les conversations sur la mise en œuvre et un point de vue lié à un consommateur de valeur qui bénéficiera de la valeur fournie par la fonctionnalité.

L' intérêt d'une histoire d'utilisateur est que les détails de mise en œuvre ne sont pas normatifs. L'équipe est libre d'implémenter la fonctionnalité de toute manière qui fournit la valeur identifiée au consommateur de valeur dans le contexte approprié.

Un exemple travaillé

Un exemple d'utilisateur

Ceci est plus facile à expliquer si vous commencez avec un ensemble d'histoires utilisateur moins ambigu. Étant donné que l'OP n'a pas fourni une histoire utilisateur exploitable qui suit la mnémonique INVEST , je vais en inventer une à titre d'exemple. Considérez l'histoire suivante:

En tant qu'utilisateur qui préfère payer par carte Discover,
j'aimerais avoir la possibilité d'effectuer mes achats avec la carte Discover
afin de ne pas être limité à Visa, Mastercard ou American Express.

Cela fournit une fonctionnalité concrète, fournit un contexte qui peut guider les décisions de mise en œuvre que l'équipe doit prendre et identifie le consommateur de valeur en tant que client propriétaire d'une carte Discover. Ce n'est pas un ensemble de spécifications, mais c'est ce dont vous avez besoin pour avoir les bonnes conversations avec le client et avec l'équipe sur la meilleure façon de mettre en œuvre l'histoire pendant une itération de développement.

Analyse et mise en œuvre

La mise en œuvre réelle appartient à l'équipe. L'équipe devra faire une analyse pour déterminer:

• La façon la plus simple d'implémenter une nouvelle fonctionnalité.
• Laquelle des diverses options de mise en œuvre sera la plus facile à soutenir à l'avenir, sans accumuler de dette technique.
• Comment appliquer les principes ouvert-fermé et YAGNI pour garantir que votre nouvelle fonctionnalité est robuste sans être trop conçue.

L'un des principes fondamentaux du Manifeste Agile est la collaboration avec les clients. Une équipe interfonctionnelle et auto-organisée devrait être en mesure de collaborer avec le client pour définir les détails de la mise en œuvre dans le cadre des directives fournies par la user story.

Si vos user stories ne sont pas bien écrites, ou si l'équipe n'a pas les compétences ou la maturité de processus pour faire l'analyse juste suffisante requise par leur framework agile, alors ce sera évidemment beaucoup plus difficile que nécessaire. Des livres entiers ont été écrits sur la façon de créer de bonnes histoires d'utilisateurs au niveau de granularité adéquat; il n'y a malheureusement pas de solution miracle, mais c'est une compétence apprenable pour les équipes agiles.

Conception pilotée par les tests et conduite par les comportements

La meilleure façon de s'assurer que l'analyse est solide et que la mise en œuvre est à la fois saine et supportable est l'utilisation de pratiques TDD et BDD. Par exemple, compte tenu de l'histoire ci-dessus, l'équipe doit capturer la mise en œuvre prévue à l'aide d'artefacts tels que:

• Fonctionnalités de concombre avec des scénarios testables.

  Ceci est très utile pour piloter le développement de tests d'acceptation et pour documenter les attentes des utilisateurs quant au comportement des applications. Par exemple, la user story doit avoir une ou plusieurs fonctionnalités Cucumber associées qui décrivent comment l'utilisateur peut extraire avec une carte Discover et à quoi ressemble ce processus pour l'utilisateur.

• Tests RSpec qui valident le comportement (et non les détails d'implémentation internes) des nouvelles fonctionnalités de code.

  Ceci est très utile pour documenter et valider le comportement prévu de la fonctionnalité dans l'application. Par exemple, la user story entraînera la création de tests unitaires et d'intégration qui garantissent que l'utilisation d'une carte Discover invoque le comportement spécifique à la carte dont l'application a besoin pour autoriser une vente via la passerelle de paiement.

Les outils spécifiques n'ont pas d'importance. Si vous n'aimez pas Cucumber ou RSpec, utilisez les outils ou méthodologies qui conviennent le mieux à votre équipe. Cependant, le fait est que les détails d'implémentation sont basés sur la user story , mais ne sont pas prescrits par elle . Au lieu de cela, l'implémentation (ou les spécifications, si vous préférez) sont des détails à élaborer pendant le développement de la fonctionnalité de manière collaborative.

Beaucoup de bonnes réponses ici. J'espère pouvoir ajouter de la valeur à un autre ...

Je pense que l'un des problèmes que votre équipe pourrait rencontrer est la migration à partir d'une méthodologie non agile.

Il s'agit généralement d'une méthodologie sous forme de cascade et, dans la pratique, cela implique généralement d'essayer de documenter toutes les exigences techniques avant d'écrire une ligne de code.

Mais cela ne fonctionne pas toujours. Souvent, cela ne fonctionne pas. La raison? Parce que les exigences correspondent rarement à la réalité. Les choses changent. D'où l'évolution vers l'Agile.

Avec Agile, la User Story est tout ce qui compte pour l'utilisateur. Ils veulent passer du point A au point B. Comment y arriver en termes de mise en œuvre est entre vos mains. Si vous attendez que quelqu'un vous dise les exigences techniques, ce n'est pas vraiment Agile. Si vous avez des questions, posez-les. Si vous avez besoin de documentation, documentez, mais que vous ne voulez pas que le client prenne toutes ces décisions pour vous. Ils peuvent avoir des opinions, mais dans un environnement agile, ces opinions devraient être (comme le suggère votre gourou) discutées dans une conversation.

Il peut sembler que c'est un fardeau pour votre équipe, mais considérez-le comme un luxe. Votre équipe a désormais beaucoup à dire sur la solution - ce qui n'était pas nécessairement le cas dans le modèle en cascade.