Estimating or not, that is the question
Le problème des estimations, c'est qu'elles sont prises pour argent comptant. Pourtant, une estimation ne saurait être un engagement : parfois, on tombe sur un os, un imprévu, lié à la spécification ou à la codebase elle-même.
Et là, on explose les délais.
Conséquence : les développeurs se protègent en donnant des estimations plus élevées que de raison. Si j'estime qu'il me faudra 1 journée pour faire ça, je dis 3. 3 jours, comme ça il ne peut rien m'arriver.
Bon, évidemment, si ensuite je livre au bout d'une journée, mon manager va très vite s'y habituer. "Ah ben, oui, mais ça c'est Mathieu, il voit toujours des problèmes qui n'arrivent pas et quand il dit 3 jours, il livre au bout d'1 journée. Donc c'est bon, je peux m'engager tranquille sur 1 jour de dev."
Donc oui, mais non en fait : retour à la case départ.
D'autant qu'à livrer trop vite, je passe pour un bleu qui ne sait pas estimer. Donc je vais le faire en 1 jour (probablement), livrer au bout de 3 et faire des trucs perso en loucedé le reste du temps. Chaque matin, au daily, je dirai "ça avance, ça devrait tenir dans les délais". Oui, j'ai (sur)vécu en entreprise.
Faut-il blâmer les développeurs ? Pas nécessairement : relisez ces lignes depuis le début.
Alors comment sortir de cette spirale, délétère pour tout le monde ?
C'est très simple : il suffit d'arrêter de faire des estimations. Ce soir à 17h, il sera 17h. Ça, j'en suis sûr. Le reste relève de la divination. 15 ans d'expérience professionnelle et je ne suis pas fichu de faire une estimation qui tienne la route. Ou bien si, mais une fois que le travail est fait 😉 Suis-je un mauvais développeur ?
Là, tout esprit sain se dit intérieurement : "oui, mais moi, j'ai besoin d'une date !" Bon point. Stay tuned.
En fait, renoncer à faire des estimations (le no-estimate), ça ne marche que si le découpage en user stories a été poussé à l'extrême : de la dentelle, un découpage façon puzzle. En effet, si chaque user story est vraiment petite (je ne sais pas exactement ce que ça veut dire mais prenons 1/2 journée), si je me trompe et que j'y passe 1 journée, ça n'est pas grave. Ça n'est pas grave, car dans la masse des user stories, les erreurs se compensent.
Et au final, la seule chose qui compte est le nombre de user stories.
Mon manager veut une date ? Il lui suffit de compter les user stories et d'appliquer le facteur multiplicatif qu'il veut. Il pourra le calculer en observant l'historique des développements. En passant, cela devient son estimation, plus la mienne : une inversion de la charge de l'estimation, en quelque sorte 😚
Evidemment, ça demande de s'entendre sur ce qu'est une user story. On ne le répètera jamais assez, mais découper en 1 story front et 1 story back n'a aucun sens, parce qu'une user story doit pouvoir être mise en production et apporter de la valeur à l'utilisateur.
Donc le seul, le vrai, l'unique sujet, c'est le découpage. Et avant cela, la spécification et la découverte fonctionnelles. On pourrait en parler des heures, mais à chaque jour suffit sa peine 🙏