Comme beaucoup d’ingénieurs, je suis réticent à donner des estimations.
je ne sais pas estimer
Tous les jours, je résous des problèmes nouveaux, pour lesquels je n’ai encore jamais implémenté de solution.
Si vous n’avez jamais fait d’informatique, mettez-vous bien ça dans la tête : Contrairement au maçon qui peut construire des dizaines de maisons, l’informaticien ne fait jamais deux fois la même chose. Il peut réutiliser la solution précédente à l’infini, en quelques heures. Qu’un développeur fasse deux fois exactement la même chose est le symptôme d’un problème d’organisation.
Si je passe plus de quelques heures, c’est qu’il y a un problème nouveau ou quelque chose de nouveau dans le problème, même si de haut il ressemble à un autre. Mon travail c’est uniquement de créer ce qui manque, ce qui est nouveau par rapport à d’éventuelles solutions précédentes.
Et pour ce nouveau, je vais devoir étudier le problème posé, probablement découvrir des sous-problèmes qu’on n’imaginait pas. Je ne sais pas ce quelles difficultés je vais rencontrer, quelles solutions vont devoir être appliquées, comment les mettre en œuvre, si elles vont réussir ou échouer, et encore moins si le besoin racine va effectivement être couvert à la fin de tout cela.
Il y a plein de textes qui expliquent la problématique de l’estimation mais j’ai trouvé plus d’une fois que le récit de voyage de Michael Wolfe illustre très bien les enjeux avec une analogie que tout le monde comprend.
vous non plus
J’ai croisé de nombreuses personnes qui annonçaient savoir estimer assez correctement, et quelques unes qui semblaient effectivement le faire. Vous en connaissez peut-être aussi.
En pratique à chaque fois qu’on y regarde de plus près, l’estimation n’est pas plus juste qu’une autre. Au mieux on compense les mauvaises estimations en jouant sur le contexte. L’estimation est potentiellement respectée, mais elle n’en est pas plus juste. Et quand compenser ne suffit pas, on se rassure en considérant que ça ne compte pas parce que c’est exceptionnel, qu’il y a une cause extérieure, ou en reportant la faute sur un tiers.
Même les itérations de la tant aimée méthodologie SCRUM jouent sur le même registre : Donner une cible avec un engagement permet d’avoir un peu de pression sur l’équipe. C’est de la pression dite « positive », pour avoir envie d’atteindre l’objectif.
Au final c’est de la pression tout de même, qui souvent se retrouve sur l’amplitude horaire ou sur la fatigue. Quand le management n’a pas une attention et une culture extrêmement forte sur le sujet, ça joue aussi sur une baisse de qualité ou une création de dette technique. C’est humain. À défaut c’est le périmètre qui bouge, mais l’estimation n’en est pas meilleure. Bref, on pallie la mauvaise estimation en jouant sur le contexte.
Si vraiment quelqu’un estime toujours juste à plus de 90%, sans compenser sur le contexte, c’est qu’il est en train de passer du temps à refaire ce qu’il a déjà fait. S’il travaille pour vous : virez-le et embauchez quelqu’un qui saura réutiliser plutôt que perdre du temps.
même par petits lots
Même l’estimation par petits lots itératifs n’est qu’une illusion. On estime effectivement mieux des petites tâches qu’on sait percevoir, mais c’est uniquement parce qu’on réfléchit déjà à la problématique et à sa solution au moment de donner l’estimation.
Par la suite on se trompe autant qu’ailleurs. On compense là aussi par l’amplitude horaire, le stress de la pression personnelle, la qualité ou la dette technique. C’est juste que plus la tâche est petite, plus le décalage probable est petit et donc moins il se voit de l’extérieur quand on regarde unitairement.
Vous avez déjà remarqué qu’on ne fait pas tenir 8 tâches d’une heure dans une journée ou 5 tâches d’une journée dans une semaine ? Des tâches d’une heure dans une journée, prévoyez-en 6, moins le temps pour les réunions.
Et des fois on a juste oublié un cas d’usage ou manqué une problématique. Sur un lot important on aurait assumé et dérapé un peu. Sur une petite tâche le cas manqué peut prendre plusieurs fois l’estimation de la tâche initiale. On en fait donc une nouvelle tâche, avec sa propre estimation. Là aussi, l’excuse du cas exceptionnel ou de la sortie de périmètre permet d’éviter de remettre en cause ses estimations.
Alors oui, les estimations sur des petits lots ont tendance à être plus souvent respectées mais elles n’en sont pas beaucoup plus justes. Tout ceci n’est qu’œillères et illusions.
C’est mieux – et c’est logique vu qu’on estime au fur et à mesure du projet, une fois la connaissance acquise – mais ce n’est toujours pas bon.
la mauvaise question
On peut discuter de l’utilité des estimations, de la capacité du genre humain à savoir donner des estimations absolues. On peu aussi s’enfoncer dans un projet d’opposition, scander #noestimate… mais qu’apporterait-on comme valeur ?
Je suis surtout agacé qu’on se pose surtout la mauvaise question. Au jour le jour je n’ai aucunement besoin d’estimer. J’ai besoin d’apporter de la valeur. La seule question à me poser est « qu’est-ce qui amènera à priori le plus de valeur demain si je le fais aujourd’hui ? » et mettre mes ressources dessus.
La question n’est pas simple pour autant. J’ai besoin d’évaluer si le niveau d’effort à fournir est rentable par rapport à la valeur ajoutée attendue. Ensuite j’ai besoin de prioriser les évolutions entre elles, en fonction de la valeur et du niveau d’effort.
Sauf que justement, je n’ai besoin pour ces usages que d’un ordre de grandeur : Est-ce 10, 100 ou 1000 ? Est-ce beaucoup plus ou beaucoup moins que l’autre évolution à laquelle je pense ? Tout autre détail est aussi utile qu’un parachute pour monter sur une échelle.
L’évaluation de la valeur attendue subit de toutes façons les mêmes incertitudes que le niveau d’effort à fournir. Même s’il est fait à base d’une page pleine de formules, calcul de la valeur attendue dépend parfois totalement de paramètres estimés au doigt mouillé, où même un ordre de grandeur relève plus de la conviction que de l’estimation.
le mauvais usage
Vous posez-vous vraiment la bonne question ?
En cherchant à savoir si votre projet dérape vous êtes simplement en train de regarder s’il se conforme au plan prévu, à son estimation. Vérifier la validité d’une estimation ne vous apportera aucune valeur, surtout quand on sait dès le départ qu’elle est soumise à des aléas imprévisibles.
Pire, en imposant l’estimation préalable comme indicateur, on freine l’initiative (si je le fais, on prend un risque, même si je sais qu’il faut le faire), on freine la capacité de changer (si on le fait, il faut recalculer le plan, re-estimer, négocier cette estimation, expliquer le mauvais indicateur, ça ne vaut pas le coût ici, tant pis), et on oublie notre objectif (l’indicateur est bon, tant pis si en fait on s’est rendu compte que ça ne créait pas la valeur attendue et qu’il aurait fallu faire autre chose, ça aurait remis en cause le plan).
Vous pouvez vous dire que vous saurez déjouer tout cela, rester agile et pragmatique. Vous vous mentez, du moins tant que votre question sera « où est-ce qu’on en est par rapport aux estimations ? ».
C’est encore pire si vous utilisez l’estimation comme métrique pour apprécier l’efficacité ou la compétence de l’équipe de production. Là non seulement vous comparez juste des choux et des carottes, mais en plus vous inversez votre résultat : Ce sont des équipes qui respectent toutes leurs estimations que vous devriez avoir peur. Elles masquent leurs erreurs en les compensant, volontairement ou non, et ça faussera toutes vos analyses sur la production passée ou future.
arrêter de naviguer dans le passé
Les méthodes agiles vont dans le bon sens mais il est trop facile de s’arrêter aux artefacts sans en comprendre l’objectif. Le principe n’est pas que de découper en petits lots plus faciles à estimer pour pouvoir reprendre une décision entre les différents lots.
Il y a aussi une philosophie derrière, celle de l’apport de valeur.
Seul le présent créé de la valeur. La stratégie envisage le futur, les rétrospectives tirent les leçons du passé. Si vous n’êtes ni dans un contexte de choix stratégique ni en train de tirer des leçons en rétrospective, vous ne devez que vous préoccuper de la meilleure façon d’apporter de la valeur là, maintenant, tout de suite, peu importe ce que vous aviez pu prévu ou estimé par le passé.
Que dois-je faire aujourd’hui et maintenant pour apporter le plus de valeur ?
La pertinence de l’estimation passée ne m’est jamais d’aucune utilité pour répondre à cette question. J’insiste : Jamais. Je prends en compte les difficultés et facilités dans des rétrospectives pour m’améliorer. Je les prends en compte pour évaluer l’effort à fournir sur le reste à faire, et donc l’opportunité de continuer. Que ces facilités ou difficultés aient été prévues ou non, que j’ai divisé par 2 ou multiplié par 20 mon estimation n’importe finalement aucunement.
Estimez, c’est utile, important. Ensuite oubliez-les et surtout ne les réutilisez pas pour autre chose.
(sur le même sujet We don’t need no stinking estimates)
Photo d’entête sous licence CC BY-NC-SA par Mark Notari
