« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 21 : | Ligne 21 : | ||
Il existe trois catégories d'antipatterns de planification de sprint. Ils concernent l'équipe de développement, le Product Owner et l'équipe scrum : | Il existe trois catégories d'antipatterns de planification de sprint. Ils concernent l'équipe de développement, le Product Owner et l'équipe scrum : | ||
=== Antipatterns de planification du sprint par l'équipe de développement === | === Antipatterns de planification du sprint par l'équipe de développement === | ||
* '''Des absents ?''' | * '''Des absents ?''' les membres de l'équipe ne déterminent pas leur disponibilité au début de la planification du sprint. (Bonne chance pour faire une prévision dans cette situation.) | ||
* '''Capacité ?''' | * '''Capacité ?''' l'équipe de développement surestime sa capacité et prend trop d'éléments. (L’équipe de développement devrait au contraire prendre en compte tout ce qui pourrait affecter sa capacité à livrer. La liste de ces problèmes est longue : jours fériés, nouveaux membres de l’équipe, congés annuels, membres qui quittent l’équipe, membres de l’équipe en congé maladie, les coûts indirects de l'entreprise, les cérémonies Scrum et tout autre réunion, pour n'en nommer que quelques-unes.) | ||
* '''Ignorer la dette technique :''' | * '''Ignorer la dette technique :''' l’équipe de développement n’exige pas une capacité suffisante pour traiter la dette technique et les bugs lors du sprint. (En règle générale, 25% des ressources sont affectées lors de chaque sprint à corriger les bugs et à refactoriser le code source. Si le Product Owner ignore cette pratique et que l'équipe de développement accepte cette infraction, l'équipe Scrum se retrouvera dans une spirale infernale. Sa capacité future à livrer le produit diminuera.) | ||
* '''Pas de mou :''' l'équipe de développement n'exige pas 20% de temps mou de la part du Product Owner. (Si la capacité d’une équipe est toujours surexploitée, sa performance diminuera avec le temps. C’est en particulier le cas dans une organisation dont les activités quotidiennes sont instables. En conséquence, chacun s’efforcera de s’acquitter de ses tâches. Le temps nécessaire pour soutenir les coéquipiers ou pour binômer. L’équipe ne traitera plus ponctuellement les plus petits problèmes ou les problèmes urgents. Chaque membre de l’équipe deviendra un goulot d’étranglement, ce qui pourrait sérieusement bloquer le flux au sein de l’équipe. Enfin, l’attitude "Je suis occupé" réduira l'émergence d'une compréhension partagée parmi les membres de l'équipe. Une surutilisation poussera toujours chaque membre de l’équipe à se concentrer sur sa production propre. Alors que le temps de mou permettra à l’équipe Scrum d’agir en collaboration et de se concentrer sur les résultats.)<br/> | * '''Pas de mou :''' l'équipe de développement n'exige pas 20% de temps mou de la part du Product Owner. (Si la capacité d’une équipe est toujours surexploitée, sa performance diminuera avec le temps. C’est en particulier le cas dans une organisation dont les activités quotidiennes sont instables. En conséquence, chacun s’efforcera de s’acquitter de ses tâches. Le temps nécessaire pour soutenir les coéquipiers ou pour binômer. L’équipe ne traitera plus ponctuellement les plus petits problèmes ou les problèmes urgents. Chaque membre de l’équipe deviendra un goulot d’étranglement, ce qui pourrait sérieusement bloquer le flux au sein de l’équipe. Enfin, l’attitude "Je suis occupé" réduira l'émergence d'une compréhension partagée parmi les membres de l'équipe. Une surutilisation poussera toujours chaque membre de l’équipe à se concentrer sur sa production propre. Alors que le temps de mou permettra à l’équipe Scrum d’agir en collaboration et de se concentrer sur les résultats.)<br/> | ||
[[Fichier:Scrum-19-Sprint-Planning-Anti-Patterns-Slack-Time-Overutilization-1650 fr.png|border|1000px]]<br/> | [[Fichier:Scrum-19-Sprint-Planning-Anti-Patterns-Slack-Time-Overutilization-1650 fr.png|border|1000px]]<br/> | ||
<br/> | |||
* '''Planification trop détaillée :''' lors de la planification du sprint II, l’équipe de développement planifie à l'avance chaque tâche du sprint à venir. (Ne devenez pas trop fin. Deux tiers des tâches c'est plus que suffisant, le reste suivra naturellement pendant le sprint. Faire trop de planification en amont pourrait engendrer du gaspillage.) | |||
* '''Trop d'estimation :''' l'équipe de développement estime les tâches. (Cela ressemble à de la comptabilité pour moi. Ne perdez pas votre temps là-dessus.) | |||
* '''Planification insuffisante :''' l'équipe de développement ignore la planification du sprint II. (Il est regrettable de sauter la planification du sprint II, car c’est le bon moment pour parler de la manière de diffuser les connaissances au sein de l’équipe de développement. Par exemple, l’équipe pensera à qui binômera avec qui et sur quel élément fonctionnel. La planification du sprint II est également bien adaptée pour examiner la façon de réduire la dette technique.) | |||
=== Antipatterns de planification du sprint par le Product Owner === | === Antipatterns de planification du sprint par le Product Owner === | ||
=== Antipatterns de planification du sprint par l'équipe Scrum === | === Antipatterns de planification du sprint par l'équipe Scrum === | ||
== Conclusion == | == Conclusion == | ||
