Diviser la première histoire utilisateur d'un projet en tâches
Je commence un nouveau projet à partir de zéro et j'ai écrit des magasins d'utilisateurs pour décrire comment un utilisateur donné interagira avec le système. Mais j'ai du mal à comprendre comment décomposer la première user story en tâches sans que la première ne devienne une épopée.
Par exemple, si je construisais une voiture et que la première histoire d'utilisateur disait quelque chose comme "En tant que conducteur, j'aimerais pouvoir changer la direction du mouvement pour ne pas heurter les choses", cela impliquerait un utilisateur interface (volant), mais aussi mouvement (roues) et tout le nécessaire pour relier ceux-ci (essieu, châssis, tringlerie, etc ...). Au final, cette première user story semble toujours représenter environ 40% du projet car elle implique tant de choses sur l'architecture sous-jacente.
Comment décomposer les user stories pour un nouveau projet afin que le premier ne devienne pas une épopée représentant l'ensemble de votre architecture sous-jacente?
Vous voudrez peut-être considérer votre histoire comme une tranche verticale du système. Une histoire peut (et touchera souvent) des composants dans toutes les couches architecturales du système. Vous voudrez donc peut-être considérer vos tâches comme le travail à effectuer sur chacun des composants que votre histoire touche .
Par exemple, supposons que vous ayez une histoire comme Afin de pouvoir facilement suivre les tweets de mes amis, en tant qu'utilisateur enregistré, je veux suivre automatiquement tous mes contacts gmail qui ont des comptes Twitter.
Pour ce faire, vous devrez passer par la couche UI, la couche service, conserver certaines données dans la couche de données et effectuer un appel API à Twitter et gmail.
Vos tâches pourraient être:
- Ajouter une option au menu
- Ajouter un nouvel écran d'authentification gmail
- Ajouter un écran d'authentification Twitter
- Ajouter un écran de sélection de contacts
- Ajoutez un contrôleur qui appelle dans votre couche de service
- Écrivez un nouveau service qui fait le travail
- Enregistrer les contacts dans la base de données
- Modifiez votre service d'appel API Gmail existant pour obtenir des contacts
- Ajouter un service d'appel API Twitter pour suivre les contacts sélectionnés
Là: c'est 9 tâches possibles ici. Maintenant, en règle générale, vous voulez que vos tâches prennent environ 1/2 journée à 2 jours, avec un biais vers une journée (meilleure pratique, pour le dimensionnement). Selon la difficulté, vous pouvez décomposer ces tâches plus en détail, ou les combiner si elles sont deux faciles (peut-être que les deux services d'appel API sont si simples, vous auriez juste un modifiez les services API externes =).
En tout cas, ceci est un croquis brut de la façon de décomposer les histoires.
EDIT:
En réponse à plus de questions que j'ai eu sur le sujet de la décomposition des histoires en tâches, j'ai écrit un article à ce sujet et j'aimerais le partager ici. J'ai expliqué les étapes nécessaires pour briser l'histoire. Le lien est ici .
Lorsque nous avons commencé des projets dans un style de gestion Scrum, le premier ensemble de tâches était toujours large, ou comme vous le décrivez: épique. C'est inévitable, le cadre de tout projet est généralement la partie la plus importante, la plus importante et la plus longue, mais il prend en charge le reste du projet. Afin de réduire l'échelle sur l'écrasante quantité de travail à faire, voyez si vous pouvez lister les pièces les PLUS essentielles. Ensuite, travaillez à définir ces tâches comme points de départ. Par conséquent, vous avez quelques tâches comme points de départ pour un large départ. J'espère que cela a du sens!
L'histoire que vous mettez en œuvre au début peut être affinée au fil du temps. Vous n'avez pas besoin de penser que chaque histoire doit être la version finale que l'utilisateur va utiliser.
Par exemple, dans un projet récent, nous avons dû développer une application qui impliquait l'indexation de divers sites Web, leur mise en correspondance avec des filtres créés par les utilisateurs, et enfin l'alerte de l'utilisateur de correspondances (ce qui est comme une alerte Google sur les stéroïdes).
Si vous le regardez d'un point de vue, il n'y a qu'une seule histoire - "En tant qu'utilisateur, je veux recevoir des alertes des pages correspondantes". Mais regardez-le sous un autre angle de "quels sont les risques que nous voulons atténuer". Le premier risque était que les utilisateurs n'obtiennent pas de résultats pertinents ou meilleurs par rapport aux alertes Google. Le deuxième risque était d'apprendre la technologie pour construire cela.
Donc, notre première histoire d'utilisateur était simplement "En tant qu'utilisateur, je veux des résultats pertinents", puis nous avons construit l'algorithme de correspondance des résultats sur un ensemble de pages et de filtres codés en dur pour certains des premiers utilisateurs et obtenu leurs commentaires.
Il peut y avoir en fait un peu de va-et-vient ici avec plusieurs histoires plus petites pour capturer l'apprentissage comme "En tant qu'utilisateur, je veux donner plus de priorité aux correspondances dans l'URL" etc. Ces histoires proviennent des commentaires pendant que nous itérons sur ce les premiers utilisateurs considèrent les "hits pertinents".
Ensuite, nous l'avons élargi à "En tant qu'utilisateur, je veux des hits de sites Web spécifiques" et nous avons construit l'architecture d'indexation pour explorer les sites spécifiés par les utilisateurs et faire des correspondances sur ce point.
La troisième histoire était "En tant qu'utilisateur, je veux définir mes propres filtres", et nous avons construit cette partie du système.
De cette façon, nous avons pu construire l'architecture pièce par pièce. Pendant la majeure partie de la partie initiale, seuls les premiers utilisateurs pouvaient utiliser le système, et de nombreuses données étaient codées en dur, etc.
Après un moment, les premiers utilisateurs pouvaient utiliser le système complètement. Ensuite, nous avons ajouté des histoires pour permettre aux nouveaux utilisateurs de s'inscrire et les avons ouvertes au public.
Pour résumer une longue histoire, l'histoire que vous implémentez en premier ne peut implémenter qu'une petite partie de l'histoire finale, coder en dur et échafauder tout le reste. Et puis vous pouvez le répéter au fil du temps jusqu'à ce que vous obteniez l'histoire que vous pourriez réellement publier au public.
Une user story décrit le what tandis qu'une tâche concerne plus le how.
- Il n'y a pas de formule parfaite, il suffit d'ajouter une tâche décrivant
howla user story va être implémentée, documentée ou testée. - Gardez à l'esprit qu'une tâche doit être estimée en heures, essayez donc de la mettre à l'échelle et de la détailler en conséquence.
Si vous pensez que vous avez trop de tâches pour une histoire (même si vous avez des tâches de 1 à 8 heures), alors vous devriez peut-être envisager de réécrire votre histoire d'utilisateur en premier lieu parce qu'elle est probablement trop complexe.
Bonne chance
Je suis parvenu à un carrefour avec cette question dans le passé. Les histoires d'utilisateurs sont censées être isolées, vous pouvez donc les faire sans aucune autre histoire, dans n'importe quel ordre, etc. Mais j'ai trouvé que cela se produisait rendait tout plus compliqué. Pour moi, cela relevait de la partie "Individus et interactions sur les processus et les outils" du manifeste agile - ou du moins de mon interprétation.
Le but ultime est le navire. Et pour expédier, vous devez construire, et pour construire, vous devez arrêter de jouer avec Scrum et simplement faire avancer les choses et vous assurer de les suivre.
Donc, ce que nous avons fait, c'est enfreindre une règle cardinale des histoires et nous avons fait des histoires technologiques comme "créer un schéma préliminaire". Nous avons également déclaré que certaines histoires dépendaient d'autres, et nous l'avons noté au dos de la carte d'histoire.
Au final, j'ai senti que ce type d'histoire était peu répandu et la difficulté de l'alternative justifiait l'exception.