« Scrum : 19 antipatterns de planification d'un sprint » : différence entre les versions
De Wiki Agile
| Ligne 43 : | Ligne 43 : | ||
* '''Longueurs de sprint irrégulières :''' l'équipe Scrum a des cadences de sprint variables. Par exemple, les éléments ne sont pas dimensionnés pour tenir dans la durée normale du sprint. Au lieu de cela, la longueur du sprint est adaptée à la taille des éléments. (Il est assez courant d’allonger la longueur du sprint à la fin de l’année lorsque la plupart des membres de l’équipe sont en vacances. Cependant, il n’y a aucune raison de s’écarter de la cadence normale pendant le reste de l’année. Au lieu de changer la longueur du sprint, l’équipe Scrum devrait consacrer davantage d’efforts à découper de la bonne manière les epics et les user stories.) | * '''Longueurs de sprint irrégulières :''' l'équipe Scrum a des cadences de sprint variables. Par exemple, les éléments ne sont pas dimensionnés pour tenir dans la durée normale du sprint. Au lieu de cela, la longueur du sprint est adaptée à la taille des éléments. (Il est assez courant d’allonger la longueur du sprint à la fin de l’année lorsque la plupart des membres de l’équipe sont en vacances. Cependant, il n’y a aucune raison de s’écarter de la cadence normale pendant le reste de l’année. Au lieu de changer la longueur du sprint, l’équipe Scrum devrait consacrer davantage d’efforts à découper de la bonne manière les epics et les user stories.) | ||
* '''Excès d’engagement :''' l’équipe Scrum prend régulièrement trop d'éléments et transfère simplement le travail inachevé dans le prochain sprint. (Si deux ou trois éléments s'empilent dans le sprint suivant, qu’il en soit ainsi. Si, régulièrement, 30 à 40% de la prévision initiale n’est pas livrée pendant le sprint, l’équipe Scrum a peut-être créé une sorte de "Kanban timeboxé". Peut-être est-ce le bon moment pour demander à l’équipe Scrum si essayer Kanban pourrait constituer une bonne alternative.) | * '''Excès d’engagement :''' l’équipe Scrum prend régulièrement trop d'éléments et transfère simplement le travail inachevé dans le prochain sprint. (Si deux ou trois éléments s'empilent dans le sprint suivant, qu’il en soit ainsi. Si, régulièrement, 30 à 40% de la prévision initiale n’est pas livrée pendant le sprint, l’équipe Scrum a peut-être créé une sorte de "Kanban timeboxé". Peut-être est-ce le bon moment pour demander à l’équipe Scrum si essayer Kanban pourrait constituer une bonne alternative.) | ||
* '''Etapes / Portes avec la | * '''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.) | |||
* | * | ||
