Diviser la première histoire utilisateur d'un projet en tâches

Question

Je commence un nouveau projet à partir de zéro et ont écrit Utilisateur Magasins pour décrire la manière dont un utilisateur d'interagir avec le système. Mais, je vais avoir du mal à comprendre comment casser le premier article de l'utilisateur à des tâches sans le premier devient une épopée.

Par exemple, si je ont été la construction d'une voiture et le premier article de l'utilisateur a dit quelque chose comme "en tant Que pilote, je voudrais être en mesure de changer la direction du mouvement, de sorte que je ne frappe pas les choses.", cela impliquerait une interface utilisateur (le volant), mais aussi le mouvement (roues) et tout le nécessaire pour lier ensemble (essieu, image, lien, etc...). En fin de compte, qui est le premier utilisateur de l'histoire semble toujours représentent environ 40% du projet, car il implique beaucoup à propos de l'architecture sous-jacente.

Comment avez-vous de briser articles de l'utilisateur vers le bas pour un nouveau projet, tels que le premier n'est pas de devenir une épopée qui représente l'ensemble de votre architecture sous-jacente?

Answer 1

Vous pourriez vouloir penser à votre histoire comme une tranche verticale du système. Une histoire peut (et souvent) toucher les composants dans toutes les couches architecturales du système. Il peut être intéressant de penser à vos tâches en tant que le travail à faire sur chacun des composants de votre histoire touche.

Par exemple, disons que vous avez une histoire comme Dans le but d'être facilement en mesure de suivre de mes amis tweets, en tant qu'utilisateur enregistré, je veux suivre automatiquement tous mes contacts gmail qui ont des comptes twitter.

Pour ce faire, vous devrez passer à travers la couche d'INTERFACE utilisateur, de la couche de service, persistent certaines données dans la couche de données, et de faire un appel API pour twitter, et gmail.

Vos tâches seront:

• Ajout d'une option pour le menu
• Ajouter un nouveau gmail écran d'authentification
• Ajouter un écran d'authentification twitter
• Ajouter un contact à l'écran de sélection de
• Ajouter un contrôleur d'appels en votre couche de service
• Écrire un nouveau service qui fait le travail
• Enregistrer des contacts dans la base de données
• Modifier votre gmail API d'appeler le service client pour obtenir des contacts
• Ajouter une API twitter appeler le service à suivre les contacts sélectionnés

Y: C'est 9 tâches possibles à droite. Maintenant, en règle générale, vous voulez que vos tâches à prendre environ une 1/2 journée à 2 jours, avec un parti pris en faveur d'un jour (les meilleures pratiques, pour le dimensionnement). Selon le niveau de difficulté, vous risquez de briser ces tâches supplémentaires, ou de combiner certains si ils sont deux facile (peut-être les deux API de services d'appels sont si simple, vous avez juste a modifier API externe des services).

En tout cas, c'est un raw esquisse de la façon de briser les histoires vers le bas.

EDIT:

En réponse à la question que j'ai eu sur le sujet de la rupture des histoires dans des tâches, j'ai écrit un billet de blog à ce sujet, et je souhaite le partager ici. J'ai élaboré sur les étapes nécessaires pour briser l'histoire. Le lien est ici.

Answer 2

Lorsque nous avons lancé des projets en vertu d'une Mêlée à un style de gestion, le premier ensemble de tâches a toujours été large, ou que vous la décrivez: épique. C'est inévitable, le cadre de tout projet est généralement le plus important, le plus important, et de temps partie, mais il prend en charge le reste du projet. Afin de réduire l'ampleur écrasante-ness de la façon dont les choses à faire, voir si vous pouvez lister les pièces les PLUS importantes. Ensuite, travailler sur la définition de ces tâches en tant que points de départ. Donc vous avez un peu de tâches comme points de départ pour un grand début. L'espoir qui fait sens!

Answer 3

L'histoire que vous mettre 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 récent projet, nous avons eu à développer une application qui a impliqué l'indexation de divers sites web, et les faire correspondre à l'encontre des filtres créés par les utilisateurs, et enfin d'informer les utilisateurs de matchs (chose que google alerte sur les stéroïdes).

Si vous regardez à partir d'un certain point de vue, il y a seulement une histoire - "en tant Qu'utilisateur, je veux recevoir une alerte à partir de la correspondance des pages". Mais regardez à partir d'un autre point de vue de "quels sont les risques que nous voulons atténuer". Le premier risque est que les utilisateurs ne serait pas pertinente ou mieux frappe par rapport à google alertes. Le deuxième risque est dans l'apprentissage de la technologie pour la construire.

Donc, notre premier article de l'utilisateur a été tout simplement "en tant Qu'utilisateur, je veux hits pertinents", puis nous avons construit juste le coup algorithme de mise en correspondance sur une codé en dur ensemble de pages et codé en dur filtres pour certains des premiers utilisateurs et a obtenu une rétroaction de leur part.

Il y a peut être effectivement un peu en arrière et en avant ici avec de multiples petites histoires de la capture de l'apprentissage comme "en tant Qu'utilisateur, je veux plus la priorité doit être donnée à des matchs dans l'URL" etc.. ces histoires vient de la rétroaction que nous itérer sur ce que les premiers utilisateurs considèrent que "hits pertinents".

Ensuite, nous avons élargi à "en tant Qu'utilisateur, je veux des hits de sites web spécifiques" et nous avons construit l'indexation de l'architecture à l'analyse de l'utilisateur spécifié sites et ne frappe pas de correspondance sur que.

La troisième histoire est "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 été en mesure de construire l'architecture, morceau par morceau. À travers la plupart de la première partie, qu'au début les utilisateurs peuvent utiliser le système, et beaucoup de morceaux de données ont été codées en dur etc.

Après un point, les premiers utilisateurs pourraient utiliser le système complètement. Puis nous avons ajouté des histoires pour permettre aux nouveaux utilisateurs de s'inscrire et ouvert au public.

Pour couper une longue histoire courte, l'histoire que vous mettre en œuvre la première pourrait mettre en œuvre, seule une petite partie de la dernière histoire, coder en dur d'échafaudage et de tout le reste. Et puis vous pouvez itérer sur elle au fil du temps jusqu'à ce que vous obtenez l'histoire de ce que vous pourriez effectivement communiqué au public.

Answer 4

Un article de l'utilisateur de décrire l' what , tandis qu'une tâche est plus sur l' how.

• Il n'y a pas de formule parfaite, il suffit d'ajouter n'importe quelle tâche qui décrivent how l'article de l'utilisateur vont être mis en œuvre, documenté ou testé.
• Gardez à l'esprit qu'une tâche doit être estimée en heures, alors essayez d'échelle et de détail les tâches en conséquence.

Si vous vous sentez que vous avez trop de tâches pour une histoire (même si vous avez de 1 à 8 heures de temps des tâches), puis peut-être vous devriez envisager de réécrire votre article de l'utilisateur en premier lieu parce qu'il est probablement trop complexe.

Bonne chance

Answer 5

Je suis arrivé à un carrefour avec ce problème dans le passé. Les User stories sont censés être isolé de sorte que vous pouvez les faire sans d'autres histoires, dans quel ordre, etc. Mais j'ai trouvé ce que cela se produise juste rendu le tout plus compliqué. Pour moi, cela tombait sous le "les Individus et les interactions des processus et des outils de" partie de l'agile manifesto - ou du moins mon interprétation de la chose.

Le but ultime est de navire. Et pour la livraison vous avez à construire, et construire vous devez vous arrêter futzing avec scrum et juste obtenir des trucs fait et assurez-vous de le suivre.

Donc, ce que nous avons fait a été de briser une règle cardinale des histoires et nous avons fait quelques tech des histoires comme "créer un schéma préliminaire". Nous avons également déclaré que certaines histoires étaient à la charge sur les autres, et a noté que sur le dos de l'histoire de la carte.

Au final, j'ai l'impression que ce type d'histoire est peu et loin entre la, et la difficulté de l'alternative justifié l'exception.