Qui fait l'UX sur un projet Scrum?

D'ACCORD. Disons que vous travaillez sur un projet de mêlée de manuels. Vous avez un maître Scrum qui collabore avec un propriétaire de produit. Le prochain sprint est lourd en interface utilisateur - au moment où vos codeurs commencent à créer des écrans, vous voulez vraiment avoir une idée de ce à quoi ils vont ressembler.

Qui fait le wireframing et quand? Le propriétaire du produit? Quelqu'un qui soutient le propriétaire du produit? Le scrum master? Si vous avez un expert UX, travaillent-ils aux côtés des codeurs après le début du sprint, ou fournissent-ils des wireframes et des maquettes à l'avant qui se trouvent à côté de vos cartes d'histoire et de vos contraintes pour guider et informer le travail des développeurs?

Je suis sûr que nous avons besoin d'aide UX, vous voyez, mais je ne sais vraiment pas où l'appliquer ...

EDIT: Permettez-moi de reformuler la question.

Comment offrez-vous une expérience utilisateur cohérente et de haute qualité sur un projet agile?

Le concepteur d'interaction

UX! = UI Vous avez besoin d'un concepteur d'interaction expérimenté pour offrir une bonne expérience utilisateur, contrairement à la croyance populaire qui n'est pas un programmeur. Pour tous les programmeurs qui pensent pouvoir faire de l'UX (cela inclut moi), permettez-moi de dire ceci. Pour réussir dans la conception d'interaction, il faut au moins autant de temps que pour bien maîtriser la programmation. Combien de temps avez-vous consacré à la conception d'interactions pures?

Dans la phase initiale, il incombe aux concepteurs d'interaction de:

1. Extraire les objectifs réels de la solution du propriétaire du produit
2. Définissez les personnes qui utiliseront la solution.
3. Écrivez des scénarios qui sont des histoires sur la façon dont la solution sera utilisée.
4. Compiler un document de conception qui laisse peu de place à l'ambiguïté du point de vue UX

Au cours du projet, il incombe aux concepteurs d'interaction de s'assurer que ces directives sont suivies et de résoudre tout problème supplémentaire qui se posera (et ils se produiront).

De nombreux programmeurs vont adopter cette approche, j'en suis sûr, car tout le monde pense qu'ils sont l'exception qui peut concevoir des interfaces "merveilleuses", ce n'est probablement pas le cas. D'un autre côté, une bonne relation concepteur d'interaction - programmeur est souvent très agréable pour le programmeur et n'a pas à lutter contre une "spécification stupide". Malheureusement, il est difficile de trouver de bons concepteurs d'interaction, mais ils existent.

Comme toujours, je recommande vivement les livres d'Alan Coopers sur le sujet ("About Face" et "The Inmates are running theylum")

Je suggère d'organiser le travail du gars UX de la même manière que le reste de l'équipe. Il doit être considéré comme un membre égal de l'équipe, participer à des standups et communiquer étroitement avec les programmeurs.

Idéalement, les maquettes devraient être effectuées au moins un sprint à l'avance, mais pour les fonctionnalités plus petites, il pourrait être judicieux d'envisager de créer des maquettes comme sous-tâche d'une histoire prévue pour l'itération en cours.

Comme toujours avec Agile, utilisez votre bon sens, expérimentez différentes approches et respectez celle qui convient le mieux à votre situation particulière.

À mon avis, il s'agit en quelque sorte d'un cas spécial qui doit être traité de manière spéciale. Scrum master ne participera certainement pas à cela - ce n'est pas du tout son rôle. L'équipe est généralement un groupe de développeurs et la plupart d'entre eux n'ont aucune expérience en UX et ce sera une perte de temps de les y forcer. Vous embaucherez un expert UX et l'expert ne fera pas partie de l'équipe - l'équipe doit être interfonctionnelle et l'expert UX ne sera probablement pas un développeur. De plus, UX expert ne sera pas sur le projet pendant toute sa durée. L'expert UX travaillera avec le propriétaire du produit un sprint à l'avance pour préparer des maquettes et des wireframes pour les user stories à venir afin que l'équipe sache ce qui devra être fait lors du prochain sprint - des maquettes seront disponibles lors de la réunion de planification.

Éditer:

J'ai fait des recherches supplémentaires parce que je savais que j'avais lu quelque chose à ce sujet quelque part et je le trouve enfin dans Réussir avec Agile: Développement de logiciels à l'aide de Scrum par Mike Cohn . Mike discute exactement du rôle du concepteur UX dans l'équipe. Sa description initiale est similaire à la mienne et il considère que c'est un changement naturel lorsque l'entreprise change la méthode de développement de la cascade à Scrum, mais plus tard, il la conclut comme non recommandée. La raison en est que si les concepteurs UX ne font pas partie de l'équipe, ils peuvent se considérer comme une équipe distincte et ils n'ont pas à partager l'engagement de l'équipe de développement.

Malgré cela, la réponse de @Adam Byrtek ressemble à la bonne. Intégrez le gars UX à l'équipe et laissez-le coopérer avec les développeurs sur les user stories actuellement implémentées. Cela ne prendra pas tout le temps du gars UX donc il coopérera également avec le propriétaire du produit ou le client pour préparer des maquettes et des wireframes pour un ou deux sprints à venir.

Je suis abonné à la boîte d'alerte de Jakob Nielsen (principalement en raison de ses critiques sur les pratiques de conception de sites Web ennuyeuses) et je me souviens que j'ai récemment lu quelques articles sur le sujet (bien que je n'ai à peine une moindre compréhension de l'ensemble du processus de développement agile), peut-être qu'ils le seraient de toute utilisation pour vous:

• Projets d'expérience utilisateur agile
• Projets de développement agile et convivialité

Pour "Scrum manuel":

Tout d'abord, Scrum Masters ne collabore pas avec les propriétaires de produits - enfin pas du tout autrement que par le fait que toute l'équipe, y compris le SM et le PO, collabore pour construire le système.

Deuxièmement, les équipes Scrum sont censées être homogènes avec les membres de l'équipe interfonctionnelle. Vous n'auriez donc pas de "UX Guy".

De plus, vous ne construirez probablement pas l'UX a Sprint avant le code fonctionnel. Les fonctionnalités sont livrées entièrement dans un seul Sprint. Si l'UX associé à une fonctionnalité est trop complexe pour être livré avec le code fonctionnel dans un seul Sprint, vous divisez l'ensemble de la fonctionnalité en quelque chose qui peut être fait, y compris les éléments UX, en un seul Sprint.

Qui fait UX sur un projet de cascade? Qui fait le développement mainframe sur un projet XP?

La méthodologie du projet n'a pas d'importance. Chaque projet technologique nécessite certains rôles spécialisés. Parfois, un projet peut s'en tirer sans un «concepteur d'interaction» entièrement sous licence et cautionné (quoi que cela signifie). Parfois, vous avez besoin de quelqu'un de spécialisé. Mais la même chose pourrait être dite pour tous les autres rôles.

Donc, passez à votre deuxième question sur la façon dont vous offrez une expérience utilisateur de haute qualité en utilisant Agile. Nous l'avons géré dans le dernier projet Scrum auquel j'ai participé en impliquant tôt et souvent l'analyste commercial et le client. De plus, nous avions un développeur qui avait un œil particulièrement bon pour l'UX. Il avait tendance à apporter des modifications mineures aux interfaces utilisateur sur lesquelles les développeurs travaillaient après avoir effectué des commits.

Nous n'avons pas livré une UX parfaite à la fin de chaque sprint. Les démos exposaient généralement un problème ou deux du point de vue UX. Mais nous avons corrigé ceux pour le prochain sprint (si cela en valait la peine pour le client) et au moment où nous sommes sortis en production, nous avions un UX très solide.

Si par UX, vous voulez dire concepteur d'interface utilisateur, ils ne sont qu'un autre rôle ou ressource pour l'équipe. La conception de l'interface utilisateur, comme toute conception, traverse un projet. Il y a une quantité raisonnable de travail d'architecture / conception qui devrait être fait à l'avance et il y en a une qui peut être faite au fur et à mesure.

Il convient de noter que les tâches de conception d'interface utilisateur ne correspondent souvent pas à la même portée qu'un sprint de développement. Lors de la conception d'un composant d'interface utilisateur, la conception peut prendre de nombreux sprints à implémenter.

Dans la pratique, j'ai tendance à trouver que les concepteurs d'interface utilisateur / UX ont besoin d'un délai raisonnable pour traiter les aspects qui doivent être cohérents dans l'ensemble de la solution. J'aime y voir une architecture logicielle. La conception de composants spécifiques peut souvent être effectuée un sprint avant la mise en œuvre, mais j'ai tendance à constater qu'une fois que les concepteurs sont en cours, ils peuvent aller bien au-delà de la mise en œuvre. Les sprints ultérieurs ont tendance à être de bons endroits pour implémenter / explorer le look & feel ainsi que pour obtenir des commentaires sur l'utilisabilité lorsque la solution commence à prendre forme. Les résultats de ces exercices ultérieurs sont réinjectés dans la planification du prochain sprint.