Contrôle des connaissances

Savoir analyser un burndown chart de sprint

Contrôle des connaissances

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 en dessin.

Considérez les burndown charts de sprint (itération) fournis. 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é

Bilan

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

Voir aussi :