Les histoires et les scénarios qui implique l'interface utilisateur
https://stackoverflow.com/questions/3506856
-
29-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je suis en train d'apprendre comment utiliser BDD pour notre processus de développement et je fin à écrire des choses qui implique parfois une conception de l'interface utilisateur, donc pour tout nouveau développement ou de nouvelles fonctionnalités, l'interface utilisateur n'existe pas toujours.
Par exemple, si je dis cela dans un scénario « Quand un en-tête de colonne est cliqué » cela signifie que cette fonction est basée sur une sorte de tableau ou de la grille, mais à ce moment nous sommes toujours juste en train d'écrire l'utilisateur histoires donc il est pas encore l'interface utilisateur.
Cela me devient confus de savoir à quel moment dans le processus venons-nous avec une conception de l'interface utilisateur?
Gardez à l'esprit, je n'ai lu des articles sur BDD et je pense que cela aiderait notre équipe beaucoup, mais encore très nouveau à cela! Thx!
La solution
Si vous écrivez vos scénarios mettant l'accent sur les capacités du système, vous serez en mesure de factoriser les étapes sous-jacentes dans ces scénarios plus facilement. Il maintient leur flexibilité. Je demande donc - qu'est-ce que cliquant sur le get de colonne pour vous? Sélectionnez-vous quelque chose? Qu'est-ce que vous allez faire avec la sélection? Vous désirez trouver quelque chose et le tri par une valeur?
J'aime voir des scénarios qui disent des choses comme:
- Quand je regarde l'entrée
- Quand je vais à l'agenda pour Janvier
- Quand je regarde les entrées les plus récentes
- Quand je regarde le même T-shirt noir
Ceux-ci pourraient impliquer tout en cliquant sur un en-tête de la colonne, mais le détail de la mise en œuvre n'a pas d'importance. Il est la capacité du système.
Sous ces scénarios de haut niveau et les étapes que je souhaite créer un écran ou avec les petites étapes comme les boutons cliquant dessus. Cela le rend facile à refactoring.
J'ai écrit cela dans un DSL plutôt que l'anglais, mais il fonctionne avec la même idée - vous ne pouvez pas dire des étapes que ce soit une interface graphique ou une page Web, et quelques-unes des étapes impliquent des actions de l'interface utilisateur multiples:
Espoir que vous trouvez intéressant et peut-être que ça aide. Bonne chance!
Autres conseils
Je suppose que vous peut écrire autour en disant « quand je trier les informations par X, alors ... » Mais alors vous devez ajuster votre scénario supprimer toute mention des données affichées dans un format de grille, ce qui pourrait conduire à une écriture plutôt obtus.
Je pense que c'est une bonne idée de commencer avec la conception interface utilisateur dès que vous le pouvez. Dans le cas que vous avez mentionné ci-dessus, je pense qu'il serait tout à fait valable pour augmenter l'histoire de l'utilisateur avec le croquis de l'interface utilisateur pertinente comme vous l'imaginez, puis affiner comme vous allez le long. Un croquis au crayon sur une feuille de papier doit être fine. Ou vous pouvez utiliser une tablette et SketchBook Pro si vous voulez quelque chose tout numérique.
Mon point est que je ne vois pas une vraie raison de la conception de l'interface utilisateur à laisser de témoignages d'utilisateurs. Vous savez probablement déjà que vous allez construire un ordinateur Windows, WPF, ou de l'application Web. Et il est sûr de supposer que lorsque vous souhaitez afficher les données sous forme de tableau, vous allez utiliser une grille. Compte tenu de ces hypothèses sur les exigences les obscurcit sans ajouter une valeur réelle.
Histoires d'utilisateurs profitent du fait que vous décrivez les interactions concrètes et une fois que vous savez des données concrètes et le comportement du système, vous pourriez aussi bien ajouter plus d'informations sur la façon dont vous interagissez. Cela vous permet d'utiliser des outils comme le concombre, qui, avec Sélénium vous permet de traduire une histoire à un test. Vous pouvez aller encore plus loin et, par exemple pour les applications Web capturer toutes les pages que vous commencez histoire concrète et de récupérer toutes les interactions avec cette page qui entraîne une sorte d'architecture de l'information que vous pouvez utiliser pour la documentation ou le prototypage et les tests de l'interface utilisateur plus tard.
D'autre part, ce qui rend vos histoires un peu fragile en matière de changements UI. Je pense que la façon agile de penser à ce sujet est le même que quand il s'agit de concevoir des changements -. Ne pas concevoir pour l'avenir, à l'avenir faire la chose la plus simple possible, vous devrez peut-être changer de toute façon
Si vous vos histoires dépouillé utilisateur de toutes les choses concrètes (même entrées), vous finirez avec des cas d'utilisation (au moins dans leur format le plus simple, dépend de la façon dont vous écrivez vos histoires). Les cas d'utilisation sont à cet égard pas fragile du tout, ils précisent que les objectifs. Cela les rend résistant au changement, mais ses informations plus difficiles à transférer automatiquement à l'aide des outils.
En ce qui concerne le processus, RUP / UP tire UI de cas d'utilisation, mais je pense agile est dans sa nature incrémental (je ne dirai pas itérative, ce qui exclurait les méthodes agiles comme FDD et Kanban). Cela signifie, comme vous implémentez nouvelle histoire, vous ajoutez à votre interface utilisateur ce qui est nécessaire. Cela ne fait que d'ajouter des détails de l'interface utilisateur dans les histoires plus raisonnables. Le problème est que ce n'est pas une très bonne façon de créer l'interface utilisateur ou plus généralement UX (expérience utilisateur). C'est exactement ce que l'on pourrait appeler un point faible de agile. Les concentrés de manifeste Agile sur un logiciel fonctionnel, mais qui est-ce. Il y a autant que je sache, aucune technique agile pour la conception de l'interface utilisateur ou UX.
Je pense que vous avez juste besoin de revenir en arrière un peu.
BAD:. Lorsque je clique sur l'en-tête de colonne, les lignes se triées par colonne I cliqué
BON: Puis-je trier les lignes par nom, ou parfois par code postal si le nom est très commun, comme "Smith"
.Une histoire d'utilisateur / flux de travail est une suite de ce que l'utilisateur veut réaliser , pas une séquence d'actions comment , il réalise que. Vous collectez les Quoi afin que vous puissiez déterminer le meilleur Comment est pour tous les utilisateurs et les cas d'utilisation.
En regardant un aspect singulier de votre message:
si je dis cela dans un scénario « Quand un en-tête de colonne est cliqué » cela signifie que cette fonction est basée sur une sorte de tableau ou de la grille, mais à ce moment nous sommes toujours juste en train d'écrire l'utilisateur histoires donc il est pas encore l'interface utilisateur.
Si cela est venu d'un utilisateur, pas de vous, il montrerait un caché attente qu'il ya effectivement une table ou une grille avec les en-têtes de colonnes. Même venir de vous, il est pas tout à fait sans valeur, vous pourriez être un utilisateur aussi. Il pourrait être à courte vue, la pensée d'une grille juste parce qu'il vient d'une requête SQL, ou il pourrait être spot-on, car il est la présentation que vous attendez les données. Une création interface utilisateur isnÄt une mauvaise chose en tant que telle, mais sans tenir compte des attentes des utilisateurs est.
