Comment pouvons-nous suivre les détails d'une histoire d'utilisateur? [fermé]

Question

Donc, si une histoire d'utilisateur est quelque chose de nébuleux comme:

En tant que représentant des ventes, je voudrais saisir les informations de contact afin que je puisse le suivi plus tard.

Je ne suis même pas sûr que ce soit une histoire d'utilisateur valide mais je suis sûr qu'il est assez proche.

Ensuite, il y a des détails / tâches pour la mise en œuvre de cette histoire d'utilisateur. Et je suis sûr que « Le représentant des ventes devrait être en mesure de l'onglet d'une zone de texte à l'autre. » est l'une des exigences. Comment capturer / suivez-nous cela? Est-ce une partie de l'histoire de l'utilisateur ou est-ce quelque chose qui est à considérer séparément?

Answer 1

Une histoire d'utilisateur capture l'essence d'une caractéristique, pas les détails, une histoire est un support pour la discussion.

Alors, pour répondre à votre question, les détails sont transmis oralement au cours d'une discussion, car discussion face à face est générateur carte d'index ). Si trouve cela très pratique, en particulier lors de l'utilisation des spécifications exécutables.

PS: votre histoire est parfaitement valide et est une bonne pratique d'inclure les avantages dans votre modèle ( «En tant que rôle , je veux Action pour que avantages ").

Answer 2

histoires de l'utilisateur doivent être courtes déclarations 1 à 3 phrases.

http://en.wikipedia.org/wiki/User_story

Je veux être en mesure d'onglet d'une zone de texte à un autre est une autre histoire utilisateur.

Vous pouvez suivre ces choses dans un outil comme www.rallydev.com, ou tout simplement tout type d'outil de suivi des tâches (SharePoint, Excel même ... etc.).

La prochaine chose que vous faites est la priorité.

Answer 3

Il suffit de prendre un coup de poignard rugueux ...

  

En tant que représentant des ventes,
  Je veux toutes les entrées de données et la navigation à accomplir à l'aide du clavier
  de sorte que je ne dois pas prendre mes mains sur le clavier
   (et que nous nous conformons aux directives d'accessibilité) .

ou

  

En tant qu'entreprise,
  Nous voulons que tous nos produits soient pleinement utilisables en utilisant exclusivement le clavier
  Alors que nous pouvons vendre à des clients qui ont besoin d'un logiciel accessible.

Answer 4

La première partie appartient à un document « exigences commerciales » (habituellement écrit par un analyste d'affaires). Les premières générations de ce document sont très haut niveau, mais les versions finales (plusieurs itérations ultérieures) sont assez détaillées.

http://www.tdan.com/view-articles/6089

La seconde partie (environ tabulant) fait partie d'un autre document - « spec UX » (montre tous les écrans et décrit l'interaction de l'utilisateur). Celui-ci est habituellement écrit par une personne / équipe différente (Product ou équipe UX).

http://uxdesign.com/ux-defined-2

http: //www.uxmatters .com / mt / Archives / 2007/05 / partage la propriété-de-ux.php

Answer 5

Oui, c'est le problème que nous avons aussi beaucoup. D'une part, les histoires d'utilisateur doivent être CONSCISE, d'autre part tous les petits détails doivent Nitty être mis quelque part .

Nous utilisons XPlanner, et nous résoudre ce problème en mettant la description courte dans le corps du texte de l'histoire de l'utilisateur. Ensuite, nous utilisons XPlanners « notes » fonctionnalité (texte arbitraire ou des fichiers qui peuvent être attachés à une histoire d'utilisateur) pour les détails.

De cette façon, nous pouvons ajouter autant d'informations que nécessaire pour une histoire d'utilisateur, sans encombrer le texte de l'histoire de l'utilisateur lui-même. Vous pouvez également consulter la documentation externe, si vous ne voulez pas avoir tout XPlanner.

Cette approche fonctionne très bien pour nous.

Answer 6

D'accord avec les autres, que ce soit l'histoire viable, mais les capturer (dérivés) exigences peuvent être mieux pris ailleurs.

développeurs de logiciels et les types d'entreprise connaissent une terminologie différente ce que certains peuvent simple à comprendre par un (des structures de données) peut signifier rien à l'autre. L'utilisateur Stories est un outil ou un moyen par lequel l'utilisateur d'affaires peut transmettre un message comme un point de départ qui est étendu sur (avec les tests, les détails, etc.).

Communication orale peut être efficace, mais l'efficacité dépend de la capacité des récepteurs d'entendre et de comprendre la signification du message. C'est là peut échouer la communication orale. Différents types de communication offerring formes plus ou moins formelles de communication. La communication vocale est une « forme informelle de communication » qui risque le message étant mal entendu, misinterpretted, et de l'incompréhension. Tout comme le jeu a joué comme un enfant, où un enfant chuchote un message à un autre enfant, qui raconte une autre, jusqu'à ce que tous ont entendu ... Quand le dernier enfant dit le message au groupe, il a souvent été mal interprété à nouveau misinterpretted puis, provoquant un message dégradé.