« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (7 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Portail Planification]] | [[Category: Portail Planification]] | ||
[[Category: Portail Product Owner]] | |||
Auteur : Stefan Wolpers<br/> | Auteur : Stefan Wolpers<br/> | ||
Source : [https://age-of-product.com/scrum-sprint-planning-anti-patterns/ Scrum: 19 Sprint Planning Anti-Patterns]<br/> | Source : [https://age-of-product.com/scrum-sprint-planning-anti-patterns/ Scrum: 19 Sprint Planning Anti-Patterns]<br/> | ||
| Ligne 11 : | Ligne 12 : | ||
La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. Évitez les 19 antipatterns suivants de planification de sprint vous aidera également.<br/> | La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. Évitez les 19 antipatterns suivants de planification de sprint vous aidera également.<br/> | ||
<br/> | <br/> | ||
[[Fichier:Scrum-19-sprint-planning-anti-patterns-hands-on-agile-1650 fr.png|border|1000px]]<br/> | [[Fichier:Scrum-19-sprint-planning-anti-patterns-hands-on-agile-1650 fr.png|border|1000px|link=]]<br/> | ||
==Le but d'une planification de sprint == | ==Le but d'une planification de sprint == | ||
La planification du sprint en Scrum a pour but d’aligner l’équipe de développement et le Product Owner. Les deux doivent s'entendre sur l'incrément produit déployable lors du prochain sprint. L’idée est que les prévisions de l’équipe de développement reflètent l’objectif du sprint du Product Owner. En outre, l'équipe doit élaborer un plan sur la manière de transformer ses prévisions.<br/> | La planification du sprint en Scrum a pour but d’aligner l’équipe de développement et le Product Owner. Les deux doivent s'entendre sur l'incrément produit déployable lors du prochain sprint. L’idée est que les prévisions de l’équipe de développement reflètent l’objectif du sprint du Product Owner. En outre, l'équipe doit élaborer un plan sur la manière de transformer ses prévisions.<br/> | ||
<br/> | <br/> | ||
Si l'équipe Scrum a | Si par le passé l'équipe Scrum a utilisé avec succès l'affinage du backlog produit, la première partie de la planification du sprint sera rapide. L’équipe de développement et le Product Owner ajusteront la portée du sprint à venir en tenant compte de la capacité disponible. Peut-être que quelqu'un de l'équipe de développement ne sera pas disponible au prochain sprint. Donc, un ou deux éléments devront retourner dans le backlog du produit.<br/> | ||
<br/> | <br/> | ||
Ou un nouvel élément fonctionnel intéressant est apparu du jour au lendemain et le Product Owner souhaitera que cet élément fasse partie du prochain backlog de sprint. Par conséquent, une autre user story retournera dans le backlog produit. Une bonne équipe pourra gérer cela en cinq à dix minutes avant de passer à la deuxième partie de la planification du sprint. Au cours de la planification du sprint II, l’équipe décompose le premier ensemble d’éléments de backlog du sprint en tâches.<br/> | Ou un nouvel élément fonctionnel intéressant est apparu du jour au lendemain et le Product Owner souhaitera que cet élément fasse partie du prochain backlog de sprint. Par conséquent, une autre user story retournera dans le backlog produit. Une bonne équipe pourra gérer cela en cinq à dix minutes avant de passer à la deuxième partie de la planification du sprint. Au cours de la planification du sprint II, l’équipe décompose le premier ensemble d’éléments de backlog du sprint en tâches.<br/> | ||
== Antipatterns de la planification du sprint == | == Antipatterns de la planification du sprint == | ||
Il existe trois catégories d'antipatterns de planification de sprint. Ils concernent l'équipe de développement, le Product Owner et l'équipe | 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 ?''' 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.) | * '''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.) | ||
| Ligne 26 : | Ligne 28 : | ||
* '''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 :''' 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|link=]]<br/> | ||
<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 | * '''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 soyez 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.) | * '''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.) | * '''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.) | ||
| Ligne 46 : | Ligne 48 : | ||
* '''Ignorer la Définition du Prêt :''' l'équipe de développement ne rejette pas les user stories qui ne correspondent pas à la définition du prêt. (C’est l’opposé du dogme de l’application de la Définition du Prêt : les user stories qui ne sont pas prêtes et qui vont causer des perturbations inutiles pendant le sprint sont autorisées. Laisser-faire n’aide pas non plus.) | * '''Ignorer la Définition du Prêt :''' l'équipe de développement ne rejette pas les user stories qui ne correspondent pas à la définition du prêt. (C’est l’opposé du dogme de l’application de la Définition du Prêt : les user stories qui ne sont pas prêtes et qui vont causer des perturbations inutiles pendant le sprint sont autorisées. Laisser-faire n’aide pas non plus.) | ||
* '''Prévision imposée :''' la prévision de sprint n'est pas une décision d'équipe. Ou ce n'est pas sans influence de l'extérieur. (On a plusieurs antipatterns possibles. Par exemple, un Product Owner assertif domine l’équipe de développement en définissant l'étendue de la prévision. Ou une partie prenante mentionne la vélocité précédente de l'équipe et exige d'elle de prendre davantage de user stories. ("Nous devons remplir la capacité disponible.") Ou le "leader technique" de l'équipe de développement fait une prévision au nom de l'équipe.) | * '''Prévision imposée :''' la prévision de sprint n'est pas une décision d'équipe. Ou ce n'est pas sans influence de l'extérieur. (On a plusieurs antipatterns possibles. Par exemple, un Product Owner assertif domine l’équipe de développement en définissant l'étendue de la prévision. Ou une partie prenante mentionne la vélocité précédente de l'équipe et exige d'elle de prendre davantage de user stories. ("Nous devons remplir la capacité disponible.") Ou le "leader technique" de l'équipe de développement fait une prévision au nom de l'équipe.) | ||
* '''Planification ignorée :''' l'équipe de développement ne participe pas collectivement à la planification du sprint. Par exemple, deux membres de l'équipe, le responsable technique et le responsable UX, représentent l'équipe. (Si l'on parle de cette idée d'avoir un ou deux coéquipiers " | * '''Planification ignorée :''' l'équipe de développement ne participe pas collectivement à la planification du sprint. Par exemple, deux membres de l'équipe, le responsable technique et le responsable UX, représentent l'équipe. (Si l'on parle de cette idée d'avoir un ou deux coéquipiers "responsables" dans une équipe Scrum, en fait il n'y en a pas, voir ci-dessus. Et à moins que vous n'utilisiez LeSS - sans jeu de mots - où les équipes sont représentées dans la planification générale du sprint, l’ensemble de l’équipe Scrum doit participer. C’est un effort collectif, et chaque voix doit donc être entendue.) | ||
== Conclusion == | == Conclusion == | ||
La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. La plupart des antipatterns de planification de sprint mentionnés précédemment sont simples à corriger. Contenez-vous de les | La planification du sprint en Scrum est une cérémonie simple. Investissez dès le départ dans l'affinage du backlog produit et vous maintiendrez cette cérémonie productive. La plupart des antipatterns de planification de sprint mentionnés précédemment sont simples à corriger. Contenez-vous de les présenter à l'équipe.<br/> | ||
<br/> | <br/> | ||
Quels sont selon vous les antipatterns de planification de sprint qui manquent ? S'il vous plaît, n'hésitez pas à les partager avec nous dans les commentaires. | Quels sont selon vous les antipatterns de planification de sprint qui manquent ? S'il vous plaît, n'hésitez pas à les partager avec nous dans les commentaires. | ||
