Comment gérer les histoires qui partagent des fonctionnalités
J'ai deux histoires (je sais qu'il leur manque la partie avantages)
- En tant qu'utilisateur de gestion de crédit, je peux voir les différences de paie actuelles et précédentes pour les bureaux.
- En tant qu'utilisateur de gestion de 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 "View", les résultats sont affichés pour l'utilisateur et dans l'histoire "Email", les résultats sont écrits dans un PDF qui est envoyé par e-mail à 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'e-mail 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.
En tant que système, je peux calculer les différences dans la masse salariale actuelle et précédente pour les bureaux.
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.
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.
En tant qu'utilisateur de gestion de crédit, je peux demander à recevoir un e-mail contenant un 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 la mise en œuvre.
À ne pas faire: 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 qui peut 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
Strictement parlant, 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 gestion de 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 en tant que solution est-il venu 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 cet 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.
- I ndépendant
- N égotiable
- V précieux
- E stimulable
- S centre commercial
- T estable
Il est normal 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 pour aider à 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 dans un plan de mise en œuvre et ses tâches associées. Les histoires 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, strictement parlant) 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, puis développer 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 judicieux de tirer des histoires liées à cause 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 non identiques à l'avenir.
Tâches Implémenter Histoires
Voici une autre façon de penser à la planification des dépendances pour les user stories. En général:
- Une épopée/thème est utilisé pour la planification à long terme ou le regroupement sur un carnet de commandes.
- Une user story est utilisée pour communiquer les objectifs, le contexte et la portée.
- La planification juste à temps est utilisée pour développer une implémentation qui s'intègre dans une seule itération.
- 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. Quoi que vous choisissiez de l'appeler, 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 d'implémentation partagés quelque part au sein du processus de votre équipe.