Durée d'une itération

Lorsqu'on se lance dans le développement itératif, une des premières questions à laquelle il faut répondre concerne la durée des itérations.
Avec 2 questions annexes : l'équipe peut-elle repousser une fin d'itération si elle n'a pas atteint ses objectifs ? est-ce que la durée est la même pour toutes les itérations ?
Il n'y a pas de réponse universelle, chaque projet est différent et doit définir sa façon de travailler. Il existe un consensus de la communauté agile pour préconiser que toutes les itérations doivent être de même durée (pour garder le rythme) et qu'une itération est un bloc de temps fixé (si les objectifs ne sont pas atteints on ne recule pas la fin d'itération, on en tient compte lors de la revue pour les prochaines itérations).
En revanche, il y des variations sur la durée d'une itération. On constate des variations qui vont d'une semaine jusqu'à 6 semaines.
Scrum recommande des itérations (sprints) de 30 jours. 30 jours en durée ou 30 jours de travail (6 semaines de 5 jours) ? C'est 30 jours en durée-un mois-, qu'on peut arrondir à 4 semaines si on veut avoir un rythme au niveau de la semaine. En pratique dans les projets agiles, même suivant Scrum, c'est souvent moins (jamais plus). La plupart des projets ont des itérations de 2 ou 3 semaines. Quels sont les critères à retenir pour définir la bonne durée ?
  • l'implication des clients et utilisateurs. Il faut tenir compte de leur disponibilité à utiliser les versions partielles produites à la fin de chaque itération.
  • du cout supplémentaire engendré par l'itération. Une itération ajoute un "overhead" pour préparer le produit partiel, faire les tests de non régression, préparer la démo et pour les revues de fin et de début d'itération.
  • la taille de l'équipe. Plus il y a de personnes dans l'équipe, plus il faudra plus de temps pour se synchroniser.
  • de la durée maximum pour prendre en compte un changement. Il faut tenir compte que cette durée peut aller jusqu'à 2 fois la durée d'une itération (le changement est demandé pendant l'itération n et développé au plus tôt dans l'itération n+1). Cela ne concerne que les itérations produisant des versions déployées. 
  • la longueur du projet(de la release). Il doit comporter au moins 4 itérations pour bénéficier des avantages de l'itératif.
  • le maintien de la motivation de l'équipe. Une durée trop longue va au détriment d'une distribution uniforme du travail pendant l'itération et conduit à travailler dans l'urgence à la fin.
J'ai suivi depuis 4 ans des projets qualifiés d'itératifs. Avec l'expérience, je préconise maintenant des itérations avec des durées les plus courtes possibles(en tenant compte du contexte). Cela demande des efforts, mais je trouve que c'est plus efficace.
Je suis  actuellement 2 projets. Le premier a des itérations de 3 semaines. Pour tenir compte des ponts du moi de mai, nous avons allongé un peu l'itération en cours pour rester à environ 15 jours de travail. Sur le second, je joue le rôle de directeur produit(product owner).  Les itérations durent une semaine. Compte tenu du contexte, cela apparaît la durée idéale et c'est très satisfaisant pour l'équipe.

La discussion continue ailleurs

1. Le mardi 09 mai 2006, 14:38 par .: Avangel's weblog :.

La souplesse de Scrum

Le propre des processus Agiles est d’être souple. C’est bien là toute leur force, en opposition aux processus “classiques”, qui imposent de fortes contraintes organisationnelles très coûteuses en temps et en ressources, pour...