Scrum: Est-il correct que la conception / UX de la user story se produise dans le même sprint que l'implémentation

9

Je suis actuellement dans un sprint (deux semaines) où le concepteur est chargé de définir les exigences et l'UX d'une user story particulière.

Dans le même sprint, je dois implémenter ce design. Au cours de la planification du sprint, j'ai dû faire une supposition folle quant au temps que prendrait cette histoire d'utilisateur non définie.

Aujourd'hui, j'ai finalement reçu le design. Malheureusement, la conception est incomplète / vague et s'apparente davantage aux exigences d'un client qu'à une conception. Cependant, à partir de cela, je peux encore voir que je n'ai presque pas estimé assez.

Pour aggraver les choses, ce n'est pas la première fois. Lors du dernier sprint, exactement la même chose s'est produite. Je l'ai signalé dans notre rétrospective et le Scrum Master n'avait pas de réponse sur la façon de résoudre ce problème, au lieu de dire "c'est juste du développement pour vous". Ironiquement, il s'énerve si la combustion n'est pas sur la cible ...

Maintenant, je vais devoir demander / travailler avec le designer pour faire son travail. Cela va me retenir car j'ai terminé toutes mes autres tâches.

Donc ma question est

A) ~~Comment gérez-vous les dépendances dans la planification du sprint?~~ EDIT: Est-il correct que la conception / UX de la user story se produise dans le même sprint que l'implémentation

B) comment dois-je maintenant aborder le sprint? Estimer à nouveau la user story actuelle et regarder le burndown se transformer en burn-up et être considéré comme incompétent / improductif? Ou ajoutez une nouvelle tâche au sprint actuel dans le sens de "aider le designer à créer un design adapté"

agile scrum planning

— Allan
source

Il convient de mentionner que votre question dans la ligne d'objet est très différente des questions au bas de votre texte. Serait utile si vous l'avez modifié pour choisir l'un ou l'autre.

— pdr

14

comment gérez-vous les dépendances dans la planification de sprint?

Idéalement, les dépendances non liées au développement sont traitées avant la planification du sprint, de sorte que vous disposez d'une bonne définition de l'élément de backlog pour estimer l'effort par rapport.

Mais, si ce n'était qu'un «développement pour vous» lors du dernier sprint, cela allait probablement être juste un développement pour vous ce sprint, donc vous auriez vraiment dû augmenter votre estimation là-bas, puis sur les tâches à venir qui sont dans un état similaire. Ce n'est pas vindicatif, et ce serait une erreur de le laisser en tant que tel.

Il montre l'incertitude de l'estimation sans un plan relativement solide pour estimer. Cela encouragera peut-être vos responsables à vous assurer qu'un élément de backlog de produit est correctement défini; mais au pire, cela couvrira votre dos. Personne ne se plaint quand un emploi manque de budget.

Cependant, vous ne l'avez pas fait, et maintenant votre question est ...

comment dois-je maintenant aborder le sprint?

Le but de Scrum en tant qu'outil de gestion de projet est d'identifier rapidement les problèmes, ce que vous avez fait. Signalez-le à votre direction, laissez-les décider quoi faire avec le sprint. S'ils essaient de vous blâmer, soyez humble et demandez comment ils vous suggèrent d'aborder des situations similaires à l'avenir, pour éviter le même problème, même si vous ne croyez pas vraiment que c'est juste.

À la fin de la journée, ce sont des problèmes de gestion de projet, et si vous essayez de les résoudre dans votre propre bulle, vous vous préparez à l'échec. Et, lorsque vous le ferez, vous serez en colère parce que cela vous tombera dessus, pas sur les gestionnaires qui n'ont pas résolu le problème lorsque vous leur avez signalé.

— pdr
source

Merci d'avoir répondu. Pour développer, mon Scrum Master veut que nous soyons vraiment agiles afin que nous puissions changer / itérer sur une user story dès qu'elle a été codée. Par conséquent, il n'aime pas trop la documentation / conception initiale et à la place, nous devons coder / planifier au fur et à mesure. Bien sûr, cela m'amène à la situation dans laquelle je me suis trouvé. Le manifeste agile semble cependant soutenir sa position. Alors, est-ce que nous sommes trop agiles pour notre propre bien?

— Allan

À titre d'exemple, l'une de nos histoires d'utilisateurs pourrait être «L'utilisateur veut pouvoir jouer contre un autre joueur humain». Dans notre planification de sprint, je décomposerais probablement cela en quelques tâches telles que: afficher les serveurs, choisir le serveur auquel se connecter, se connecter au serveur. Le concepteur me dirait alors idéalement comment les serveurs sont affichés, quels filtres de liste sont disponibles, ce qui se passe s'il n'y a pas de serveurs, etc. Bien sûr, cette liste de choses n'est disponible pour moi qu'une fois qu'il l'a conçue et dans ce cas se produit dans le même sprint. Cette liste est également sujette à modification / itération pendant le sprint.

— Allan

1

@Allan: Ce que votre scrum master ne parvient pas à comprendre, c'est que si le concepteur doit terminer son travail avant qu'un développeur puisse commencer son travail, c'est une conception initiale. Faire en sorte que cela se produise dans le sprint ne supprime aucun coût de la conception initiale, mais cela le rend moins visible ET rend plus difficile l'estimation de votre développement. Si vous pouvez trouver un moyen d'itérer avec votre designer, c'est génial, faites-le partie du sprint et faites l'effort approprié à une tâche collaborative. Mais à l'avance, c'est OK, tant que c'est honnête et, de préférence, fait avant le sprint.

— pdr

Si c'est typique de vos histoires d'utilisateurs, je dirais que vos histoires sont trop grandes. Compte tenu de votre exemple, je m'attendrais à voir "l'utilisateur peut voir la liste des serveurs", "l'utilisateur peut se connecter au serveur et voir la liste des opposants disponibles" comme des histoires.

— Jules

6

Tout d'abord, il y a une grande différence entre les dépendances entre les histoires / tâches et l'incertitude dans la portée / l'effort d'une histoire / tâche.

Les dépendances sont gérées en donnant à la tâche / histoire dépendante une priorité inférieure à la tâche / histoire dont elle dépend et éventuellement une annotation qu'elle ne peut pas démarrer avant la fin de l'autre tâche / histoire.

L'incertitude devrait être abordée lors de la réunion de planification en clarifiant le travail qui doit être fait sur l'histoire. S'il n'est pas possible de supprimer suffisamment de l'incertitude, l'histoire ne correspond probablement pas à votre "Définition de Prêt" et ne devrait pas être acceptée dans le sprint.
Si, pour une raison quelconque, l'histoire doit vraiment entrer dans le sprint, votre seule option restante est d'ajouter un tampon de risque à l'estimation.

Pour le sprint en cours, si vous ne pouvez pas travailler sur une histoire, signalez-le simplement lors de la prochaine réunion quotidienne et effectuez tout le travail possible pour atteindre l'objectif de sprint global de l'équipe. Vous pouvez également annoter l'histoire comme bloquée et par quoi.
Après le démarrage d'un sprint, il est en principe impossible d'ajouter de nouvelles tâches au sprint.
De plus, si une tâche s'avère être plus de travail que prévu, vous ne modifiez pas l'estimation, mais vous rapportez fidèlement la progression et l'effort restant sur la tâche.

Au final, dans Scrum, c'est l'équipe qui promet de livrer quelque chose. Si cette promesse ne peut pas être faite, alors c'est un échec de toute l'équipe, jamais d'un individu au sein de l'équipe.

— Bart van Ingen Schenau
source

C'était aussi une bonne réponse. Si je pouvais marquer deux réponses comme correctes, je l'aurais fait.

— Allan

3

Lors de la planification du sprint, j'ai dû deviner combien de temps durerait cette histoire d'utilisateur non définie.

C'est l'erreur que vous avez commise. Personne ne peut forcer l'équipe à accepter une tâche dans le sprint et il est de votre devoir de déclarer que la tâche ne peut pas être estimée et acceptée dans le sprint à moins qu'il n'y ait au moins une image filaire (par exemple). Il semble que votre scrum master soit en fait un chef de projet, ce qui ne fait qu'empirer les choses.

Comment aborder une telle tâche s'il est nécessaire de l'accomplir dans le sprint (pour des raisons commerciales valables)? Eh bien, vous devez d'abord définir la date limite pour la conception, après quoi vous ne pourrez pas la mettre en œuvre. Par exemple: l'histoire est acceptée, mais la conception doit être livrée dans la première semaine et mise en œuvre dans la seconde. Ensuite, vous devez travailler en étroite collaboration avec le concepteur pour vous assurer qu'il sera possible de l'implémenter dans le sprint. Scrum suppose une équipe interfonctionnelle et c'est à vous d'organiser votre travail avec le designer. Cela dit, si vous acceptez la tâche dans le sprint - qui appartient à l'équipe de décider - c'est à l'équipe de gérer le travail de manière à ce qu'il soit terminé dans le sprint, et de gérer les risques associés. Vous ne devez pas attendre qu'un autre termine son travail pour faire votre travail. Il est possible que vous soyez sur le point de révéler un dysfonctionnement plus important dans votre organisation.

— Maxim Krizhanovsky
source

Merci Darhazer. Oui, le Scrum Master est également le chef de projet. Le Scrum Master a déclaré qu'il devait y avoir une planification et une documentation minimales. Au lieu de cela, nous devons construire des fonctionnalités au fur et à mesure, avec des révisions continuelles pendant le sprint pour itérer / changer ce qui a été construit tel que déterminé par le gestionnaire de projet (d'où la conception et l'implémentation se produisant dans le même sprint). Étant venu d'un rôle où la conception était assez solide à l'avant, j'ai du mal à m'adapter à cette culture du code par le fil.

— Allan

3

"... Scrum Master est également le chef de projet." - pas bon. "... planification et documentation minimales ..." - qu'y a-t-il exactement dans vos définitions de prêt et / ou terminé? "... revues pendant le sprint pour itérer / changer ce qui a été construit comme déterminé par le responsable du projet ..." - cela devrait être la décision de l'équipe, pas le scrum master, certainement pas le chef de projet et (si cela DOIT être quelqu'un ) ce devrait être le propriétaire du produit!

— Phill W.

@PhillW. Nous n'avons pas de définition de prêt. Nous avons juste un backlog avec différents états de détail pour une fonctionnalité. Le détail s'épanouit au fur et à mesure. C'est officiellement lorsque les parties prenantes signent mais c'est vraiment pour les jalons et c'est le manager / scrum master / producteur (la même personne) qui dit quand c'est fait. Je fais maintenant de la "mêlée" depuis un an, peu de temps après le début, j'ai fait un peu d'auto-étude sur la mêlée, car je sentais que notre façon de procéder était étrange. Plus je lis, plus j'ai l'impression que nous faisons de la mêlée "Cargo culte". Mais la politique rend difficile pour moi de faire quoi que ce soit à ce sujet ...

— Allan

1

Les tâches de conception sont-elles exprimées sous forme d'histoires et quelles sont les définitions de

une histoire est prête
une histoire est faite

Chaque histoire doit avoir ses propres exigences et conditions d'acceptation, mais je pense que c'est une bonne pratique d'avoir un ensemble de règles applicables à toutes les histoires. Par exemple, une histoire est prête si (et seulement si!): Les études d'architecture de bout en bout sont terminées, la conception est disponible, l'histoire a été estimée par l'équipe. Les conditions minimales d'acceptation pourraient être: le test automatisé est fait, OK et a été intégré à la combinaison de tests, la révision du code est effectuée.

Si une histoire n'est pas prête, ne l'intégrez pas dans votre sprint. Si les conditions d'acceptation ne sont pas remplies, ce n'est pas fini.

Dans votre cas, l'équipe pourrait décider que pour être prête, une histoire de développement doit avoir une conception complète (au moins un filaire, ajustez cela à votre propre réalité). Si c'est le cas, vous ne pouvez pas gérer la conception et le développement dans le même sprint. L'équipe pourrait également décider qu'une histoire UX / design devrait au moins produire une conception filaire. Si ce n'est pas le cas, alors l'histoire n'est pas acceptée et donc les histoires qui en dépendent ne peuvent pas commencer.

Vous devriez facilement convaincre vos managers qu'avoir des règles solides pour le prêt est une bonne chose: réévaluer la complexité pendant le sprint est une mauvaise pratique. Cela signifie que la vitesse de l'équipe est incertaine et que, en tant que managers, ils ont une mauvaise vision du travail de l'équipe et de l'avenir.

— Keufran
source

0

Un Sprint démarre généralement lorsque l'histoire est claire - à ce stade, le Backlog produit est établi et hiérarchisé. Si vous avez commencé sans avoir la conception, il aurait dû être clair ce qui peut être fait sans la conception et ce qui ne l'est pas ...

Si vous devez improviser pendant que le design «oscille» entre le client et le bon de commande, votre bon de commande doit informer l'équipe de toutes les nouvelles fonctionnalités dès qu'elles apparaissent: c'est le sens de la «flexibilité» dans Scrum - adaptez-vous au cours situation. L'équipe de développement, le Scrum Master et le Product Owner doivent communiquer en permanence, sinon il n'y a pas de réaction en temps réel au changement.

Une formation supplémentaire ne peut pas nuire ... Peut-être que travailler avec le designer serait une opportunité pour vous d'acquérir de nouvelles compétences UX? ... c'est observer le verre à moitié plein au lieu d'être à moitié vide :))

— ScrumMasterChangeFacilitator
source