Notre équipe de mêlée se compose des rôles de mêlée habituels. Nous n'avons pas de concepteur UI / UX et les développeurs travaillent l'UI / UX avec le propriétaire du produit. Voilà un problème. Chaque fois que nous sommes sur le point de créer le backlog et que nous ne définissons pas la conception UI / UX exacte avant le début du sprint, nous finissons par passer trop de temps pendant le sprint à essayer de finaliser la conception UI / UX.

C'est exactement le cas pour l'analyse et l'architecture des fonctionnalités. Pensez-vous que tous les détails possibles sur une fonctionnalité devraient être donnés aux développeurs avant le début du sprint ou devrait-il être une tâche dans les fonctionnalités? Nous en avons fait l'expérience et il en résulte des fonctionnalités indéfinies qui n'ont aucun critère.

Tout d'abord: jetez un œil à cette belle conférence , a donné Florian Haas au FROSCON (GER). Il s'agit de l'impossibilité pratique de faire de la mêlée.

La bonne nouvelle : comme Scrum est impossible à mettre en œuvre, vous êtes libre de faire ce que vous voulez.

La mauvaise nouvelle : n'appelle pas ça mêlée.

Cela vous libère de la question: «Est-ce que je fais de la mêlée à droite?» (Réponse: non, vous ne le faites pas ) et vous pourriez passer aux questions pratiques de la vie, d'ailleurs.

Nous n'avons pas de concepteur UI / UX et les développeurs travaillent l'UI / UX avec le propriétaire du produit

Cette situation n'est pas rare. Mais AFAIR Scrum est contre la spécialisation: tout le monde devrait avoir les mêmes compétences et travailler de manière interchangeable.

Chaque fois que nous sommes sur le point de créer le backlog et que nous ne définissons pas la conception UI / UX exacte avant le début du printemps, nous finissons par passer trop de temps pendant le sprint à essayer de finaliser la conception UI / UX.

Oui, j'ai maintenant cette situation trop bonne. J'ai travaillé dans une équipe, où nous avons dû faire face à des backlogitems très larges comme »En tant qu'utilisateur, je veux voir des informations x « et c'est tout. Ensuite, l'article a atterri sur la planche de sprint. Un développeur l'a pris. Résolu. Après sa mise en œuvre, un premier examen par les pairs a eu lieu, où une discussion a commencé sur la façon dont l'interface utilisateur devrait ressembler.

Puis la phase d'AQ est arrivée et la discussion a recommencé.

Après le sprint, nous avons fait comme la mêlée exigeait l' examen où le design a été déchiré par le PO . Malheureusement, notre client n'a pas pu accéder aux commentaires, il n'a donc pas vu le logiciel à ce stade.

Mais le cycle a recommencé jusqu'à ce que PO soit satisfait.

Et puis est venu le client ...

D'après cette histoire de guerre, vous voyez que ce processus (spécial) est terriblement inefficace.

Ce qui a fonctionné pour nous à la fin, c'était de jeter la mêlée par- dessus bord.

Mais ce n'est pas la solution à votre question;)

Pensez-vous que tous les détails possibles sur une fonctionnalité devraient être donnés aux développeurs avant le début du sprint ou devrait-il être une tâche dans les fonctionnalités?

Une solution à ce dilemme impliquerait des boucles de rétroaction étroites entre a) le client lui-même et l' OP , de sorte que les critères soient formulés de manière relativement stricte. b) Une boucle de rétroaction serrée entre l'équipe de mêlée et l' OP pour minimiser les chances de quitter la route.

Je briserais quelques règles de mêlée (plus) pour définir un backlogitem: un «mannequin de travail». Ce qui pourrait être rapidement examiné par le PO et le client pour minimiser le temps de développement consacré à un article simple.

tl; dr

Quel devrait être l'apport d'une équipe de mêlée?

Assez d'informations pour répondre aux spécifications en un minimum de temps.

Hors sujet:

Nous ne faisons plus de mêlée. Nous ne faisons pas d'estimations. Nous avons gardé la planche de sprint. Nous ne faisons pas de sprints. Nous développons des fonctionnalités / corrige des bugs et publions dès que possible. Lorsque de nouvelles fonctionnalités sont mises en œuvre, elles vont dès que possible sur un serveur public où nous pourrions discuter de la conception avec les clients aussi étroitement que possible.

La réponse canonique est «faites ce qui fonctionne pour vous».

Scrum est l'une des méthodologies agiles. Il est explicitement conçu pour évoluer et s'adapter à votre équipe et à votre projet. Votre objectif devrait être:

Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration du client sur la négociation des contrats
Répondre au changement en suivant un plan ( manifeste Agile )

Ce n'est pas une question de ce que votre équipe devrait avoir pour commencer une histoire, c'est une question de savoir quelle contribution permet à votre équipe particulière de résoudre le besoin commercial particulier.

Dans mon expérience personnelle, cela dépend de l'objectif commercial. Certaines histoires viennent déjà avec des recherches UI / UX et des conceptions complètes, et c'est OK. Certaines histoires comportent des exigences vagues, car l'entreprise a juste besoin d'un problème résolu. C'est aussi OK.

Il y a aussi bien sûr d'autres facteurs. Par exemple, si vos concepteurs font partie de l'équipe de développement, du marketing, du développement de produits, etc. De nombreux facteurs. Faites simplement ce qui est nécessaire pour satisfaire l'entreprise, soyez flexible et assurez-vous de discuter de ces choses lors de vos rétrospectives, en ajustant le processus si nécessaire.

J'ai eu une poussée similaire de la part des développeurs. Le problème, de leur point de vue, était qu'ils se méfiaient du temps que la partie UX pourrait mettre en œuvre. S'ils acceptent d'essayer de livrer N histoires dans un sprint mais que certaines histoires prennent beaucoup plus de temps que prévu en raison des allers-retours sur l'UX, alors ils ont senti que cela se reflétait mal sur eux.

Ce qui a fonctionné pour nous, c'est:

1. Quelqu'un travaille avec le propriétaire du produit pour créer des maquettes des écrans à développer. Ceux-ci sont examinés pendant le processus habituel de raffinement de l'histoire avant que l'histoire ne soit tirée dans un sprint qui donne à chacun une chance d'avoir une discussion honnête.
2. N'essayez pas de finaliser la conception avant de coder, sortez-la et discutez de ce qui doit changer. Les coûts de la modification sont alors plus clairs, ce qui aide le propriétaire du produit / client à décider si cela en vaut la peine.
3. Confiance entre le propriétaire du produit / les clients et les développeurs. En fin de compte, tout le monde essaie de livrer des choses au client. Le PO n'est pas autorisé à se plaindre que l'équipe ne livre pas tout d'un sprint. Les développeurs ne peuvent pas être délibérément obstructifs car ils ont peur de ne pas livrer.
4. Entraine toi. Nous avons juste une meilleure estimation de la taille des histoires et la possibilité de repérer les problèmes probables.

Tl; DR: Ne définissez pas complètement l'UX avant de coder. Attendez que les utilisateurs le voient et jouent avec.

Pensez-vous que tous les détails possibles sur une fonctionnalité devraient être donnés aux développeurs avant le début du sprint ou devrait-il être une tâche dans les fonctionnalités?

En termes simples, si le propriétaire du produit n'est pas en mesure de livrer le design ui / ux avant le sprint, le développement de l'ui / ux devrait être une histoire , pas une tâche.

Vos livrables de sprint ne doivent pas toujours être du code de travail, et l'équipe elle-même peut être le «qui» dans l'histoire. Vous pouvez avoir une histoire telle que "En tant que membre de l'équipe de développement, nous avons besoin de maquettes d'interface utilisateur afin de pouvoir implémenter l'interface utilisateur". Vous estimez ensuite combien de temps il faudra à votre équipe pour livrer les maquettes, et cela devient l'une des premières histoires sur lesquelles vous travaillez.

Vous n'avez pas besoin d'énoncer l'interface utilisateur, acceptez simplement la demande fonctionnelle (histoire) et notez-la en sachant que vous devez penser à une interface utilisateur. Demander au client de spécifier l'interface utilisateur pose problème.

Maintenant que vous savez que l'interface utilisateur vous coûtera un peu de temps, vous devriez être en mesure de mieux planifier. La prochaine fois que vous entreprendrez une tâche qui comprend le travail de l'interface utilisateur, vous lui attribuerez des points d'histoire supplémentaires.

Si vous êtes scrum, n'importe qui peut être un designer UI / UX.

L'interface utilisateur / UX ne devrait pas être une réflexion après coup. Ce devrait être un produit livrable. Il doit être approuvé par le propriétaire de votre produit. Il devrait apparaître, même si ce n'est qu'un gif, lors de la livraison.

Cela ne signifie pas que cela ne peut pas changer. C'est quelque chose qui changera souvent. C'est aussi quelque chose sur lequel vous souhaitez obtenir des commentaires au début. Ne laissez pas le code guider la conception de l'interface utilisateur. Laissez le client le conduire. Ne repoussez que lorsque le client demande de la magie. Sinon, informez-les simplement de la quantité de travail qu'ils demandent et du prix à payer.

Le seul UI / UX finalisé est sur un logiciel mort.

De votre commentaire:

"Il doit être approuvé par le propriétaire de votre produit." C'est exactement là que le problème se pose. Il y a énormément de temps consacré à ce processus d'approbation et nous finissons par passer des jours au lieu de quelques heures qui avaient été initialement estimées. - Rashid

Éliminez tout ce qui vous ralentit inutilement.

Tu as une idée. Dites au propriétaire du produit. Ils devraient être assis à côté de vous.

Ils détestent ça? Passez. Aimer? Fais le. Tu ne comprends pas? Montre leur.

De courtes réunions fréquentes et imprévues. Parler. Doodle sur un tableau blanc ou du papier. Maquette dans un programme de peinture à l'aide de captures d'écran. Communiquez, approuvez, mettez en œuvre et passez en revue vos idées rapidement.

Si le propriétaire du produit n'est pas là, prenez un humain commode et demandez-lui. Tout ce qu'il faut pour commencer l'itération. Réintégrer le propriétaire du produit dès que vous le pouvez.

Ne passez pas une seconde à la rendre jolie. Allez droit au but. Gardez vos idées petites et incrémentales et vous pouvez avoir terminé avant que quiconque ne demande même une estimation.

Dans mon expérience:

• Trop peu d'analyses initiales entraînent un développement inefficace, stop-start
• Trop d'analyses initiales provoquent une paralysie de l'analyse (le Sprint ne démarre jamais)

Ce que nous faisons:

• Définir certains critères " Prêt pour le développement "
• Pour les histoires UX, cela pourrait être "nous avons un filaire bien compris par l'équipe"

Pendant la planification de Sprint:

• Toutes les histoires qui ne sont pas prêtes pour le développement sont rejetées (elles perturberaient trop l'équipe et reviendraient pour plus d'analyse)
• Toutes les histoires limites sont déclarées «à haut risque» et entreprises dès le début du sprint
• Des histoires bien comprises sont estimées et autorisées dans le Sprint

Ce système nous permet de consacrer la plupart de chaque Sprint à l'exécution, c'est-à-dire que nous travaillons beaucoup plus efficacement.

Toute tâche dans votre mêlée doit avoir une estimation du travail total impliqué et un résultat vérifiable.

Si je mets une tâche dans votre scrum "implémenter la fonctionnalité X avec une interface utilisateur dont le chef de produit est satisfait", cela a un résultat vérifiable, mais il est clairement impossible d'estimer la quantité de travail impliqué. Cette tâche ne peut donc pas être raisonnablement mise dans une mêlée.

Maintenant, je mets une tâche dans votre scrum "concevoir une interface utilisateur pour la fonctionnalité X". Cela peut être estimé et le résultat est vérifiable. C'est une tâche OK dans une mêlée. Lorsque la tâche est terminée, vous l'avez fait.

Maintenant, une fois la tâche terminée, votre chef de produit peut dire qu'il n'aime pas le résultat. C'est bon. Il y avait une tâche dans la mêlée, vous l'avez fait, et c'est votre travail. Il peut mettre une autre tâche dans la prochaine mêlée. Peut-être avec un peu plus de sens quel type d'interface utilisateur il aimerait réellement. Voilà son travail. Définir des tâches qui donnent des résultats utiles . Parfois, c'est difficile, et un travail est fait qui s'avère inutile. C'est pourquoi ils l'appellent «agile»; des tâches sont effectuées qui s'avèrent inutiles, puis vous changez de direction.

De plus, la conception UX, en particulier une bonne conception UX, est un travail à temps plein pour quelqu'un qui a pratiqué la conception UX. Beaucoup de bons développeurs de logiciels peuvent faire un travail passable en créant un UX, mais ils ne le feront pas aussi bien et aussi rentable qu'un bon concepteur UX (s'ils le pouvaient, alors ils créeraient des conceptions UX et ne développeraient pas de logiciel). Donc, ne pas avoir de concepteur UX est inefficace - encore une fois un problème pour le propriétaire du produit.

Je ne suis pas sûr que vous suiviez des principes agiles, mais voici comment cela devrait être géré.

nous ne définissons pas la conception exacte de l'interface utilisateur / UX avant le début du sprint

Le but n'est pas d'être parfait à ce stade. Obtenez autant d'informations sur les exigences afin que les développeurs puissent créer quelque chose qui corresponde le plus possible à ce qui a été demandé. Ne faites pas un tas de réglages ou n'essayez pas de concevoir des choses qui n'ont pas été demandées. Vous perdrez votre temps.

nous finissons par passer trop de temps pendant le sprint à essayer de finaliser la conception UI / UX.

Travaillez sur un moyen de déterminer quand les choses seront faites. J'ai le sentiment que quelqu'un continue de faire beaucoup d'évaluations dans les deux sens de l'interface utilisateur / UX. Trop de gens ont des opinions sur l'UX / UI sans rien du client pour étayer leurs hypothèses.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Ce genre de chose peut durer éternellement. Ce n'est pas un défaut Scrum. Quelqu'un se mêle des exigences pendant le sprint. Revenez à décider ce que le client veut, déterminez combien de temps cela prendra et travaillez avec lui pour établir des priorités. S'ils pensent que cela prendra trop de temps, demandez-leur de quoi se débarrasser.

Il existe une entreprise qui conçoit des logos pour un montant forfaitaire. Ils limitent le nombre de demandes de modification car ils savent que certains clients les tueront par la mort de mille coupures avec tous leurs changements. Arrêtez-vous ou facturez plus. Ça s'appelle les affaires.