Comment gérer les histoires qui partagent des fonctionnalités

J'ai deux histoires (je sais qu'il leur manque la partie avantages)

1. En tant qu'utilisateur de la gestion du crédit, je peux voir les différences de paie actuelles et précédentes pour les bureaux.
2. En tant qu'utilisateur de la gestion du crédit, je peux recevoir un e-mail contenant un PDF des différences de paie actuelles et précédentes pour les bureaux.

Les deux sont liés en ce qu'ils auraient les mêmes critères de requête / filtre. La seule différence est que dans l'histoire "Afficher", les résultats sont affichés pour l'utilisateur et dans l'histoire "E-mail", les résultats sont écrits dans un fichier PDF envoyé à l'utilisateur.

Je me bats avec la séparation des aspects communs de ces deux histoires ou si je devais même le faire.

Par exemple, ils auront tous deux la même requête, ce qu'ils font avec les résultats est différent.

Dois-je séparer la requête en une autre histoire purement technique?

La création du PDF et l'envoi de l'email doivent se faire hors ligne, cela devrait-il devenir une histoire technique?

Je pouvais voir décomposer ces deux histoires en 2 histoires fonctionnelles et 2 histoires techniques.

1. En tant que système, je peux calculer les différences dans la masse salariale actuelle et précédente pour les bureaux.

2. En tant qu'utilisateur de la gestion du crédit, je peux voir les différences dans la paie actuelle et précédente pour les bureaux.

3. En tant que système, je peux créer un document PDF des différences dans la paie actuelle et précédente pour les bureaux.

4. En tant qu'utilisateur de la gestion du crédit, je peux demander à recevoir un e-mail contenant un fichier PDF des différences dans la paie actuelle et précédente pour les bureaux.

Le problème auquel je reviens toujours est que les 4 histoires ne sont pas indépendantes et ne "coupent pas le gâteau".

Je ne sais donc pas trop comment gérer ces deux-là.

Les user stories ne sont pas des spécifications système ou des exigences fonctionnelles. Ils sont plutôt le début d'une conversation qui peut conduire à de telles spécifications ou exigences.

Par conséquent, je m'attendrais à ce qu'il y ait chevauchement dans la mise en œuvre du système. Les User Stories ne sont pas destinées à décrire un tel chevauchement fonctionnel ou à l'éliminer. Le but des User Stories est de capturer les attentes fonctionnelles du point de vue d'un utilisateur, et non de décrire les détails de l'implémentation.

Ne pas: essayez de diviser les histoires, faites une histoire puis l'autre.

À faire: assurez-vous que l'équipe de développement est au courant de la deuxième histoire.

Le problème avec essayer de planifier les tâches détaillées et de concevoir un modèle générique capable de gérer les deux de manière élégante est que c'est difficile.

Le but des user stories est de faire avancer les choses. L'élégance est un objectif secondaire et doit être laissé à la refactorisation.

Évidemment, c'est super ennuyeux si vous prenez cela au maximum et ne parlez à personne des dix autres tâches similaires qui doivent être effectuées, mais il est également tout à fait concevable que la deuxième ou la troisième tâche ne soit pas pensée avant que la première ne soit terminée. Si vous voulez tout planifier, allez avec une cascade.

En accord violent avec Robert Harvey, le but d'une user story est de comprendre ce que l'utilisateur doit pouvoir faire. Au fur et à mesure que vous vous préparez, le client comprend et se soucie de l'histoire de l'utilisateur, mais les développeurs se soucient un peu plus. Une fois que vous avez posé suffisamment de questions pour comprendre et estimer le travail, vous pouvez créer des tâches pour les soutenir.

Dans ce cas particulier, vous pouvez créer des tâches qui activent le cœur des deux user stories qui seraient effectuées avec celui que vous abordez en premier.

Les éléments importants à ajouter à la user story sont:

• Critères d'acceptation
• Hypothèses

À proprement parler, les User Stories sont la promesse d'une conversation pour comprendre le résultat souhaité.

Par exemple, en prenant votre deuxième user story

En tant qu'utilisateur de la gestion du crédit, je peux recevoir un e-mail contenant un PDF des différences de paie actuelles et précédentes pour les bureaux.

Pensez à ce qui suit:

• Quel est le "besoin" de l'utilisateur à l'origine de cette exigence? (Le PDF dans un e-mail comme solution vient-il d'eux? Cela pourrait ne pas répondre au besoin et votre équipe pourrait trouver une meilleure solution)
• Quelle est la tranche minimale qui peut répondre à ce "besoin" de l'utilisateur et valider votre solution? De courtes boucles de rétroaction sont précieuses.

Lorsque vous approchez du fractionnement de l'histoire, souvenez-vous de vos critères INVEST lorsque cela est possible.

1. Je ne dépend pas
2. N egotiable
3. V aluable
4. E stimulable
5. Centre commercial S
6. T estable

C'est bien d'avoir des histoires qui ont un ordre naturel. Tenez compte de cela - généralement la première histoire est plus grande car elle apporte les fonctionnalités requises et la deuxième histoire s'appuie dessus.

Je contesterais les histoires «techniques», car en général, il s'agit le plus souvent de tâches destinées à soutenir la mise en œuvre des histoires axées sur les résultats utilisateur.

TL; DR

En supposant que les deux user stories soient intégrées dans la même itération, c'est le travail de l'équipe de décomposer les stories en un plan d'implémentation et ses tâches associées. Les récits d'utilisateurs fournissent le contexte et la portée; ce ne sont pas des implémentations, des spécifications ou des éléments de liste de pointage.

Les histoires doivent être décomposées en tâches d'itération

Que vous suiviez Scrum ou une autre méthodologie agile, c'est une erreur courante d'ignorer la phase de planification d'une itération. Dans Scrum, lorsqu'un élément de backlog de produit (il ne doit pas nécessairement s'agir d'une user story) est tiré dans le Sprint actuel, l'équipe est ensuite censée utiliser une partie de Sprint Planning pour prendre en compte les points communs entre les éléments de travail, identifier les dépendances et puis développez un Sprint Backlog pour capturer le travail au niveau de la tâche.

Comme vous l'avez souligné dans votre article, il n'est pas rare (et en fait souhaitable) qu'une itération agile contienne des user stories étroitement liées. Dans Scrum, cela se traduit par l'utilisation du Sprint Goal. En dehors du cadre Scrum, il est souvent toujours logique de tirer des histoires liées en raison de leurs objectifs partagés ou de leurs dépendances partagées. En extrayant puis en travaillant sur les dépendances partagées au sein d'une seule itération, les équipes peuvent souvent éviter de refactoriser ou d'itérer le code pour des fonctionnalités similaires mais pas identiques à l'avenir.

Tâches Mettre en œuvre des histoires

Voici une autre façon de penser à la planification des dépendances pour les user stories. En général:

1. Une épopée / thème est utilisé pour la planification à long terme ou le regroupement sur un carnet de commandes.
2. Une user story est utilisée pour communiquer les objectifs, le contexte et la portée.
3. La planification juste à temps est utilisée pour développer une implémentation qui s'intègre dans une seule itération.
4. Les tâches mettent en œuvre le plan juste à temps qui répond à la définition de Terminé pour une ou plusieurs user stories.

Traiter les user stories comme un plan de mise en œuvre ou une liste de tâches est considéré par la plupart des praticiens comme un anti-modèle agile. Peu importe comment vous l'appelez, ne sautez pas la phase de planification juste à temps de votre infrastructure agile et assurez-vous de suivre les dépendances et les détails de mise en œuvre partagés quelque part dans le processus de votre équipe.