Les concepteurs UX préparent un Sprint

13

Nos concepteurs UX ont généralement une histoire dans Sprint X que les développeurs implémenteront dans Sprint X + 1 (les concepteurs UX et les développeurs / testeurs sont sur une seule équipe). Je pense que cela a du sens car si vous n'avez pas de maquette d'écran et de spécifications claires, vous ne pouvez pas vraiment estimer le travail pendant la planification de sprint.

Cependant, dans Scrum, vous n'êtes censé avoir que des user stories qui apportent de la valeur à l'utilisateur. Dans notre cas, les histoires de conception UX n'apportent pas une telle valeur (elles ressemblent plus à une activité de préparation de l'arriéré). De plus, les entraîneurs Scrum ne recommandent généralement pas d'avoir des spécifications complètes avant le début du Sprint, une recommandation que j'ai du mal à comprendre.

Voyez-vous donc des inconvénients dans notre approche? Cela semble fonctionner pour nous, mais cela va un peu à l'encontre des principes Scrum.

Eugène
la source
3
Pourquoi la conception UX n'apporterait-elle pas de valeur à l'utilisateur? En supposant que vous continuiez à scrum et que vous continuiez à utiliser les concepteurs UX, je ne vois pas qu'il existe une alternative, et si vous n'en avez pas, comment peut-il y avoir des inconvénients?
Michael Shaw
Parce qu'une maquette d'écran et une liste des exigences de l'interface utilisateur ne fournissent pas de valeur directe à l'utilisateur. Ceux-ci ne fournissent de la valeur qu'après avoir été mis en œuvre dans l'histoire du prochain Sprint.
Eugene
Votre problème pourrait être que vous n'avez pas de concepteurs ou idéalement des ingénieurs UX, vous avez des graphistes. Ils utilisent juste Photoshop, non? Pas de CSS JS ou XAML ou Interface Builder ou des côtelettes techniques frontales? Vous n'avez donc pas de designers. Vous avez besoin de vrais designers. Vous n'aurez alors pas cette confusion.
RibaldEddie
Non. Nous avons à la fois des concepteurs d'interaction avec les utilisateurs et des graphistes. Les deux travaillent un sprint avant le développement
Eugene
10
Comment l'interaction avec votre clientèle à l'aide de maquettes et de prototypes n'apporte-t-elle pas de valeur à l'utilisateur? La valeur n'est pas définie comme code d'expédition. La tangibilité est très bonne à avoir mais n'est pas essentielle pour la valeur.
BobDalgleish

Réponses:

15

Cependant, dans Scrum, vous n'êtes censé avoir que des user stories qui apportent de la valeur à l'utilisateur.

La valeur n'est pas mesurée uniquement en lignes de code livrable.

Vous semblez impliquer qu'avoir une interface utilisateur bien conçue ne fournit aucune valeur. Bien sûr que oui. Évidemment, il y a de la valeur pour l'utilisateur final, mais il y a aussi de la valeur pour votre équipe de développement, qui est une partie prenante parfaitement valide. Si vous n'avez pas les outils et les matériaux pour faire votre travail, vous ne pouvez pas apporter de valeur à l'utilisateur final.

Ne vous attardez pas sur le dogme de la mêlée. Scrum est là pour vous rendre plus efficace. Si faire une histoire UX un sprint avant d'implémenter l'interface utilisateur vous aide à fournir un meilleur logiciel, faites-le.

Bryan Oakley
la source
2
"Le logiciel de travail est la principale mesure du progrès.", Pas UX. UX ne vaut rien s'il ne fonctionne pas. Vous auriez raison si vous préconisiez d'avoir UX en même temps ou plus tard avec la fonctionnalité réelle, mais vous ne le faites pas, donc cette réponse est carrément fausse.
Sklivvz
3
@Sklivvz: Je suppose que nous devons accepter d'être en désaccord. S'il est vrai que le logiciel de travail est la principale mesure du progrès, ce n'est pas la seule mesure. Une certaine quantité de conception doit être effectuée à l'avance avant qu'une équipe puisse commencer à coder. UX n'est pas quelque chose que vous pouvez simplement virer à la fin.
Bryan Oakley
4
@BryanOakley Je suis d'accord qu'il faut réfléchir à tout le travail en amont, pas seulement à ux. Cependant, la valeur de ce travail est décidée par les parties prenantes. Si le travail ux est effectué un sprint à l'avance, la boucle de rétroaction vient d'être prolongée d'au moins un sprint. Je dirais que c'est un risque inutile. UX n'est pas différent de la conception, de l'architecture, de la conception de base de données ou du format de rapport. Tout peut être fait en un seul sprint, avec des éléments de backlog de produit créés sous forme de tranches de fonctionnalités verticales.
Derek Davidson PST CST
Cela peut être fait en un seul sprint, mais sans savoir quelle sera l'expérience utilisateur, comment pouvez-vous planifier le reste du travail? Si vous ne connaissez pas la conception détaillée du logiciel, vous pouvez toujours planifier le travail. Mais si vous ne savez même pas à quoi ressembleront l'écran et les fonctionnalités, comment planifier quoi que ce soit?
Eugene
1
En travaillant de manière incrémentale, comme c'est la manière agile habituelle. Les développeurs produisent un prototype en collaboration en temps réel avec un concepteur d'UX ou basé sur leurs propres idées sur l'UX; une fois qu'un prototype fonctionne, un concepteur l'examine et fournit une liste de modifications. Une histoire n'a pas besoin d'une planification détaillée; il suffit d'une estimation de la taille (et certains contestent même cela).
Jules
13

Les principaux inconvénients sont les suivants:

  1. Vous êtes pipe-lining: si vos concepteurs sont en retard, vos développeurs se retrouvent sans travail; si vos développeurs sont en retard, votre concepteur finira par travailler plus d'une itération à l'avance. Ce n'est pas une situation stable - ce n'est pas durable .

  2. Vos concepteurs travaillent à l'avance, vous payez des frais pour des histoires qui peuvent ou non être développées. Même si cela se produit rarement, vous jetez toujours de l'argent.

  3. Vos concepteurs UX prennent des décisions à l'avance sans impliquer les développeurs. Vous manquez des informations utiles et augmentez le risque que les conceptions soient carrément fausses ou irréalistes. Ceci est assez courant car la conception UX n'est pas un exercice "abstrait" - elle doit être élaborée à partir des caractéristiques de l'application (y compris ce qui est faisable / conseillé de faire ou non techniquement)

  4. Exclure ou priver de pouvoir vos développeurs n'est pas un moyen durable de gérer un projet.

  5. Les concepteurs n'apportent pas de valeur: cela signifie qu'il est difficile, voire impossible, de hiérarchiser correctement leur travail. Habituellement, le travail du développeur est priorisé en utilisant différentes préoccupations, la valeur, la faisabilité dans le prochain sprint, la quantité d'effort. Beaucoup d'histoires de temps sont négociées et modifiées afin de les rendre «adaptées» ou à cause d'une discussion utile: si tout cela change l'interface utilisateur (et vous pouvez supposer que cela change si ce n'est pas un simple détail d'implémentation), que faites-vous avec l'histoire? Vous ne pouvez plus y jouer.

  6. Vous supposez qu'une histoire qui peut tenir dans une seule itération pour les concepteurs tient dans une seule itération pour les développeurs: comment pouvez-vous diviser les histoires pour que cette hypothèse soit correcte?

Sklivvz
la source
Les commentaires étaient largement hors sujet et ont donc été supprimés.
ChrisF
1
Vous dites que "vos concepteurs UX prennent des décisions ... sans impliquer les développeurs". Comment le sais-tu? Ce n'est pas parce qu'ils travaillent un sprint à l'avance qu'ils ne travaillent pas avec les développeurs. Peut-être que les développeurs sont leurs parties prenantes. Cela va également au point 4 - vous supposez que les développeurs sont exclus, mais ce n'est pas nécessairement le cas. Quant aux «concepteurs ne fournissent pas de valeur», je ne pourrais pas être plus en désaccord. Vous ne voyez aucune valeur dans l'UX correctement conçu? Bien que je pense que vous soulevez des points qui méritent discussion, vous faites beaucoup d'hypothèses qui pourraient ne pas être vraies.
Bryan Oakley
@bry soit ils travaillent sur ux, soit ils ne le font pas. Sûrement être impliqué dans le processus ux est considéré comme un "travail" sur une histoire. Concernant votre évaluation de la valeur ... Ils n'ajoutent pas de valeur s'ils fonctionnent à l'avance car ils ne produisent rien qui puisse être déployé. Si quelque chose n'atteint jamais le client, cela n'a aucune valeur pour lui.
Sklivvz
re: "être impliqué dans le processus ux équivaut à" travailler "sur une histoire." Pas nécessairement. Les gens viennent me poser des questions tout le temps, cela ne veut pas dire que je travaille sur leurs histoires.
Bryan Oakley
2
@BryanOakley sûrement, mais les problèmes restent d'actualité: comparer "renvoyer" un design parce qu'il est irréaliste de l'exécuter vs le faire correctement la première fois parce que c'est fait pendant qu'un développeur y travaille. De plus, il y a des problèmes qui ne sont découverts que lors de la mise en œuvre, et à ce stade, le concepteur fait la prochaine histoire ...
Sklivvz
6

Je l'aime, pour deux raisons:

  1. cela semble fonctionner pour vous; il est difficile de discuter avec succès!
  2. l'équipe UX prend l'histoire et commence la conversation tôt - et les conversations sont en quelque sorte le but des histoires
Steven A. Lowe
la source
4

Une exigence de base de Scrum est que l'équipe Scrum possède toutes les compétences nécessaires pour créer un produit potentiellement libérable. Dans la situation que vous décrivez, cela ne se produit pas.

L'équipe UX ne produit pas de produit potentiellement libérable et l'équipe Scrum n'est pas capable de produire des tranches de fonctionnalités verticales car elle n'a pas toutes les compétences requises. Ce sont des dysfonctionnements.

Sklivvz a écrit un excellent article sur les problèmes que les dysfonctionnements ci-dessus pourraient entraîner. En résumé, je ne pense pas que vous pratiquiez Scrum.

Mais il n'y a absolument rien de mal à cela. Si vous avez découvert une façon de travailler qui vous apporte de la valeur et que vous en êtes tous satisfaits, continuez à le faire. Mon seul conseil serait d'inspecter et d'adapter fréquemment.

Notez, cependant, que si votre objectif est de fournir un logiciel à l'aide de Scrum, vous devrez résoudre les dysfonctionnements identifiés.

Derek Davidson PST CST
la source
Comme je l'ai dit dans mon article d'origine: "Les concepteurs UX et les développeurs / testeurs sont dans une seule équipe"
Eugene
2
@Eugene Dans quel sens font-ils partie de la même équipe? Je dirais que s'ils travaillent un sprint à l'avance, ils ne font pas partie de la même équipe. Soit dit en passant, Scrum est également clair qu'il ne reconnaît pas les "sous-équipes", donc je dirais que votre situation ne ressemble pas à Scrum. Certainement pas comme je le sais.
Derek Davidson PST CST
Ils font un sprint avec le reste du temps. Le reste de l'équipe examine généralement au moins leur travail et aide parfois à la conception elle-même.
Eugene
4

Il y a deux problèmes ici, l'un concernant la conception centrée sur l'utilisateur et l'autre concernant l'alignement du sprint.

Premièrement : les histoires d'utilisateurs doivent être alignées sur les besoins des utilisateurs, pas seulement sur le backlog. Les histoires UX doivent avoir une valeur claire pour les utilisateurs. Cela ne nécessite pas de spécification complète et une brève déclaration telle que,

"Les utilisateurs auront un accès plus facile à l'activité du compte sur une seule page plutôt que divisé entre plusieurs pages"

est adaptable et adaptable à diverses implémentations et pourtant clair sur la valeur pour l'utilisateur (accès plus facile à l'activité du compte).

Seconde : alignement du sprint. UX conçoit des fonctionnalités dans le sprint X que les développeurs implémentent au printemps X + 1. En pratique, cela se produit dans de nombreux magasins et parfois, cela peut ressembler davantage à une implémentation dans le sprint X + 2 ou X + 3. Avec une équipe serrée et expérimentée, cette configuration peut fonctionner. Cela devient difficile si vous avez une nouvelle équipe ou de nouveaux membres qui ne connaissent pas les compétences, les préférences, les habitudes, les styles de travail et les tendances des autres membres de l'équipe. Si vous travaillez ensemble depuis moins de 6 mois, cela risque d'être un problème.

Prenez du recul et réévaluez. Du côté positif, vous avez les concepteurs et développeurs UX travaillant côte à côte, ce qui est une aubaine. Commencez par vous assurer que vos histoires ont une valeur claire pour les utilisateurs.

atimba
la source
2

L'un des problèmes possibles que je vois est que dans Scrum, la portée du sprint N + 1 est normalement déterminée juste avant son démarrage. Alors, comment pouvez-vous faire de l'UX pour les histoires de sprint N + 1 dans le sprint N avant de savoir quelles histoires seront dans la portée. Si vous décidez de fixer la portée du sprint N + 1 au début du sprint N, vous perdez une certaine flexibilité.

Frank Bakker
la source
1

Cependant, dans Scrum, vous n'êtes censé avoir que des user stories qui apportent de la valeur à l'utilisateur. Dans notre cas, les histoires de conception UX n'apportent pas une telle valeur (elles ressemblent plus à une activité de préparation de l'arriéré).

À mon avis, ils offrent beaucoup de valeur à leur utilisateur. Le fait est que leur utilisateur n'est pas l'utilisateur final de l'entreprise, leur utilisateur est l'équipe de développement qui implémentera la fonctionnalité au sprint X + 1.

mverardo
la source
1

Vous êtes coincé dans la religion du processus et en cours de route, je vois que Scrum / Agile est mal utilisé et que les utilisateurs sont mal étiquetés. Scrum n'est pas un outil universel, c'est un moyen de parvenir à une fin.

Je pense que votre groupe a mal identifié qui sont vos utilisateurs et planifie le mauvais public.

Le groupe UX utilise Scrum de manière classique, la valeur utilisateur et l'adaptation agile aux entrées de certains utilisateurs finaux magiques. Ils sont celui avec les utilisateurs. Votre groupe utilise abusivement Scrum parce que vous remplissez simplement la mécanique pour faire fonctionner une conception existante, il n'y a rien d'agile requis et Scrum remplit le rôle de suivi de gestion.

C'est pourquoi cela vous fait du mal, vous n'avez en fait pas besoin de Scrum ni n'en bénéficiez en aucune façon parce que vous êtes dans un groupe de service et que votre travail continue avec les personnes UX qui ont déjà fait les parties agiles / Scrum.

Rien de vraiment mauvais là-bas, juste un processus différent est en place que ce qu'on vous a dit.

Patrick Hughes
la source