Contrôle des connaissances

Savoir analyser un burndown chart de sprint

Cette année à l'IUP ISI, une Unité d'Enseignement (UE) était dédiée aux méthodes agiles. Elle était programmée au premier semestre et s'est donc terminée en décembre. Un étudiant doit être évalué pour une UE, j'ai donc proposé un examen (il y avait aussi un contrôle continu).

Une des 2 questions portait sur la gestion de projet agile, que les étudiants ont vue en cours, avec des travaux pratiques, et qu'ils mettent en oeuvre sur leurs projets.
La voici :

bdc.jpg

Considérez les burndown charts de sprint (itération) ci-contre. Ils présentent des situations typiques rencontrées pendant le déroulement des sprints.

Questions

Pour chacun de ces burndown charts indépendamment des autres :

  • donner une ou plusieurs raisons qui peuvent expliquer qu'on en soit arrivé à ce que montre le burndown chart
  • proposer une ou plusieurs actions pour finir le sprint de la meilleure façon.

Quelques réponses amusantes des étudiants

Pour le BDC 2 :

  • raison : la vélocite est trop importante
  • pour moi ce cas est quasi idéal
  • la phase de conception s'est mal déroulée. Action : faire valider sa conception

Pour le BDC 3

  • raison : les développeurs sont en vacances. Action : attendre leur retour

Pour le BDC 4

  • raison : un membre de l'équipe est tombé malade
  • action : contrôler la machine à café
  • action : faire appel à un professionnel
  • action : engager des intérimaires

Pour le BDC 7

  • action : prendre des vacances

Parmi les actions proposées, des fans d'XP ont aussi proposé de :

  • transformer des stories en spike,
  • faire du pair programming pour aider un développeur en difficulté

Dans l'ensemble les résultats montrent une bonne interprétation des burndown charts, sauf une tendance pour quelques uns à proposer, quand la courbe est au dessus de l'idéal, de :

  • embaucher
  • augmenter la vélocité

Les BDC 1, 2, 3, 4 et 6 sont rencontrés assez souvent. Les 2 autres un peu moins, je ne les ai vus qu'une fois chacun sur des projets. Si pour le BDC 5, quelques étudiants ont donné l'explication correspondant à ce que j'ai vécu, personne n'a trouvé pour le BDC 7(la plupart ont dit que l'équipe travaillait plus vite que prévu, ce qui est une explication possible, mais pas celle que j'ai rencontrée). Une idée ?

27 janvier : Je l'ai rencontré pour de vrai. La raison était la suivante : lors de la réunion de planification de sprint, toutes les tâches n'avaient pas été estimées (ni même identifiées pour certaines), ça arrive. Avant qu'elles ne le soient, les burndown charts ressemblaient au BDC7, donnant l'impression qu'on finirait avant la moitié du sprint. Après, ça a repris une allure plus normale :

bdc7.jpg

Commentaires

1. Le jeudi 10 janvier 2008, 17:30 par Migi

Pour le 7, vous avez réussi à négocier une réduction du périmètre ?

2. Le vendredi 11 janvier 2008, 19:46 par David Gageot

BDC 7 : Tu t'es encore endormi sur ton stylo Gribouille !

3. Le vendredi 11 janvier 2008, 22:14 par Thomas Lissajoux

Bonne idée pour un examen. Attention que les étudiants ne surveille pas de trop près les réflexions de l'excellent Mishkin Berteig toutefois ! ;)

Personnellement j'ai préféré aborder ça comme exercice durant le cours de gestion de projet agile que je donne en Master au CS2I… Pour le coup, il faudra que je me fende d'un billet, histoire de partager qq idées de contrôle de connaissance.

Ca sera d'ailleurs intéressant que l'on échange sur l'enseignement des méthodes agiles. Peut-être lors d'un Sigmat, je ne désespère pas, ou par mail entretemps.

4. Le mardi 15 janvier 2008, 16:27 par JM.D

Je vote pour un bon gros "refactoring des familles" qui a tué dans l'œuf la complexité ayant entrainé une estimation finalement sur-évaluée.

Le burndown chart de l'itération qui a suivi a dû retrouver une courbe plus "normale" ?

5. Le dimanche 27 janvier 2008, 22:13 par claude aubry

merci pour les réponses pour le BDC7. Cela aurait pu être une sur-estimation du travail ou bien une vélocité nettement accélérée (plus de 2 fois !). Mais c'était seulement un retard dans l'estimation des tâches...