Il n'y a que les paranos qui survivent :-)
Pourquoi mon "chef" (Chef de projet ou Scrum Master) me demande de chiffrer le temps de développement de ce bouzin ?
- Réponse A: Il veut me virer ?
- Réponse B: Il a demandé à Brandon et Brenda et il va comparer les 3 résultats, le meilleur aura un prime, les 2 autres seront virés, ça se trouve mon "chef" est en train d'inventer une nouvelle version de Kolanta.
Toutes les mois, il doit virer un développeur du projet et celui qui donne le meilleur chiffrage à le Totem et est assuré de revenir le mois suivant, les autres sont analysés sur leur dérive de leurs autres chiffrages, leur nombre de bug, le nombre de commit dans CVS...
- Réponse C: Il a relu "Chef de projet fainéant" durant ces vacances et donc nous délègue tout son boulot/
- Réponse D: Il veut planter le projet.
- Réponse E: La pire : Il veut nous démontrer que nous sommes des gros abrutis finis.


En fait, j'ai beau le dire, redire, répéter, rabâcher, ressasser et radoter :
"Il n'y a que le développeur qui va coder la tâche qui est le mieux placer pour estimer la tâche qu'il doit développer".

Il y a pour moi, 2 objectifs importants au fait que le développeur doit chiffrer son développement :

  1. Toute sa vie, le développeur va se entendre les mêmes questions : Dans combien de temps et pour combien de jour ?,
  2. Le développeur confirme qu'il a compris le besoin et qu'il est capable de le découpé en une série de sous-tâches,
  3. Apprendre à chiffrer est la meilleur école pour comprendre la notion du reste à faire (RAF),
  4. Le "bons" chiffrages mais surtout les améliorations dans les chiffrages (ou le RAF) permettent de créer des relations de confiances.


Ok, mais comment on apprend à chiffrer, on ne peut pas avoir une équipe de sénior, les "juniors" ne savent pas obligatoirement chiffrer.

(Certains séniors ne savent pas chiffrer....)

J'ai une technique super simple : Apprenez leur à se tromper et rappelez que ce n'est pas grave si ils se trompent c'est même normal, mais qu'au bout d'un mois leur chiffrage sera de plus en plus juste si ils comprennent pourquoi ils se sont trompés.

"Scrum dit" : les storys doivent être petites.
Pour moi petites c'est entre 2 et 5 jours (exceptionnellement 6 mais jamais 7).
Il y a plein d'avantages, je vous présenterais cela dans un autre billet :-)

Le développeur estime une tâche à 5 jours : la vérité est entre 2 et 6 vu que les tâches sont petites.
Chaque matin au Daily Scrum Meeting, on fait un point sur l'avancement, plus on avance moins on a d'inconnu et plus le développeur se rend compte de la charge de travail qui lui reste pour finir : il devient donc meilleur dans ces chiffrages.
Il se rend compte de ces erreurs (excès d'optimisme ou de pessimiste).

Au bout de quelques mois, l'ensemble de votre équipe arrive à chiffrer est des modules de plus en plus gros et se challengent sur les stratégies qui peuvent faire gagner du temps à l'équipe en détaillant leur chiffrage.

Vous avez donc atteint votre objectif : avoir une équipe qui sait chiffrer et qui sait argumenter/défendre son chiffrage.

Derniers points :

  • Les chiffrages sont des estimations hors marge de sécurité
  • C'est au Scrum Master de pondérer le chiffrage en fonction de l'ancienneté du développeur sur le projet ou des résultats de ces précédents chiffrages :-)
  • Comme l'explique Nicolas sur Le Touilleur Express : faites confiances à vos équipes, quelqu'un qui sur-chiffre et "bulle" toute la journée sera découvert rapidement.



Un chiffrage n'est qu'une estimation elle n'est valable que dans un environnement, à un instant t.