Chute de vélo-cité

Une équipe que j'ai formée aux méthodes agiles vient de finir une itération de 3 semaines. La vélocité estimée au début de l'itération était de 24. Résultat à la fin : seulement 6 points.

Des événements imprévus ont perturbé le déroulement de l'itération, mais cela ne justife pas un résultat 4 fois inférieur aux prévisions.
La seule bonne nouvelle que j'y vois est que l'équipe a bien assimilé la notion de fini et ne compte des points que lorsque l'exigence est vraiment finie (et donc testée).
Comment éviter une telle situation qui n'est satisfaisante pour personne ?

  • lorsqu'on s'aperçoit que les objectifs initiaux d'une itération ne seront pas tenus (comme ça a dû être le cas), il est préférable de recadrer l'itération sur des objectifs réduits, ce qui évite d'avoir plein de choses commencées et non finies
  • il est important d'en analyser les raisons objectives lors de la rétrospective et d'en déduire des actions concrètes pour la prochaine itération, à commencer par une estimation plus raisonnable
  • un bug découvert sur une exigence déjà finie devrait aller dans le backlog et être candidat pour la prochaine itération plutôt que d'être pris en compte immédiatement au risque de perturber les travaux en cours
  • lors de la planification en début d'itération, l'équipe doit s'engager collectivement sur ce qu'elle pense pouvoir faire. C'est elle qui décide des tâches à mettre dans l'itération. Il est probable qu'alors elle fera des estimations plus réalistes. Elle sera ensuite motivée pour faire ce qu'elle a dit qu'elle ferait.

Commentaires

1. Le vendredi 25 août 2006, 11:03 par Avangel

Concernant le point 4, c'est ce qu'il y a de plus pénible à faire il me semble : c'est fastidieux et rébarbatif. Mais d'un autre côté, c'est là qu'on réfléchit vraiment à fond sur les aspects techniques de la réalisation d'une fonctionnalité, et qu'on se rend compte qu'on avait sous-estimé quelquechose. Des quelques expériences que j'ai vues, cette activité est souvent un peu bâclée, et les conséquences en sont très lourdes.

Mais quel temps peut-on consacrer à cette activité : certains problèmes suscitent des discussions techniques parfois très longues, et le "timebox" de 4 heures n'est clairement pas suffisant. J'ai conseillé d'introduire la réflexion au problème comme une tâche à réaliser, mais ça conditionne souvent l'estimation des autres tâches... L'exemple typique c'est la réalisation d'un module générique qui permettra d'aller plus vite par la suite. Si on a pas bien réfléchi à ce module, impossible d'estimer correctement les suivants.

2. Le vendredi 25 août 2006, 13:06 par claude aubry

L'engagement de l'équipe est fondamental. Cette seconde partie de la réunion de planification est effectivement parfois bâclée, surtout qu'elle vient immédiatement après la sélection des exigences avec le propriétaire du produit. Il est difficile de garder tout le monde concentré.

Ce que tu proposes est une bonne solution, ça s'appelle un "spike", une tâche dont le but est de comprendre suffisamment une exigence pour pouvoir estimer correctement les tâches associées. Il est évident qu'il faut inclure des tâches de réflexion dans une itération.

De mon point de vue le problème que tu évoques, la difficulté de l'équipe à s'engager, vient aussi d'un manque de travail sur l'architecture et la conception au début, lors de la phase de préparation.