Agile - Définitions des histoires d'utilisateurs [fermé]

Question

J'écris une petite application pour le travail de mon ami et je pensais profiter de l'occasion pour mettre à niveau une formation en gestion de projet Agile que j'avais donnée au début de l'année.

Moi (et je pense que mon organisation actuelle!) a toujours eu du mal à rassembler les exigences sous forme d'histoires d'utilisateurs, qui prennent la forme suivante:

En tant que [Type d'utilisateur], je veux [fonction] de sorte que [certains avantages]

Je suis toujours tenté de rater le début et la fin et de laisser la fonction en suspens, mais cela devient alors une condition préalable à la méthode habituelle!

Mais je ne veux pas que tout rentre dans l'ordre, pour pouvoir dire «je fais de l'agilité» ... par exemple, si je sais que l'utilisateur doit recevoir une liste d'éléments, alors la raison est évidente, n'est-ce pas?

par exemple

En tant que [gérant de magasin], je veux [voir une liste d'articles en stock] pour que ...?

Est-ce une pratique normale de laisser de côté la clause [so that]?

Answer 1

Nous l’avions manqué aussi. Et en le laissant, nous avons beaucoup manqué. Pour bien comprendre la fonctionnalité et ne pas simplement faire les choses correctement, il est essentiel de connaître POURQUOI la fonctionnalité, et pour cela la clé suivante est l'OMS (le rôle). En termes de DDD, partie prenante. Les parties prenantes peuvent être différentes, tout le monde s'en soucie. Des programmeurs et des administrateurs de base de données à tous les types d’utilisateurs.

Alors, comprenez d’abord qui est l’acteur, puis vous connaissez 50% de POURQUOI il s’intéresse à lui, ensuite l’avantage, puis c’est déjà de toute évidence QUOI mettre en œuvre.

Essayez de ne pas simplement écrire "en tant qu'utilisateur". Spécifier. "en tant que responsable de magasin", ou même "en tant que responsable du quart de travail responsable de la fermeture de la journée", j’ai besoin de ... pour que ....

Peut-être pouvez-vous mettre en œuvre quelque chose de différent qui procurera un bénéfice encore meilleur à la même partie prenante !!!

Answer 2

Essayez d’atteindre la [valeur commerciale] en tant que [utilisateur] il me faut [fonction].

L'objectif est de se concentrer sur la valeur apportée par la fonctionnalité. Il vous aide à penser en tranches verticales, ce qui réduit les "tâches techniques" pures. qui ne sont pas visibles. Ce n'est pas une transition facile, mais lorsque vous commencez à penser verticalement, vous commencez vraiment à réduire le gaspillage dans votre processus.

Vous pouvez également envisager les tests d'acceptation que votre client pourrait écrire pour garantir le bon fonctionnement de la fonctionnalité. Il suffit ensuite de FitNesse pour automatiser ces tests.

Answer 3

Non, ce n'est pas évident - il y a beaucoup de raisons de vouloir voir une liste, plein d'autres choses que vous voudrez peut-être avec elle - scannez-la pour plus d'informations, obtenez une vue d'ensemble, imprimez-la, copiez et collez etc. dans un document Word, etc. Ce qui vous donnera des indications précieuses sur des détails d’application raisonnables - mise en forme de la liste, contenu exact; ou même un indice qu'une fonctionnalité différente pourrait être une meilleure idée pour satisfaire ce besoin. Ne soyez pas surpris d'apprendre que la raison en est "pour que je puisse compter le nombre d'entrées" ...

Bien sûr, cela pourrait ne pas s’appliquer à vous. Ce que je veux dire en réalité, c’est qu’il ya des raisons pour lesquelles les gens ont proposé ce modèle - et il ya aussi des raisons pour lesquelles beaucoup de personnes expérimentées ne l’utilisent pas. Et lorsque vous débutez dans la pratique, vous n'êtes pas bien placé pour évaluer tous les avantages et les inconvénients de la pratique. Je vous recommande donc fortement d'essayer de la suivre de près pendant un certain temps. Vous pourriez être surpris par son utilité - ou non, auquel cas vous avez encore appris quelque chose et pouvez le laisser tomber avec une concision claire ...:)

Answer 4

User Stories est une autre façon de dire que vous devez interroger vos utilisateurs pour savoir ce qu’ils veulent et les problèmes qu’ils essaient de résoudre. C'est le coeur d'avoir cela en développement agile. Si le formulaire ne vous convient pas, prenez du recul et essayez une approche différente, plus naturelle ou plus adaptée à vos capacités en tant que rédacteur.

En bref, ne vous sentez pas obligé de porter une veste droite. L'important est que vous suiviez l'esprit de la méthodologie.

Dans ce cas précis, vous souhaitez obtenir une liste des problèmes rencontrés par l'utilisateur, de la raison de leur problème et de ce qu'ils pensent pouvoir les aider.

Answer 5

Je pense que vous devriez vraiment essayer de définir une raison, même si cela peut sembler évident. Si vous ne pouvez pas trouver une raison, pourquoi alors créer la fonctionnalité en premier lieu? La raison peut également indiquer d’autres lacunes dans la conception qui pourraient entraîner des améliorations dans d’autres domaines.

Answer 6

Je classe souvent mes histoires en fonction de l'utilisateur / du personnage auquel elles se rapportent principalement. Par conséquent, je ne mets pas l'identité de l'utilisateur dans le titre de l'histoire. Mes histoires sont aussi plus importantes que ne le suggèrent certaines méthodologies agiles. D'habitude, je commence avec un titre. Je l'utilise à des fins de planification. Une fois que je suis sur le point de travailler sur cette histoire, j’enrichis certains détails - idée de base, contraintes, hypothèses, histoires apparentées - afin de saisir davantage d’informations que je connais à ce sujet. Je conserve également mes histoires dans un wiki, pas sur des cartes de correspondance. Je comprends le compromis, c’est-à-dire que je peux passer trop de temps sur les détails avant d’en avoir besoin, mais je peux facilement le capturer et le partager avec des clients hors site.

Pour moi, l'essentiel est qu'agile est une philosophie plutôt qu'une spécification. Certaines mises en œuvre peuvent (fortement) suggérer de faire les choses d’une certaine manière et d’être non négociables sur certains articles. Par exemple, il est difficile de dire que vous utilisez XP si vous ne programmez pas de programme. En général, cependant, je dirais que la plupart des agilistes diraient que vous devez faire ce qui vous convient le mieux, de la manière dont ils le font - tant qu’ils respectent les principes généraux, vous pouvez toujours appeler vous-même agile. Les principes généraux incluraient des choses telles que la publication anticipée / la publication fréquente, les tests unitaires, les itérations courtes, la reconnaissance du fait que des changements se produiraient, le retard de la planification détaillée jusqu'à ce que vous soyez prêt à l'implémenter, ...

En résumé, si les histoires fonctionnent pour vous sans l'utilisateur et sans justification - tant que vous comprenez qui est l'utilisateur et pourquoi il veut quelque chose - faites-le comme vous le souhaitez. Il suffit simplement de ne pas avoir besoin d’une spécification complète avant de commencer à implémenter.