Question:
Le propriétaire du produit demande de nouvelles fonctionnalités alors que le sprint a commencé
Rafael
2016-05-13 16:21:49 UTC
view on stackexchange narkive permalink

Je travaille actuellement sur le projet X et mon propriétaire de produit continue de pousser de nouvelles fonctionnalités dans le backlog de sprint qui doit être complété dans ce sprint.

Transférer de nouvelles fonctionnalités dans le backlog n'est pas le problème, le problème réside dans le fait qu'il souhaite que moi et les autres développeurs les complétions immédiatement.

La façon dont notre PO le gère n'est pas du tout professionnelle, car nous discutons de l'importance des user stories actuelles dans la réunion de sprint pour le sprint à venir.

Comment puis-je adresser cela à mon PO de manière professionnelle?

Vous savez que l'ajout de fonctionnalités à un sprint en cours d'exécution est contraire au concept de mêlée, n'est-ce pas?
Y a-t-il un Scrum Master dans le lieu qui peut lui expliquer qu'un sprint est une unité de travail non modifiable une fois qu'il est démarré? Si l'entreprise ou l'équipe a accepté de faire Scrum, alors ce n'est pas Scrum et vous devez en parler en équipe.
@AlexandreVaillancourt et si vous découvrez une faille de sécurité massive dans votre produit le premier jour du sprint? Que faire si vous trouvez une bibliothèque open source qui possède les fonctionnalités sur lesquelles vous prévoyez de travailler? Et si le client dont vous écrivez le code fait faillite? "Le sprint ne peut jamais être changé" n'est pas une idée réalisable. Il s'agit de savoir si ces nouvelles fonctionnalités demandées sont suffisamment importantes pour modifier les plans de travail, et si oui, comment cela est fait.
Bonnes infos pour vous aider ici: http://programmers.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprint
@dan1111 Une faille de sécurité n'est pas une fonctionnalité. C'est un bug.
@dan1111 Vous avez parfaitement raison, et d'après les nombreuses choses que j'ai lues à ce sujet, si le sprint a besoin d'un changement de portée, il est terminé et un nouveau sprint est lancé pour résoudre les problèmes urgents. Cependant, je sens de l'OP que les problèmes soulevés par le PO sont plus triviaux que cela et qu'ils pourraient attendre le prochain sprint.
@dan1111 Le fait est que ce n'est pas la question posée
@Paparazzi corrigeant une faille de sécurité peut impliquer l'ajout d'une nouvelle fonctionnalité. Mais en tout cas je répondais au commentaire d'Alexandre selon lequel les sprints ne peuvent pas être modifiés.
Pertinentes: http://workplace.stackexchange.com/questions/66681/boss-wants-my-team-to-work-weekends/66686#66686
@AlexandreVaillancourt - Non, voir ma réponse ci-dessous. Le Manifeste SE FÉLICITE des changements, quiconque vous a dit le contraire était un vendeur d'huile de serpent et ne connaissait pas Scrum. C'est l'erreur la plus courante dans SCRUM aujourd'hui.
@TheWanderingDevManager Hmm, à droite; c'est confu; selon le [Guide Scrum] (http://www.scrumguides.org/scrum-guide.html): "Pendant le Sprint: Aucun changement n'est apporté qui mettrait en danger l'objectif du Sprint; la portée peut être clarifiée et renégociée entre le Product Owner et l'équipe de développement au fur et à mesure que l'on apprend. " C'est un peu contradictoire à première vue, mais oui, il semble que tant que les modifications apportées au backlog de sprint restent concentrées sur l'objectif de sprint, il ne devrait pas y avoir de problèmes, tant que l'équipe a le temps de le faire. dans le sprint. Je devrais relire ce document: P
@AlexandreVaillancourt - Exactement! Vous n'autorisez pas les changements arbitraires, mais être capable de réagir aux choses qui doivent changer fait partie de l'Agilité. Dire que nous ne pouvons pas faire quelque chose de différent de ce que nous avons prévu est de retour à Waterfall, et tant de coachs Agile / Scrum ne comprennent pas cela, ils voient "Aucun changement n'est effectué" et leurs yeux se glacent après cela.
@TheWanderingDevManager Merci pour la pointe! Cela améliorera mon Scrum-fu!
@AlexandreVaillancourt - Heureux de vous aider!
Espérons qu'au cours des ~ 2 dernières années, vous en avez appris davantage sur le cadre grâce au document faisant autorité, [The Scrum Guide] (https://scrumguides.org), voyez les inexactitudes dans les réponses et disposez de meilleures informations pour résoudre les problèmes.
Sept réponses:
#1
+57
The Wandering Dev Manager
2016-05-13 16:44:43 UTC
view on stackexchange narkive permalink

Le Manifeste Agile accueille en effet les changements tardifs, voir le point 4:

Répondre au changement en suivant un plan

Et le guide Scrum a ceci :

Pendant le Sprint:

Aucune modification n'est apportée qui mettrait en danger l'objectif du Sprint ;

Les objectifs de qualité pas diminuer; et,

La portée peut être clarifiée et renégociée entre le Product Owner et l'équipe de développement au fur et à mesure que nous en apprendrons plus .

La chose pour c'est que votre équipe a une vélocité et que vous avez accepté des histoires dans le sprint en fonction de cela.

Ce que vous devez maintenant faire est que le bon de commande définisse la priorité dans le backlog de cette histoire. S'il se trouve au-dessus d'une histoire (ou d'histoires) en cours, vous l'estimez et déplacez les histoires les plus basses jusqu'à ce que vous équilibriez votre vitesse. Si l'histoire est en dessous de quoi que ce soit dans le sprint actuel, alors par définition, elle est moins importante et devra donc attendre. Si l'histoire est à la fin du sprint et qu'il n'y a pas assez de temps pour le faire, démarrez-la et passez au sprint suivant.

C'est (intentionnellement) aussi simple, soit c'est plus important et vous donnez la priorité au travail existant, ou ce n'est pas le cas. Si le bon de commande le souhaite également, rappelez-lui que la vélocité est une métrique de ce que vous pouvez faire, et non un objectif , si elle souhaite la charger, elle le peut, mais vous n'y arriverez pas.

Une autre chose est de convenir d'un objectif de sprint avec le bon de commande / l'entreprise conformément au guide. Si quelque chose arrive, vous le comparez également à cela (cette histoire nous aide-t-elle à atteindre l'objectif?), Sinon, elle nécessite un appel prioritaire sur le travail que vous faites. Donc, un bug urgent peut être prioritaire, mais quelque chose d'autre est rétrogradé car cela ne fait pas partie de l'objectif, ou peut-être que vous abandonnez le Sprint pour le travail plus prioritaire.

D'accord. De plus, si le propriétaire du produit change fréquemment de priorités inutiles, insister sur ce processus (et une réunion pour effectuer les changements) à chaque fois les aide à voir comment les changements de priorités perturbent les plans.
Je dirais que si cela se produit tout le temps, si vous avez normalement 300 heures-personnes par sprint, peut-être n'attribuer que 250 personnes-heures par sprint, les 50 dernières étant dédiées aux «travaux urgents». Peut-être que les 50 derniers sont mis de côté avec des choses que vous voudrez peut-être faire ce sprint, mais vous pouvez reporter si nécessaire. Ensuite, si votre PDG vient avec des demandes, vous savez à l'avance ce que vous réduisez.
+1 pour "quelque chose d'autre est rétrogradé car il ne fait pas partie de l'objectif". Au risque de répéter ce que JeffO a dit. Tout a un prix. Toute nouvelle fonctionnalité a un prix. Ne laissez pas votre Product Owner s'en tirer en ajoutant des éléments à la pile sans rééquilibrer la feuille de calcul des priorités et sans couper les choses ailleurs.
@corsiKa: Mais cela permet simplement à ceux qui veulent contourner le système. Combien de temps avant que les 50 heures ne leur suffisent plus? Dans quelques mois, je peux presque garantir que vous ne ferez plus de mêlée.
@Lightness Et alors? Scrum n'est pas un objectif. Et ce n'est certainement pas un Saint Graal. Si cela ne fonctionne pas pour votre situation de travail, tenez-vous-en aux pièces qui fonctionnent et passez à autre chose. N'oubliez pas que l'objectif est de produire un bon profit.
@Bernhard: Bien sûr, mais lorsque votre situation de travail fait tout ce qu'elle peut pour utiliser le pire système de gestion possible, malgré des efforts massifs pour le redresser, ce n'est pas quelque chose que vous devriez accepter aveuglément. «Être stupide» n'est pas une «situation de travail» valable.
#2
+7
maurocam
2016-05-13 23:27:22 UTC
view on stackexchange narkive permalink

Je suis d'accord avec toutes les déclarations ci-dessus sur l'Agile permettant la flexibilité et le changement.

Mais (très gros mais!) J'ai travaillé avec des OP qui combattent souvent les incendies tout au long du sprint Scrum. Si cela se produit, cela peut être très distrayant et / ou démoralisant pour l'équipe de devoir constamment s'adapter à ces changements. Ce changement continu de priorités peut également affecter sérieusement les versions, et en conséquence il aura un effet négatif sur le retour sur investissement!

Dans ces cas, j'ai fait partie d'équipes où la décision a été prise d'abandonner Scrum et expérimentez avec Kanban. Ce dernier offre une flexibilité dans la définition des exigences bien plus que Scrum. Kanban est également plus adapté à la livraison continue que aux versions régulières.

Pour plus d'informations, à partir de deux perspectives, consultez ces liens:

https: // www. scrumalliance.org/community/articles/2014/july/scrum-vs-kanban

http://kanbantool.com/kanban-library/scrum-and-kanban/kanban -vs-scrum-how-to-use-the-most-of-both

Enfin, en prenant une citation de la dernière référence

.. .ne jamais arrêter la rétrospective, afin de tirer les leçons de votre expérience et de continuer à expérimenter, car vous ne savez jamais quelle solution possible pourrait s'avérer la meilleure pour vous.

J'ai également été dans la situation de passer d'un Scrum (où les sprints étaient constamment manipulés à mi-sprint) à Kanban et cela fonctionnait beaucoup mieux pour cette équipe et cette entreprise.
#3
+5
Jonathan Vanasco
2016-05-14 03:48:38 UTC
view on stackexchange narkive permalink

En tant que personne qui a été à la fois CTO et Head of Product dans différentes organisations, je suis largement d'accord avec @The Wandering Dev Manager mais je voulais ajouter plus qu'un commentaire ne le permettrait.

Cela ne devrait pas se passe comme décrit. Je vois beaucoup de signaux d'alarme dans la fréquence et l'immédiateté des demandes. Je suggère d'avoir une discussion honnête avec le Product Owner sur son processus actuel et comment il affecte votre travail. Je commencerais aussi à chercher un autre emploi, car la situation ne s’améliorera peut-être pas.

Si le Product Owner est simplement mauvais dans son travail, c'est vraiment bien - il peut s'améliorer ou être remplacé. Malheureusement, de nombreuses situations comme celle-ci existent parce que le Product Owner est en fait assez bon dans ce qu'il fait, mais a été contraint de suivre certains schémas en raison de la pression d'en haut. Tout le monde ne peut pas inviter son PDG à les renvoyer à chaque bataille. Lorsque c'est le cas, la situation ne s'améliorera pas.

Dans l'ensemble, les changements pendant un sprint sont bien - mais vous devez vous y préparer. Je m'assure toujours que mes équipes produit et technique remplissent les sprints avec suffisamment de points pour gérer les «correctifs» et les bogues. Lorsque je dirigeais un produit dans une entreprise de médias, mes équipes savaient qu'il fallait réserver un certain nombre de points à chaque sprint - quelque chose revenait toujours, car c'était la nature de notre entreprise. Notre système fonctionnait, car nous pouvions toujours planifier une sorte d'événement. Si un événement prévu d'une manière ou d'une autre ne se produisait pas, alors le temps restant pourrait être utilisé pour des projets personnels, des tâches ménagères ou [gasp!] Pour avancer. La gestion des fonctionnalités / modifications de dernière minute était toujours à la discrétion du chef de produit, et en consultation avec le chef de projet et le directeur technique de cette équipe. Nous nous sommes toujours assurés que le moral de l'équipe était également un facteur. Rien n'a jamais été promis aux unités commerciales autre qu'une "meilleure tentative de livraison".

Parfois, une très mauvaise décision commerciale est prise - et personne ne s'en rend compte tant que le sprint n'a pas commencé. Cela s'est souvent produit avec les startups que je conseille. Gérer ce type de situation est assez simple - vous avez une réunion à tous les participants pour re-pointer, redéfinir les priorités et reprogrammer. Le sprint est interrompu; vous partez de zéro.

Les parties prenantes de votre entreprise peuvent ne pas comprendre qu'une planification appropriée est nécessaire pour de nombreuses raisons. Il minimise les frais administratifs, il permet de construire des systèmes interconnectés de manière plus efficace, il permet de prévoir et de planifier la façon dont une solution est conçue ... Il y a une longue liste de raisons, mais il n'y a que 2 principaux points à retenir. les parties prenantes et les propriétaires de produits doivent comprendre:

  • Vous perdez plus de temps et d'argent avec des changements et des demandes immédiats. Cette méthode est toujours la moins efficace.
  • Vous blessez le moral de l'équipe et la satisfaction professionnelle des employés avec ce flux de travail. Vos développeurs deviendront stressés, en colère et finiront par partir.

Lorsque le client est une organisation interne, cela signifie que les chefs de service doivent discuter. Si le client est un client externe, l'entreprise doit décider si la relation commerciale est réparable ou même justifiée.

#4
+1
Martin York
2016-05-13 20:38:03 UTC
view on stackexchange narkive permalink

En théorie, je suis d'accord avec @The Wandering Dev Manager mais je pense qu'il / elle rend potentiellement trop facile pour le PO de changer le sprint.

C'est le travail du PO de résister au changement au sprint (ne pas l'empêcher) d'entités externes (clients). À moins qu'il n'y ait une situation critique, le sprint doit être considéré comme immuable.

De plus, le cycle de sprint est censé être court afin que tout ce qui arrive puisse être priorisé dans le prochain sprint sans affecter le client . Si vous avez des sprints de plusieurs mois, vous n'êtes pas vraiment agile. L'objectif est une rotation rapide avec quelques changements visibles (2-4 semaines).

Mais un sprint peut changer. Si c'est le cas, le coût des nouveaux éléments Doit être calculé et une quantité de travail équivalente supprimée du sprint pour compenser.

Alors, que devez-vous faire à ce sujet? Eh bien cela dépend. C'est le travail de PO de maintenir le sprint est-ce qu'il le fait? Abandonne-t-il un travail approprié pour compenser? Sinon, "The Scrum Master" devrait avoir un mot avec le PO.

C'est Lui, et je ne suis pas d'accord avec vous. Le travail du PO est de maximiser le retour sur investissement du produit, si cela signifie changer, cela signifie changer, même si le sprint doit être abandonné. Le sprint n'est jamais immuable, vous voudrez peut-être en discuter, mais ne pas accepter de changement valide est un anti-modèle Agile, tracé par les `` coachs agiles '' du monde entier.
D'ailleurs, le travail du PO est de maximiser le retour sur investissement du produit même si cela signifie ne pas utiliser du tout de sprints, ou ne pas faire du tout d'agilité. Si le processus ne convient pas à l'entreprise, le processus perd. Un sprint n'est qu'un nom pour une collection de travaux que vous prévoyez pour un bloc de temps particulier. Si ce n'est pas ce que vous faites, parce que cela ne convient pas à l'entreprise, n'appelez pas cela un sprint.
Oui et non. Un changement constant entraîne une perte de productivité. Si cela se produit plus qu'occasionnellement, il bombarde la vitesse. J'ai vu que lors de mon dernier gros client où le PO accordait la priorité au backlog 3 fois par semaine - le résultat n'a jamais été fait. Vous commencez sur quelque chose, puis le boxez encore et encore.
@TheWanderingDevManager: Churn en modifiant le sprint réduira le retour sur investissement dans le cas général. C'est le travail du PO de discuter avec le client et de s'assurer que le changement est la meilleure option (pas seulement changer à cause des changements). Ainsi, ils devraient résister (en conseil qui est généralement mauvais) mais devraient faciliter si c'est la meilleure option. Ils doivent également rappeler au client que le sprint est court pour une raison que vous n'avez pas besoin de changer souvent.
@TheWanderingDevManager: Je pense que nous sommes d'accord sur ce qu'il faut faire. Je veux juste souligner que pour obtenir le meilleur retour sur investissement, cela ne signifie pas accepter ce que le client veut simplement parce qu'il est le client. Là, Job n'est pas d'agir comme l'homme du oui pour le changement de sprint, mais d'agir comme le point de raison et de s'assurer que le client est prêt à payer le coût d'un changement au milieu d'un sprint et d'essayer d'empêcher l'équipe d'être randomisée. par des changements. Mais si le sprint doit changer, ils en sont responsables et doivent faire le changement correctement.
Je pense que le mot «résister» (mais pas «empêcher») dans cette réponse est un bon mot. Changer de cap lorsque vous avez planifié votre sprint nuira à la productivité - mais le but du sprint et de l'équipe de développement est de _supporter l'entreprise_, pas de produire un modèle de la façon dont le développement agile est censé fonctionner. Si quelque chose d'inattendu doit être fait, alors il doit être fait.
#5
  0
gnasher729
2016-05-14 02:37:20 UTC
view on stackexchange narkive permalink

Voici ce que votre bon de commande provoque:

J'ai fait l'une des tâches du sprint. J'ai apporté des modifications à ma base de code locale. Je n'ai pas tout à fait fini. Une fois que j'ai terminé et que je suis convaincu que tout est à la hauteur, cela passe à une révision du code, il passe par le contrôle qualité, puis il est intégré dans le code de développement partagé. S'il faut beaucoup de temps entre le début de la tâche et la préparation, il y aura des changements dans le code de développement partagé qui entreront en conflit avec mon travail, ce qui créera du travail supplémentaire et des risques.

Votre PO, s'il obtient ce qu'il veut, me ferait interrompre mon travail et continuer sur autre chose. Quelque temps plus tard, je reviens à la première tâche. À ce moment-là, j'en ai oublié la moitié, il me faut donc du temps pour recommencer. Les choses qui étaient dans mon esprit qui devaient être faites sont abandonnées. Baisse de qualité. Au moment où j'ai terminé, il y a beaucoup plus de changements dans le code partagé, beaucoup plus de conflits, plus de temps perdu.

En même temps, cela détruit totalement toute motivation. Commencer une tâche et se faire dire à mi-chemin qu'elle n'est pas souhaitée est totalement démotivant. Et être démotivé n'augmente pas exactement la productivité. Pourquoi devriez-vous faire des efforts dans la tâche suivante alors que vous vous attendez à ce qu'elle soit également tirée?

Je ne serais pas surpris si ce genre de chose, qui se passe régulièrement, réduirait de moitié la productivité d'une équipe . En d'autres termes, le nouveau truc qui a été inséré dans le sprint ne sera pas terminé plus rapidement que si le PO avait été patient, tandis que le truc original est massivement retardé. Au lieu de deux semaines pour les éléments d'origine et de deux semaines pour les nouveaux éléments, il faut une semaine pour démarrer les éléments d'origine, trois semaines pour les nouveaux éléments, deux semaines pour terminer les éléments d'origine. Au lieu de quatre semaines + une équipe heureuse, cela prend six semaines + produit une équipe malheureuse et démotivée.

#6
-1
o.m.
2016-05-13 22:14:59 UTC
view on stackexchange narkive permalink

Ce que fait votre bon de commande peut être entièrement légitime. Je présume que vous êtes dans une entreprise commerciale et que l'argent de vos clients va payer votre salaire. Il y a des moments où vos gens d'affaires disent «OK, changement total de plan» et quand vous devriez l'accepter.

D'un autre côté, il est de votre responsabilité envers les propriétaires de l'entreprise de livrer un produit de qualité à un rythme durable, de ne pas ruiner votre architecture parce que quelqu'un a une nouvelle idée chaque semaine.

  • Si les histoires à haute priorité sont petites et s'intègrent dans le produit, envisagez d'utiliser votre processus de bogue pour elles, même s'il s'agit de nouvelles histoires. (Je suppose que vous avez un processus défini pour obtenir des correctifs dans le sprint actuel.)
  • S'il y a des changements majeurs dans la priorité, suggérez au PO de abandonner le sprint actuel . Remettez toutes les histoires inachevées dans l'arriéré. Rappelez au bon de commande que tout travail que vous avez déjà effectué sur des articles inachevés peut être gaspillé si vous ne pouvez pas redémarrer le travail et fusionner bientôt.
Je ne suis pas d'accord avec la première puce. Agiter plus de choses dans un sprint même si petit nécessite une marge de manœuvre. Soit a) il y a des points de sprint non dépensés (mauvais) b) déposer une histoire pour l'adapter aux nouveaux (adéquat) c) surcharger le sprint (mauvais). d) Mettez-le de côté pour le nouveau sprint (recommandé, mais pas toujours possible compte tenu de l'agenda du PO) ... N'utilisez jamais de processus de correctif / bug pour les nouvelles fonctionnalités.
L'annulation d'un sprint est également vraiment très mauvaise.
@Mindwin, nous réservons toujours du temps pour examiner les nouveaux bugs, préparer les powerpoints pour expliquer les choses à la direction, faire face à un ou deux jours de maladie, etc.
#7
-1
Paul Sweatte
2018-03-29 12:51:43 UTC
view on stackexchange narkive permalink

Dans des situations comme celle-ci, il est essentiel d'avoir un processus pour s'attendre à l'inattendu. Par exemple, une politique dans laquelle une histoire est échangée contre une autre histoire de la même taille est un bon moyen de maintenir l'équilibre:

Dans le processus Scrum, scope creep se produit lorsque le Product Owner, ou tout autre membre de l'équipe Scrum, apporte du travail supplémentaire (par exemple «plaquage or» ou se faufiler dans la dette technique) dans le sprint sans en discuter avec l'équipe. Toute l'équipe doit toujours négocier le retrait d'une user story du Product Backlog et son intégration dans le Sprint Backlog actuel. Cependant, si l'équipe a terminé tout le travail sur lequel elle s'est engagée dans le sprint actuel et qu'un développeur ne peut en aucun cas aider un autre ou un testeur, elle peut soulever le problème lors de la prochaine réunion quotidienne et demander à apporter de nouveaux

De plus, le partage des commentaires des clients et des mesures au sein de l'équipe permet de clarifier si un changement est nécessaire ou non dans le produit lui-même, la messagerie qui l'entoure ou l'analyse des données . Avoir une feuille de route et y adhérer est essentiel, mais cela ne fonctionne que si tout le monde connaît le plan et les modifications qui y sont apportées sont bidirectionnelles:

Nous pouvons ajouter ou modifier des tâches dans le plan trimestriel, mais cela se traduit par une dérive de la portée et une modification explicite du plan.

Références



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...