Quel type d'histoires d'utilisateurs doivent être écrites dans les premières étapes d'un projet?

Au début d'un projet, vous n'avez rien - pas d'interface utilisateur, pas de couche de données, rien entre les deux. Ainsi, une seule histoire comme «les utilisateurs devraient pouvoir voir leurs foos» nécessitera beaucoup de travail. Une fois que vous avez cette histoire, celui comme "les utilisateurs devraient pouvoir modifier leurs foos" est plus réaliste, mais cette première histoire impliquera la configuration d'une couche d'interface utilisateur, une couche logique de présentation, une couche logique de domaine et une couche d'accès aux données.

Cela ne correspond pas à mon concept de "tâches": pour moi, je préfère avoir quelque chose comme les "tâches" suivantes:

• Afficher des données factices pour les foos d'un utilisateur en HTML, dérivées d'objets JavaScript.
• Configurez une couche logique de présentation et connectez-y les objets JavaScript.
• Configurez une couche logique de domaine et connectez-y la couche logique de présentation.
• Configurez une couche d'accès aux données et connectez-y la couche logique du domaine.

Tous ces éléments relèvent-ils de la seule "histoire" ci-dessus? Si c'est le cas, j'ai l'impression que les histoires ne sont pas un cadre terriblement utile dans les premières étapes d'un projet. Si c'est le cas, c'est bien --- Je veux juste m'assurer de ne rien manquer, car j'essaie vraiment d'apprendre cette méthodologie agile du mieux que je peux.

C'est une bonne question et il y a probablement plusieurs bonnes réponses. Ma prise est la suivante:

Une histoire est une histoire d'utilisateur , elle doit donc être définie en termes décrivant ses avantages pour l'utilisateur.

Si Agile et les histoires vont fonctionner pour vous, alors ils devraient fonctionner même au début. Le premier point est une histoire d'utilisateur unique (libellée un peu technique cependant), mais les trois autres sont des descriptions de tâches techniques.

Dans les premières étapes d'un projet, lorsque vous ne disposez pas des cadres appropriés pour faire CRUD ( C réer, R ead, U pdate, D elete) rapide de développement et facile, vos histoires doivent être beaucoup plus petit, incrémental pièces.

Au lieu de "L'utilisateur devrait pouvoir voir son foo" , quelque chose comme ceci:

1. L'utilisateur doit pouvoir voir une page contenant des exemples de données
2. L'utilisateur doit pouvoir voir une page avec des exemples de données interactives
3. L'utilisateur doit pouvoir voir une page contenant des données d'exemple interactives en direct

N'oubliez pas que la plupart des histoires d'utilisateurs qui semblent trop énormes pour être développées en un seul sprint (j'ai trouvé que tout ce qui dépassait environ 8 points d'histoire ou jours de développement était trop grand) peuvent probablement être décomposées en morceaux qui sont toujours significatifs pour l'utilisateur.

L'histoire / fonctionnalité ne doit pas être commercialisable, elle doit simplement être significative pour le propriétaire du produit. Dans le cas ci-dessus, vous pouvez ajouter des éléments de démonstration rapides pour montrer ce qui a changé et comment cette histoire est désormais réalisée - par exemple, pour # 3, vous pouvez afficher la page de deux utilisateurs différents avec des données préremplies dans la base de données . À l'étape 2, tous les utilisateurs verraient les mêmes données.

Ce que vous demandez est essentiel "comment pensez-vous de l'espace du problème" afin de le décomposer en morceaux sensibles, à partir desquels vous pouvez faire un design.

Que vous appeliez cela la user story, ou l'analyse, ou la décompostion, ou les spécifications, ou la collecte des exigences ... au final, cela revient à plusieurs choses qui normalement auront une certaine itération.

Vous devez obtenir de la tête des utilisateurs ce qu'ils veulent. (Ils savent probablement ce qu'ils veulent et veulent des choses incohérentes mais ne peuvent pas encore le voir.)

Vous devez capturer cela sous une forme - vous n'avez vraiment que 2 choix: des mots ou des images. Les deux ont du pouvoir, utilisez-les tous les deux si vous le pouvez. Les mots sont finalement plus puissants du point de vue d'un différend contractuel ultérieur.

Vous devez présenter ce dossier et rechercher un accord.

Certaines personnes réalisent les premiers prototypes visuels sans aucune logique commerciale ou autre. Cela peut être une technique puissante - jusqu'à un certain point, car elle implique toujours une certaine quantité d'agitation de la main.

Certains feront du story-board - puis présenteront et expliqueront.

Certains rédigeront des documents rigoureux et soigneusement analysés.

Chaque technique a ses avantages et ses inconvénients.

Le seul conseil que je donnerais est le suivant: se précipiter pour coder une solution trop tôt est généralement une mauvaise décision. Comprendre QUOI faire, pour QUI et POURQUOI, avant de le faire conduit généralement à moins de retouches et à un développement plus rapide.

Lorsque vous parlez de "tâches", cela me semble être une sorte de panne du travail, après avoir compris ce qui, qui et pourquoi. Vous ne pouvez PAS bien comprendre les tâches tant que vous n'avez pas compris l'histoire utilisateur, dans un document, approuvé par le client comme l'étendue du travail que vous allez faire. Savoir ce que vous devez accomplir (la sortie) vous permet de comprendre les tâches (les étapes nécessaires pour y arriver).

Ne lésinez pas sur l'analyse et la documentation frontales.

Je pense que ce qui vous manque, c'est que les histoires d'utilisateurs décrivent comment l'utilisateur s'attend à utiliser le système. C'est une façon de déterminer les besoins de l' entreprise . Ils ne sont pas conçus pour vous dire directement quoi faire techniquement, ce que vous semblez vouloir.

Il s'agit sans doute de l'une des parties les plus importantes d'un projet. Si vous n'obtenez pas les exigences commerciales correctes, le système ne sera d'aucune utilité pour les utilisateurs.