L'acceptation « à mi-sprint » est-elle un concept valable en Agile/SCRUM ?[fermé]
https://stackoverflow.com//questions/9638514
-
10-12-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je fais partie d'une équipe Agile Scrum travaillant sur une version d'un produit logiciel.La durée du sprint est de 2 semaines (~10 jours).
Il existe une métrique particulière utilisée ici, appelée «acceptation à mi-sprint'.Essentiellement, on s’attend à ce que la moitié des points de la user story engagés et planifiés par une équipe Scrum dans un sprint doivent être complétés au milieu de ce sprint.Ceci, disent-ils, se traduit par une répartition linéaire des points, ce qui est un indicateur fort du bon déroulement du sprint.
En tant qu'équipe, nos acceptations à mi-sprint sont généralement mauvaises, mais nous sommes connus pour avoir terminé tous les points de la user story engagés avant la fin du sprint.
J'ai les questions suivantes:
1) L'acceptation à mi-sprint est-elle une pratique Agile/SCRUM valide ?Est-il utilisé ailleurs ?
2) S'attendre à ce que la moitié du travail soit réalisé en deux fois moins de temps équivaut à le traiter comme un travail « en usine », où la nature et la complexité du travail à accomplir sont complètement déterministes.Étant donné que le développement de logiciels est un processus « créatif », des mesures aussi rigides dans une méthodologie très flexible telle qu'Agile ne sont pas pertinentes.Qu'en penses-tu?
3) Bien que mon équipe Scrum remplisse tous nos engagements juste à temps pour le sprint, nous sommes interrogés sur nos mauvaises mesures d'acceptation à mi-sprint.Est-il tout à fait normal que les équipes Scrum partout ailleurs ne respectent leurs engagements que vers la fin de leurs sprints ?
Merci beaucoup d'avance.
La solution
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Je n'ai jamais entendu parler d'acceptation à mi-sprint auparavant.Je ne pense pas que ce soit une pratique Agile/Scrum valide. Ce site semble être d'accord "Une fois que l'équipe s'est engagée dans le travail, le Product Owner ne peut pas ajouter plus de travail, modifier le cap à mi-sprint ou microgestion."
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Les mesures rigides ne sont généralement pas une bonne idée à utiliser avec les développeurs pour les raisons que vous mentionnez.Il est également probable que les développeurs seront plus intéressés à obtenir une note de passage dans tout ce qui est mesuré et non à produire un produit de qualité.C'est l'un des oursons de Joel Spolsky - ici, ici et ici
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Une équipe Scrum performante devrait avoir accompli tout ce qu'elle s'est engagée à faire d'ici la fin du sprint.Le burndown chart doit être visible pour guider la progression vers cet objectif et indiquera certainement dans la seconde moitié du sprint si le sprint est susceptible d'être un succès.Dans les sprints réussis auxquels j'ai participé, il est normal de faire des progrès constants vers la réalisation des user stories, mais cela ne peut pas se traduire par la réalisation de la moitié des user stories en moitié moins de temps et je déconseille une métrique de ce type.
Autres conseils
Avez-vous essayé de limiter la quantité de travail que vous avez en cours.Si vous obtenez toute l'équipe pour vous concentrer sur quelques histoires et ne pas vous déplacer jusqu'à ce que ces histoires soient terminées, vous devriez voir que votre brûlure deviendra beaucoup plus linéaire.
Cela pourrait également valoir la peine de regarder la taille des histoires.Personnellement, je n'aime pas voir une histoire qui prend plus de plusieurs jours pour terminer le début à la fin.
Ce n'est pas une pratique scrum.Il pourrait être interprété comme une métrique, mais une mauvaise.En ce qui concerne vos doutes, vous avez raison.
Scrum a un outil parfait pour suivre la progression - la carte de combustion.Pas besoin d'ajouter une étape arbitraire.
Il semble que votre gestion ne comprenne pas le concept de base d'un sprint, ils devraient obtenir des conseils ou suivre une formation de base.S'il est toujours important pour votre gestion, ce qui se fait dans la semaine, essayez de suggérer de couper la longueur de sprint en deux à la fois.
1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?
Oui, c'est.
2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?
Si vous cassez les tâches en très petits, vous pouvez obtenir une bonne métrique d'évolution du travail.Par conséquent, les tâches de conception doivent être complètes en une journée de travail et vous pouvez obtenir une bonne utilisation métrique de brûlure.Si vous avez de longues tâches à longueur imprévisible, la métrique de brûlage est hors de propos, comme vous l'avez dit.
3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?
Le problème n'est pas l'équipe, mais la conception des tâches.Le problème concerne la granularité de la tâche.Votre équipe peut effectuer le travail dans la métrique du temps sprint, mais vous devez maintenant affiner les tâches à 50% d'entre elles être complétées à la métrique de temps à mi-sprint.Casser les tâches dans des tâches plus petites et vous pouvez obtenir le tableau d'épuration (linéaire) souhaité.
C'est une terminologie non standard, mais il y a quelque chose à ce que votre responsable dit.
Un graphique d'épuration extrêmement lourde (c'est-à-dire qui reste élevé pour une grande partie du graphique, puis des queues soudainement à la fin) témoigne d'une pratique où les tâches sont graines grossier - c'est-à-dire La tâche prendra probablement une sprint entière à compléter - et accomplie par des développeurs individuels. Avec ce modèle, toutes les tâches restent incomplètes jusqu'à juste avant la fin du sprint.
Ce n'est vraiment pas la façon dont il est censé travailler: si l'arriéré est en ordre de priorité, pourquoi les problèmes n'ont-ils pas les priorités les plus élevées qui fonctionnent? De plus, cela définit le "numéro de bus" pour chaque tâche très faible, ce qui peut augmenter de manière significative le risque de tâches restant incomplètes à la fin du sprint.
Pour résoudre ce problème, les tâches doivent être décomposées en morceaux beaucoup plus petits. Si vous planifiez le poker et une tâche est estimée à 8 points ou plus, il est probable que la tâche est sous-précisée. Il doit être décomposé. Essayez de le garder à 2s et 3 (ou plus petit!) Si possible. De cette manière, vous pouvez avoir plusieurs développeurs travaillant de manière autonome sur le même objectif global et que votre carte Burndown devrait commencer à être plus lisse et moins risquée, même si le même travail se fait.
L'acceptation moyenne du sprint n'est pas une pratique agile ou cela ne fonctionne pas en réalité.Si vous avez une estimation correcte pour chaque histoire d'utilisateur et tâche (E.g in Rallye), le diagramme de Burndown indique clairement si le travail Sprint est en alignement avec le plan et peut être complété à temps ou non.L'acceptation n'est effectuée qu'à la fin du développement et des tests d'une histoire d'utilisation et non des tâches.
