Comment gérer la conception de l'interface utilisateur et la prise en charge des fonctionnalités respectives dans le développement Agile?

Dans un processus de développement Agile, l'accent est généralement mis sur les user stories, mais parfois une seule exigence peut s'étendre sur plusieurs user stories.

Par exemple, le client peut demander une page de recherche pour tous les utilisateurs d'un forum et plusieurs actions peuvent se produire sur chaque utilisateur, telles que bannir l'utilisateur, supprimer l'utilisateur, réinitialiser le mot de passe, etc.

Nous pouvons diviser cette fonctionnalité en au moins 4 user stories:

1. Recherche d'utilisateurs
2. Utilisateur banni
3. Supprimer l'utilisateur
4. Réinitialiser le mot de passe

Comment le concepteur d'interface utilisateur implémenterait-il une telle interface utilisateur? Doit-il / elle travailler sur la première user story puis commencer à incrémenter davantage de fonctionnalités dans l'interface utilisateur? Cependant, je pense que l'interface utilisateur finale sera foirée!

S'il décide de travailler sur l'ensemble de la fonctionnalité (recherche + actions), que se passerait-il si les actions étaient de faible priorité et seraient mises en œuvre plusieurs itérations après que la fonctionnalité de recherche a été effectuée?

Prenez-le itérativement. Vous travaillez directement avec les utilisateurs, non? Donc ça ne devrait jamais vraiment être un gâchis.

Faites d'abord la page de recherche. Vous et les utilisateurs devez garder à l'esprit qu'ils voudront pouvoir effectuer des actions sur les résultats. Les utilisateurs l'aiment-ils? OK, vous avez votre recherche.

Ajoutez maintenant le "Changer le mot de passe" (ou ce qui est prioritaire ensuite). Oups, nous devons changer un peu la page de recherche - eh bien, le changement fait souvent partie du jeu. Les utilisateurs aiment-ils les résultats? Bien.

Maintenant, ajoutez l'élément suivant et le suivant ...

L'approche agile indique que vous avez toujours des commentaires immédiatement, donc vous devriez être bon.

Cela dit, il n'y a aucune raison réelle pour laquelle vous ne pourriez pas attaquer 2 de ces histoires dans la même itération (en ajoutant supprimer l'utilisateur ET interdire l'utilisateur). La clé est de toujours travailler avec le client pour s'assurer qu'il a raison.

Vous allez souvent (toujours?) Vous retrouver avec des utilisateurs qui pensent à autre chose qu'ils veulent faire à partir de cet écran de recherche une fois que votre "conception" originale est terminée et implémentée. Donc, vous finirez par le modifier à un moment donné de toute façon. Abordez le tout avec cette attente et vous devriez être bon.

J'ai l'impression de dire beaucoup de choses. Agile ne signifie pas que vous devez mettre des œillères pour ignorer l'avenir et vous concevoir dans un coin. Agile concerne la façon dont vous fournissez les fonctionnalités et n'a que très peu à voir avec la façon dont vous concevez les fonctionnalités.

En d'autres termes, il est normal de regarder aussi loin dans le futur que vous le souhaitez lors de la création de votre design, tant qu'il ne retarde pas la livraison de fonctionnalités à court terme.

Dans votre exemple spécifique, cela signifie que vous allez de l'avant et que vous concevez l'interface utilisateur de sorte qu'il sera facile d'ajouter des actions plus tard. Cependant, si travailler sur la bonne conception des actions retarderait la livraison de la recherche utilisateur de base par une itération, il est préférable de faire d'abord une conception sans actions, en supposant qu'une recherche sans aucune action a de la valeur pour le client.

La question à vous poser est: "Ce travail de conception retarde-t-il ma première livraison?" La plupart du temps, la réponse sera non. Vous devez quand même faire un design, tout ce que vous changez, ce sont des critères de design.

La première histoire d'utilisateur peut être la conception de toute l'interface - ils n'ont pas à en concevoir une seule pièce. C'est la conception dans son ensemble qui ajoute de la valeur commerciale.

Cela étant dit, je vois au moins deux fonctionnalités distinctes ici: la possibilité de rechercher des utilisateurs et la possibilité d'exécuter une fonction sur un ou plusieurs utilisateurs. Le concepteur pourrait s'attaquer à chacun de ceux-ci avec parcimonie si cela a plus de sens.

N'oubliez pas: l'objectif est de fournir des logiciels de qualité, ce n'est pas de suivre aveuglément une méthodologie. Demandez-vous si la décomposition du design en morceaux aide ou entrave cet objectif. Il n'y a pas de mêlée, seulement des clients heureux ou insatisfaits.

J'ai eu l'opportunité de faire un stage dans une usine de programmation Agile / Extreme. Ils utilisaient des story-cards pour piloter le processus de développement itératif. Chaque story-card a entraîné une implémentation ou un changement. La clé était l'interaction des utilisateurs. Comment concevoir avec succès une interface destinée à un utilisateur sans interagir avec un utilisateur du logiciel?

Un scénario possible consiste à commencer par l'interaction avec l'utilisateur pour décider ce que l'utilisateur veut d'abord. Ensuite, de manière itérative, concevez l'interface utilisateur en fonction de l'augmentation des commentaires, de la priorité de l'utilisateur et de ce que l'utilisateur doit avoir.

Les user stories sont là pour déterminer comment l'utilisateur interagirait, à quel niveau et de quelle manière. Mais ce ne sont que des approximations jusqu'à l'interaction avec l'utilisateur. S'il y a une multitude d'utilisateurs qui souhaiteraient tous quelque chose de spécifique, alors une petite enquête auprès des gens pourrait être afin de définir une base de référence pour l'interface utilisateur.