Ponts en mai, appentis en juin

Mi avril, je m'étais mis d'accord avec un charpentier pour la construction d'un appentis. Il s'était engagé à faire les travaux en mai. Je l'appelle hier, il me dit : vous comprenez, avec tous ces ponts, on a pris du retard, je ne pourrai venir chez vous qu'en juin. Ce que je comprends surtout c'est que le 17 avril, il n'avait pas pensé qu'il y aurait des ponts en mai pour ses prévisions de travaux. Après tout, les artisans ne sont pas formés à la gestion de projet.

Il arrive aussi que des étudiants, sensibilisés eux à la gestion de projet, utilisent ce genre d'argument -faire passer une situation prévisible pour une vicissitude imprévue- pour tenter de justifier un manque de résultat. Par exemple, à la fin d'un sprint j'ai quelquefois entendu qu'à cause du projet temps réel l'équipe n'avait pas pu consacrer autant de temps qu'elle aurait souhaité sur mon projet. Je ne suis pas dupe, le responsable du projet temps réel a dû entendre la même chose.

Agile ou pas, la planification agile doit tenir compte des événements connus à l'avance, comme les ponts en mai. Pour Scrum cela peut influencer la durée du sprint. Par exemple, une équipe de 5 personnes qui fait habituellement des sprints de 3 semaines dispose de 5 fois 5 fois 3 soit 75 jours de ressources. Elle commence un nouveau sprint le 28 avril et les membres de l'équipe font les ponts de mai. Pour avoir en gros les mêmes ressources que pour les autres sprints[1], il est logique de passer la durée de ce sprint à 4 semaines. Cela devrait être anticipé dans le planning de la release.

Notes

[1] ce qui rend la mesure de la vélocité plus pertinente