« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 24 : | Ligne 24 : | ||
* '''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.) | * '''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 :''' 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.) | * '''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 :''' | * '''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/> | ||
<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/> | ||
=== Antipatterns de planification du sprint par le Product Owner === | === Antipatterns de planification du sprint par le Product Owner === | ||
