Comment définir des règles métier complexes à l'aide de User Stories?

Une définition rapide et sale de User Story :

"As a <role>, I want <goal/desire> so that <benefit>"

Dans cette définition communément acceptée, il y a peu d'espace pour définir des règles métier, des contraintes ou des entrées utilisateur.

Exemple trivial juste pour illustrer:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

Dans cet exemple stupide, où définirait-on les champs nécessaires lors de l'enregistrement d'un livre? Doit-il être écrit n'importe où? Ou les règles commerciales requises devraient-elles être adoptées comme bouche à oreille par le propriétaire du produit?

Les champs font partie de la conversation qui devrait avoir lieu. Ils peuvent être notés si cela est utile, mais c'est un jugement. La mise à jour de la documentation peut être difficile alors que le logiciel de travail peut être considéré dans une certaine mesure comme de la documentation.

User Story - Une promesse d'avoir une conversation serait une entrée de blog à ce sujet.

Votre exemple trivial a quelques points que je ne sais pas à quel point vous le remarqueriez. Que signifie "enregistrer de nouveaux livres?" Qu'est-ce que "Trouver leur disponibilité en ligne?" C'est là que commence la conversation et une fois l'histoire terminée, il peut y avoir de nouvelles histoires car ces enregistrements doivent peut-être être conservés dans le dossier ou des rapports doivent être générés périodiquement.

Les réponses précédentes fournissent des points valides, en ce qui concerne spécialement une histoire d'utilisateur étant un rappel pour avoir une conversation . Autres choses à considérer:

1. Si l'histoire est trop complexe, c'est probablement une épopée . Vous pouvez diviser les épopées en histoires plus petites maintenant ou une fois qu'elles ont été priorisées dans le backlog de produit

2. Les détails qui impliquent des cas de test sont séparés de l'histoire elle-même. [ Mike Cohn ]

   Vous pouvez ajouter au dos de la carte d'histoire, prendre de petites notes si elles sont vraiment importantes ou les mettre dans le document des tests d'acceptation .

Pour évaluer si vos histoires d'utilisateurs sont bonnes, vous pouvez suivre la suggestion de Bill Wake :

• Je ne dépend pas (d'autres histoires)
• N égoïste
• V aluable (pour l'utilisateur ou le client)
• E stimulable (à une bonne approximation)
• Centre commercial S (assez pour être estimable)
• T estable

Vous voudrez peut-être lire le chapitre 2 «Écriture d'histoires» du livre User Stories Applied, de Mike Cohn.

Généralement, sur une large user story englobante qui a de nombreuses facettes, j'essaie d'obtenir l'exemple le plus général de l'histoire, puis pour des spécificités, je crée des user stories enfants qui en héritent. De nombreux outils de gestion de projet Agile comme RallyDev vous permettent de le faire facilement et je trouve que cela a du sens.

L'enregistrement de nouveaux livres est large, il y a donc peut-être 10 autres histoires d'utilisateurs sur la façon dont les <role>livres devraient être enregistrés.

Des détails extrêmes de ces choses ou des détails marginaux bizarres que je définis habituellement dans une ou plusieurs tâches sous cette histoire d'utilisateur. Les tâches aident à définir le travail de développement et de conception qui devrait être fait (à un niveau général) pour répondre à cette histoire d'utilisateur (par exemple, écrire validtor pour s'assurer que la saisie dans le champ de description est inférieure à 50 caractères ...) EDIT: Je voulais juste ajouter qu'il est probablement préférable de garder les détails extrêmes hors des histoires d'utilisateurs, car ce n'est probablement pas quelque chose qui intéressera vraiment un utilisateur. Les utilisateurs veulent expliquer les logiciels en termes généraux et ils dépendent des développeurs de logiciels pour comprendre et leur cacher les détails.

C'est juste comment j'aborde le problème, mais je suis sûr qu'il existe un certain nombre de façons différentes.

La réponse est simple, intégrez les règles métier dans les critères d'acceptation.

Exemple trivial juste pour illustrer:

En tant que bibliothécaire, je souhaite enregistrer de nouveaux livres, afin que les étudiants puissent trouver leur disponibilité en ligne

Je serai satisfait quand: * Je peux enregistrer les champs suivants: - RNIS - Auteur - Dewey Decimal blah blah * Je peux voir la confirmation que le livre a été enregistré par le système * Je peux voir le livre dans le système

Comment définir des règles métier complexes à l'aide de User Stories?

Ce n'est pas à cela que servent les user stories. Ce ne sont pas des exigences logicielles qui capturent tous les détails ou les règles métier nécessaires à l'écriture de l'implémentation. Ils ne sont qu'une description de ce que l'application doit faire du point de vue de l'utilisateur.

N'oubliez pas ce qui est important: créer le bon logiciel. Vous utilisez tout ce qui est nécessaire pour ce faire et les user stories sont juste pour vous assurer que vous avez rassemblé les fonctionnalités nécessaires que l'application devrait avoir afin que vous puissiez ensuite en parler, les hiérarchiser, les estimer, etc. La partie manquante de l'utilisateur classique histoire (comme ... je veux ... pour ça) concerne la communication entre les personnes impliquées dans la construction du logiciel.

Avoir les détails comme critères d'acceptation, sous-histoires, tâches techniques attachées à la user story, dans un document de spécification ou autre, va au-delà de ce que la user story vous aide. L'utilisateur Stoy n'est que le «sujet» de la conversation lorsqu'il décide comment construire le logiciel.

Dans l'exemple donné, il existe de nombreux détails sur l'enregistrement des livres que les développeurs ne connaissent pas bien, tels que Dewey ou d'autres systèmes de classification, ISBN, numéros d'acquisition, copies / titres / auteurs en double, autres éditions, etc. Pour un nouveau système, ces détails doivent être fournis par le client (et un bibliothécaire, de toutes les personnes, se souciera certainement d'eux).

Pour citer Steve O'Connell, «Il est terrifiant de voir à quel point la politique commerciale est créée par des développeurs qui n'avaient pas les détails nécessaires dans les spécifications, alors venez de les inventer.»