21 juin! C'est l'été, la fête de la musique, les plages ensoleillées, les corps qui se détendent, les esprits qui se délassent.... C'est l'été, et son cortège de casse-têtes pour tout manager de projet, avec cette période de vacances qui va s'éterniser. Comment planifier quelque chose dans ces conditions là?
C'est certain, avec un planning traditionnel, l'été est propice aux suicides des chefs de projets! Un planning établi à l'automne, avec un découpage en tâches très précis ne peut qu'exploser avec les acances. Bien sûr, le chef de projet aura pris soin d'anticiper tout cela en demandant aux membres de son équipe de remplir en décembre un volumineux fichier Excel des congés, de décembre à septembre. Mais, outre le fait que l'équipe l'aura pris pour quelqu'un de très rasoir et de bien psycho-rigide, ce volumineux fichier ne sert pas à grand chose, car, nous le savons tous, les vacances se décident de plus en plus tard...appartenant au domaine des vacances et du loisirs, je suis bien placé pour en savoir quelque chose, et le succès de lastminute.com nous démontre bien qu'au delà d'un horizon de 15 jours, il est tout à fait illusoire de croire que l'on puisse connaître les absences de ses collaborateurs. Tiens, d'ailleurs, je ne sais pas moi-même encore quand je prendrais mes vacances...
Comment ça se passe, avec scrum? Avec scrum, nous avons une planification en pelures d'oignon :
- premier niveau de planification : la journée. Pendant le scrum, chaque membre de l'équipe planifie sa journée, de manière consensuelle avec le reste de l'équipe. En général, sauf accident ou indigestion, il n'y a pas de risque d'absence innattendue : les personnes présentes au scrum du matin savent parfaitement si elles sont présentes tout ou partie de la journée.
- second niveau de planification : le sprint. Nous avons choisi une durée de sprint de 15 jours, ce qui correpond, dans mon esprit, à la période de prévision minimale crédible des congés et RTT. Donc, lors de la phase d'élaboration du sprint, nous savons tous quelle sera la capacité de l'équipe sur le sprint à venir. Donc, l'engagement de l'équipe sur le contenu du sprint est cohérent avec les absences éventuelles de ses membres.
- troisième niveau de planification : la release. La release correspond au contenu d'un ensemble de user stories que le Product Owner souhaiterait voir mis en oeuvre. Techniquement, il s'agit donc d'un plan de développement qui recouvre un certain nombre de sprint. Ce plan de développement est établi par le Scrum Master, à partir des demandes du Product Owner. Le Scrum Master doit donc répartir ces demandes dans le temps, en tenant compte de la vélocité de l'équipe. Et les congés, alors, me direz-vous? Pour moi, la vélocité tient compte des congés. En effet, dans une équipe qui tourne depuis un certain temps, il y aura déjà eu des collaborateurs absents, en congés, en RTT, etc... la vélocité intègre donc une certaine part de congés, et, puisque le plan de développement est une vision à moyen terme de planification, globalement, les absences seront lissées sur la durée du plan. Bien entendu, un plan de développement est, par nature, amené à se préciser sprint après sprint, en fonction des problèmes techniques rencontrés, d'éventuelles nouvelles priorités à intégrer ou des user stories à retirer, des solutions techniques permettant d'aller plus vite...et des congés. Mais ces ajustements resteront assez marginaux, et à un ou deux sprints près, la release devrait se dérouler sans difficulté particulière.
Vive l'été!
Commentaires