Briser la première User Story 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 histoire d’utilisateur 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 pilote, j’aimerais pouvoir changer la direction du mouvement pour ne pas bash des choses”, cela impliquerait un utilisateur interface (volant), mais aussi mouvement (roues) et tout le nécessaire pour les relier (essieu, châssis, sortingnglerie, etc …). En fin de compte, cette première histoire d’utilisateur semble toujours représenter environ 40% du projet, car cela implique beaucoup de choses sur l’architecture sous-jacente.

Comment diviser les histoires d’utilisateurs pour un nouveau projet de telle sorte que le premier ne devienne pas une épopée représentant toute votre architecture sous-jacente?

Vous pouvez penser à votre histoire comme une tranche verticale du système. Une histoire peut (et va souvent) toucher des composants dans toutes les couches architecturales du système. Vous pourriez donc vouloir penser à vos tâches car le travail doit être fait sur chacun des composants que votre histoire touche .

Par exemple, disons que vous avez une histoire comme celle-ci. Pour pouvoir suivre facilement 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 d’interface utilisateur, la couche de service, conserver certaines données dans la couche de données et passer 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 contact
  • Ajouter un contrôleur qui appelle votre couche de service
  • Ecrire un nouveau service qui fait le travail
  • Enregistrer des contacts dans la firebase database
  • Modifiez votre service d’appel API existant pour obtenir des contacts
  • Ajouter un service d’appel Twitter API pour suivre les contacts sélectionnés

Là: C’est 9 tâches possibles là-bas. Maintenant, en règle générale, vous voulez que vos tâches durent environ une demi-journée à deux jours, avec une préférence pour une journée (meilleures pratiques de dimensionnement). En fonction de la difficulté, vous pouvez décomposer ces tâches ou en combiner quelques-unes si elles sont simples (peut-être que les deux services d’appel d’API sont si simples, il vous suffit de modifier les services d’API externes ).

En tout cas, il s’agit d’une esquisse brute de la façon de décomposer les histoires.

MODIFIER:

En réponse à d’autres questions que j’ai eues sur le sujet des bris d’histoires dans les tâches, j’ai écrit un article sur ce sujet et je voudrais le partager ici. J’ai élaboré les étapes nécessaires pour briser l’histoire. Le lien est ici .

Lorsque nous avons lancé des projets dans un style de gestion Scrum, le premier ensemble de tâches était toujours vaste 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 vaste et la plus longue, mais il supporte le rest du projet. Afin de réduire l’ampleur de la situation, voyez si vous pouvez lister les parties les plus essentielles. Ensuite, travaillez sur la définition de ces tâches comme points de départ. Par conséquent, vous avez quelques tâches en tant que points de départ pour un large début. J’espère que c’est logique!

L’histoire que vous implémentez 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 consistant à indexer divers sites Web et à les comparer à des filtres créés par les utilisateurs, puis à alerter l’utilisateur des correspondances (comme alerte Google sur les stéroïdes).

Si vous le regardez d’un seul sharepoint 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: “quels sont les risques que nous voulons atténuer”. Le premier risque était que les utilisateurs n’obtiendraient pas de résultats pertinents ou supérieurs à ceux des alertes Google. Le deuxième risque était d’apprendre la technologie pour le construire.

Donc, notre première histoire d’utilisateur était simplement “En tant qu’utilisateur, je veux des hits pertinents”, nous avons ensuite construit l’algorithme de correspondance des hits sur un ensemble de pages codées en dur et des filtres codés pour certains utilisateurs débutants.

Il pourrait y avoir un peu de va-et-vient avec de multiples petites histoires pour capturer l’apprentissage comme “En tant qu’utilisateur, je veux que plus de priorité soit donnée aux correspondances dans l’URL”, etc. les premiers utilisateurs considèrent les “hits pertinents”.

Ensuite, nous l’avons élargi à “En tant qu’utilisateur, je veux des hits à partir de sites Web spécifiques” et nous avons construit l’architecture d’indexation pour parsingr les sites spécifiés par les utilisateurs et y faire correspondre les correspondances.

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 manière, 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 nombreux éléments de données étaient codés 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 de l’ouvrir au public.

Pour résumer une histoire courte, l’histoire que vous mettez en œuvre en premier pourrait implémenter seulement une petite partie de l’histoire finale, coder en dur et échafauder tout le rest. Et puis, vous pouvez le parcourir au fil du temps jusqu’à ce que vous obteniez l’histoire que vous pourriez réellement publier.

Une user story décrit le what alors qu’une tâche est plus sur le how .

  • Il n’y a pas de formule parfaite, il suffit d’append une tâche décrivant how la user story va être implémentée, documentée ou testée.
  • N’oubliez pas qu’une tâche doit être estimée en heures. Essayez donc de mettre à l’échelle et de détailler les tâches en conséquence.

Si vous sentez que vous avez trop de tâches pour une histoire (même si vous avez des tâches de 1 à 8 heures), vous devriez peut-être envisager de réécrire votre user story en premier lieu car elle est probablement trop complexe.

Bonne chance

Je suis arrivé à un carrefour avec cette question par le passé. Les user stories sont censées être isolées pour que vous puissiez les faire sans autres histoires, dans n’importe quel ordre, etc. Mais j’ai trouvé que cela ne faisait que compliquer les choses. 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 bateau. Et pour expédier, vous devez construire, et pour construire, vous devez arrêter de fouiner avec Scrum et faire en sorte que vous le suiviez.

Donc, nous avons rompu une règle cardinale des histoires et nous avons fait certaines histoires techniques 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 verso de la carte récit.

En fin de compte, j’ai senti que ce type d’histoire était rare et la difficulté de l’alternative justifiait l’exception.