« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 45 : | Ligne 45 : | ||
* '''Etapes / Portes avec la Définition du Prêt :''' la définition du prêt est traitée de manière dogmatique, créant ainsi un processus d'approbation semblable à un processus étapes / portes. (C’est un sujet intéressant pour une discussion entre les membres de l’équipe. Par exemple, une user story intéressante devrait-elle être reportée à un autre sprint simplement parce que les conceptions de la partie cliente ne seront pas disponibles avant deux jours de travail ? Mon conseil: présentez-la à l'équipe. Si elle est d'accord avec la situation du moment et accepte la user story dans le sprint, c'est très bien. Pour en savoir plus : [https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready Les dangers d'une Définition du Prêt].) | * '''Etapes / Portes avec la Définition du Prêt :''' la définition du prêt est traitée de manière dogmatique, créant ainsi un processus d'approbation semblable à un processus étapes / portes. (C’est un sujet intéressant pour une discussion entre les membres de l’équipe. Par exemple, une user story intéressante devrait-elle être reportée à un autre sprint simplement parce que les conceptions de la partie cliente ne seront pas disponibles avant deux jours de travail ? Mon conseil: présentez-la à l'équipe. Si elle est d'accord avec la situation du moment et accepte la user story dans le sprint, c'est très bien. Pour en savoir plus : [https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready Les dangers d'une Définition du Prêt].) | ||
* '''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.) | ||
* '''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 "responsales" 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 == | ||
