« Faire face aux urgences dans les équipes Agile » : différence entre les versions
De Wiki Agile
Page créée avec « Category: Portail ScrumMaster <div id="content_view" class="wiki" style="display: block"><span style="background-color: #ffffff">Auteur : Serge Beaumont</span><br /> <... » |
|||
| Ligne 20 : | Ligne 20 : | ||
<br /> <div style="text-align: center">[[Image:Scrum-DealingWithIncidents-3.jpeg|Scrum-DealingWithIncidents-3.jpeg]]</div><br /> <span class="s1">"Nous considérons qu'il s'agit d'un très gros problème ! Nous avons besoin de la correction tout de suite !". "Bien sûr, nous allons traiter le problème. Depuis combien de temps ce problème existe-t-il dans le système ? ". "Eh bien, depuis plus d'un an, mais nous venons juste de le découvrir !". "C'est là depuis un an ? ... Et vous ne pouvez pas attendre deux semaines de plus pour la correction ?"</span><br /> <br /> <span class="s1">La solution 2 est une extension de la Solution 1. Il peut être effectivement important de corriger une urgence, mais il y a un critère important dans ce cas : '''c'est une urgence, uniquement si elle doit être corrigée dans le Sprint courant.''' Si vous pouvez reporter le problème au Sprint suivant, ''alors il n'y a pas de problème !'' L'équipe peut l'intégrer à son processus, le planifier, le corriger et le livrer à la fin du Sprint suivant. C'est encore une fois de la responsabilité du Product Owner : en dehors de la décision de rejeter, un bon Product Owner fera en sorte que tout ce qui peut être reporté le soit effectivement.</span><br /> <br /> | <br /> <div style="text-align: center">[[Image:Scrum-DealingWithIncidents-3.jpeg|Scrum-DealingWithIncidents-3.jpeg]]</div><br /> <span class="s1">"Nous considérons qu'il s'agit d'un très gros problème ! Nous avons besoin de la correction tout de suite !". "Bien sûr, nous allons traiter le problème. Depuis combien de temps ce problème existe-t-il dans le système ? ". "Eh bien, depuis plus d'un an, mais nous venons juste de le découvrir !". "C'est là depuis un an ? ... Et vous ne pouvez pas attendre deux semaines de plus pour la correction ?"</span><br /> <br /> <span class="s1">La solution 2 est une extension de la Solution 1. Il peut être effectivement important de corriger une urgence, mais il y a un critère important dans ce cas : '''c'est une urgence, uniquement si elle doit être corrigée dans le Sprint courant.''' Si vous pouvez reporter le problème au Sprint suivant, ''alors il n'y a pas de problème !'' L'équipe peut l'intégrer à son processus, le planifier, le corriger et le livrer à la fin du Sprint suivant. C'est encore une fois de la responsabilité du Product Owner : en dehors de la décision de rejeter, un bon Product Owner fera en sorte que tout ce qui peut être reporté le soit effectivement.</span><br /> <br /> | ||
==<span class="s1">'''Solution 3 : prévoir une provision pour gérer les problèmes inattendus'''</span>== | ==<span class="s1">'''Solution 3 : prévoir une provision pour gérer les problèmes inattendus'''</span>== | ||
<span class="s1">[[Image:Scrum-DealingWithIncidents.jpeg|Scrum-DealingWithIncidents.jpeg]]</span><br /> <br /> <span class="s1">Si vous êtes passé par les Solutions 1 et 2, alors tout ce qui reste devrait être considéré comme de vrais problèmes que vous devez corriger le plus tôt possible. La meilleure manière que je connaisse pour gérer cette situation c'est de '''prévoir une provision de temps ou de points de story non planifiée'''. Cela fonctionne particulièrement bien si l'historique de la charge de travail dédiée à la résolution des problèmes est raisonnablement stable. Vous ne savez pas ce que vous ferez, mais vous savez quel effort il faudra fournir.</span><br /> <br /> <br /> <span class="s1">Mais attention en utilisant une provision, ça peut vous exploser au visage ! Le premier risque est la taille de la provision. Si la provision est un pourcentage important de la capacité du Sprint, disons plus de 1/5ème de votre vélocité, vous vous retrouverez alors avec un grand trou dans votre processus de planification. Appliquez donc la Règle n°1 : ''la provision ne concerne pas les items du backlog''. Essayez de garder une provision qui soit la plus petite possible.</span><br /> <br /> <span class="s1">[[Image:Scrum-DealingWithIncidents-2.jpeg|Scrum-DealingWithIncidents-2.jpeg]]Le deuxième risque, c'est ce que j'ai déjà dit en décrivant la Solution 1 : dès que l'utilisateur voit une solution pour contourner le processus normal, vous pouvez être sûr qu'il va se jeter dessus. Une provision doit vraiment, vraiment être protégée de toute utilisation involontaire. Donc, triez bien !</span><br /> <br /> <span class="s1">Le troisième risque, c'est de dépasser la provision. Ce qui conduit à l'explosion du processus. Si la provision est utilisée, vous aurez besoin de déterminer quelle proportion de la provision a été utilisée, sinon vous allez avoir une drôle de surprise à la fin du Sprint.</span><br /> <br /> | <span class="s1">[[Image:Scrum-DealingWithIncidents.jpeg|Scrum-DealingWithIncidents.jpeg|right]]</span><br /> <br /> <span class="s1">Si vous êtes passé par les Solutions 1 et 2, alors tout ce qui reste devrait être considéré comme de vrais problèmes que vous devez corriger le plus tôt possible. La meilleure manière que je connaisse pour gérer cette situation c'est de '''prévoir une provision de temps ou de points de story non planifiée'''. Cela fonctionne particulièrement bien si l'historique de la charge de travail dédiée à la résolution des problèmes est raisonnablement stable. Vous ne savez pas ce que vous ferez, mais vous savez quel effort il faudra fournir.</span><br /> <br /> <br /> <span class="s1">Mais attention en utilisant une provision, ça peut vous exploser au visage ! Le premier risque est la taille de la provision. Si la provision est un pourcentage important de la capacité du Sprint, disons plus de 1/5ème de votre vélocité, vous vous retrouverez alors avec un grand trou dans votre processus de planification. Appliquez donc la Règle n°1 : ''la provision ne concerne pas les items du backlog''. Essayez de garder une provision qui soit la plus petite possible.</span><br /> <br /> <span class="s1">[[Image:Scrum-DealingWithIncidents-2.jpeg|Scrum-DealingWithIncidents-2.jpeg|right]]Le deuxième risque, c'est ce que j'ai déjà dit en décrivant la Solution 1 : dès que l'utilisateur voit une solution pour contourner le processus normal, vous pouvez être sûr qu'il va se jeter dessus. Une provision doit vraiment, vraiment être protégée de toute utilisation involontaire. Donc, triez bien !</span><br /> <br /> <span class="s1">Le troisième risque, c'est de dépasser la provision. Ce qui conduit à l'explosion du processus. Si la provision est utilisée, vous aurez besoin de déterminer quelle proportion de la provision a été utilisée, sinon vous allez avoir une drôle de surprise à la fin du Sprint.</span><br /> <br /> | ||
==<span class="s1">'''Solution 4 : Corriger les causes racines, améliorer la qualité'''</span>== | ==<span class="s1">'''Solution 4 : Corriger les causes racines, améliorer la qualité'''</span>== | ||
<br /> <span class="s1">Cette solution est présentée comme la numéro 4, car les trois premières sont dans l'ordre logique lorsque vous essayez de maîtriser les dégâts, mais finalement vous aurez envie de faire la chose la plus importante de toutes : '''corriger définitivement les problèmes et construire la qualité intrinsèque de sorte que vous n'aurez plus d'urgence du tout !''' C'est quelque chose que nous devrions faire de toute façon, et ce n'est pas réservé aux projets Agile : vous voulez le faire dans n'importe quel type de projet ! Mais il y a une Règle supplémentaire qui est pertinente pour la provision (je remercie d'ailleurs au passage Jeff Sutherland, puisque j'ai appris cette règle lorsque nous faisions des formations CSM). Règle n°2 : Si vous dépassez la provision, arrêtez le Sprint. Si vous avez tellement de problèmes que vous ne pouvez même plus limiter le traitement des urgences à une petite provision, ce n'est plus la peine de chercher à vous améliorer pour développer des features. Arrêtez-tout et utilisez le Sprint pour corriger les causes racines, puis essayez à nouveau dans le Sprint suivant. C'est une coïncidence, mais la Règle n°2 fait également des merveilles pour tous les utilisateurs qui essayent de "reprioriser" : "voulez-vous vraiment corriger ce problème maintenant ? L'équipe estime que cela coûte deux points de travail, et cela va déborder de la provision. Il faudrait alors arrêter le Sprint, et vous n'aurez donc pas les stories utilisateurs que vous avez demandées ! Oh ... euh ... eh bien, je pense que ce n'est pas un problème si important que cela ... " (Et ça ne l'était effectivement pas ... il s'agit d'une véritable anecdote !).</span><br /> <br /> | <br /> <span class="s1">Cette solution est présentée comme la numéro 4, car les trois premières sont dans l'ordre logique lorsque vous essayez de maîtriser les dégâts, mais finalement vous aurez envie de faire la chose la plus importante de toutes : '''corriger définitivement les problèmes et construire la qualité intrinsèque de sorte que vous n'aurez plus d'urgence du tout !''' C'est quelque chose que nous devrions faire de toute façon, et ce n'est pas réservé aux projets Agile : vous voulez le faire dans n'importe quel type de projet ! Mais il y a une Règle supplémentaire qui est pertinente pour la provision (je remercie d'ailleurs au passage Jeff Sutherland, puisque j'ai appris cette règle lorsque nous faisions des formations CSM). Règle n°2 : Si vous dépassez la provision, arrêtez le Sprint. Si vous avez tellement de problèmes que vous ne pouvez même plus limiter le traitement des urgences à une petite provision, ce n'est plus la peine de chercher à vous améliorer pour développer des features. Arrêtez-tout et utilisez le Sprint pour corriger les causes racines, puis essayez à nouveau dans le Sprint suivant. C'est une coïncidence, mais la Règle n°2 fait également des merveilles pour tous les utilisateurs qui essayent de "reprioriser" : "voulez-vous vraiment corriger ce problème maintenant ? L'équipe estime que cela coûte deux points de travail, et cela va déborder de la provision. Il faudrait alors arrêter le Sprint, et vous n'aurez donc pas les stories utilisateurs que vous avez demandées ! Oh ... euh ... eh bien, je pense que ce n'est pas un problème si important que cela ... " (Et ça ne l'était effectivement pas ... il s'agit d'une véritable anecdote !).</span><br /> <br /> | ||
