Les esti­ma­tions de petites tâches ne sont pas plus précises

Un des premiers mensonges qu’on vous livre trop souvent avec SCRUM c’est qu’on peut esti­mer des petites tâches avec bien plus de préci­sion que des grandes, et qu’en consé­quence on peut être assez fiable dans l’es­ti­ma­tion des une à trois semaines de chaque itéra­tion.

Foutaises !

Combien de temps faut-il pour mettre les blou­sons avant d’al­ler à l’école ? Mettons 30 secondes si on ne se presse pas. La réalité c’est que ça mettra plus souvent 5 minutes que 30 secondes, et ça c’est si on n’a pas besoin de se battre.

400% de marge d’er­reur ? Comment voulez-vous faire un plan­ning avec de telles esti­ma­tions. Pour­tant on est sur une tâche connue, répé­tée chaque jour. Seule solu­tion, on triche et on compte 2 minutes 30. Même ainsi on a une marge d’er­reur de 100%. Hallu­ci­nant !

Ce n’est pas un exemple choisi. J’ai le même problème pour termi­ner la tartine, pour boire le verre d’eau ou pour passer aux toilettes avant de partir, pour descendre dans la rue, pour faire le trajet, pour trou­ver le badge et passer le portail de l’école, pour montrer ma carte au vigile, pour les 10 mètres dans l’école au milieu des copains et autres parents d’élèves, pour le bisou de bonne jour­née avant de pouvoir repar­tir…

Ce n’est pas non plus la faute d’une mauvaise analo­gie. Esti­mer une petite tâche est juste impos­sible parce que le moindre aléa fait tout explo­ser.

Ajou­ter un lien sur une page ça prend 30 secon­des… sauf si on vous dit de chan­ger l’URL au dernier moment et qu’il faut faire deux fois le travail, sauf si c’est le seul lien à cet endroit et qu’il faut retou­cher les règles de style, sauf si le lien passe à la ligne en plein milieu et que visuel­le­ment ça ne le fait pas du tout sur ce compo­sant, sauf si l’es­pace pris fait glis­ser le bouton qui suit sous le clavier sur un smart­phone une fois le clavier déplié, sauf s’il faut partir à la chasse de la bonne URL parce que c’était « ça n’a pas d’im­pact, on donnera le lien au dernier moment », sauf si on se rend compte qu’il faut mutua­li­ser ce lien avec autre chose ailleurs dans l’ap­pli­ca­tion, sauf si ajou­ter un lien casse le test end-to-end et qu’il faut le réécrire pour faire passer le serveur d’in­té­gra­tion conti­nue au vert, sauf si… pour un simple foutu lien !


Et pour­tant, on n’est jamais en retard à l’école. Malgré les aléas infi­nis à chaque tâche, le projet « aller à l’école » prend 45 minutes à ±15 minutes. Pas plus.

Ce n’est même pas qu’es­ti­mer le projet dans son ensemble permet de lisser les risques de déra­pages, c’est que le temps que prend chaque tâche dépend de toutes les tâches précé­dentes et des options qu’il nous reste pour les suivantes.

S’il faut lutter pour termi­ner le crois­sant alors on active sérieu­se­ment la suite. Si les toilettes s’éter­nisent je prépare le blou­son et le bonnet pendant ce temps. S’il le faut on presse un peu le pas. À l’école, si on arrive dans les derniers, aucun parent d’élève ou cama­rade ne nous retient dans les dix derniers mètres et le bisou sera vite fait. Si vrai­ment on est super en retard on peut toujours sortir le vélo ou prendre le tram.


En réalité si SCRUM estime les fonc­tion­na­li­tés unitaires ce n’est pas pour s’en­ga­ger sur un résul­tat donné à l’avance, ni même pour mesu­rer si l’ité­ra­tion a été une réus­site ou un succès lors de la rétros­pec­tive. C’est unique­ment pour savoir où on va dans la boîte de temps qu’on s’est donnée. Rien de plus.

Quand on vous dit que ça permet d’être plus fiable, derrière se cache l’hydre du « on va trans­for­mer vos esti­ma­tions en enga­ge­ment » voire du « on va ajou­ter vos esti­ma­tions une à une et ça donnera la dead­line de fin de projet si rien ne change ».


Publié

dans

,

par

Étiquettes :

Commentaires

2 réponses à “Les esti­ma­tions de petites tâches ne sont pas plus précises”

  1. Avatar de Bruno

    Sur le fond, je suis bien d’accord, des estimations ne doivent pas devenir des engagements : ça ne marche jamais !

    Sur la forme, j’ai quelques remarques. D’abord, ce que l’on nous vend avec Scrum, ce n’est pas que chaque estimation sur une petite tâche est précise, c’est juste que si on a suffisamment d’estimations, les erreurs vont statistiquement avoir moins d’importance. On peut avoir 400% d’erreur sur une tâche, si elle est noyée dans un lot de 20 tâches de tailles plus ou moins égales, ça ne va pas faire une grosse différence sur le total. C’est le même principe que pour les mutuelles : elles assurent un grand nombre de personnes et même si une personne va à l’hôpital et coûte très cher à rembourser, sur le nombre de personnes, ça s’équilibre bien.

    Bref, on n’achète pas un mensonge évident (les estimations sur les petites tâches sont précises) mais une affirmation qui est plus facile à faire passer : si on découpe un gros projet en petites tâches, la somme des estimations pour les petites tâches sera plus précise que juste une estimation du gros projet. À titre personnel, je ne suis pas convaincu de cela, j’ai pu par le passé faire une première estimation d’un projet, puis la retravailler en découpant le projet en tâches, et l’estimation initiale au doigt mouillé était parfois meilleure que l’estimation plus détaillée (mais pas tout le temps). Je serais curieux de savoir s’il y a des études scientifiques sur ce sujet. C’est fort possible que cette affirmation soit vraie. Ceci dit, même si elle est vraie, les estimations restent trop imprécises pour devenir des engagements.

    1. Avatar de Sizvix
      Sizvix

      Découper en plus petites tâches permet aussi de voir mieux le moment où on prend du retard et donc de reporter dès ce moment là l’ESTIMATION de la fin du développement. Et de ne pas arriver à la fin de la durée estimée de la grosse tâche et de ne réorganiser le développement qu’à ce moment là … ( quand on a des contraintes de temps )

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *