Appuyez sur Entrée pour voir vos résultats ou Echap pour annuler.

Pourquoi c’est impossible d’estimer un projet

Je crois sincèrement qu’il est impossible d’estimer un projet en développement logiciel. Maintenant que j’ai affirmé cette horreur, permet-moi de t’expliquer pourquoi. Mais avant toute chose, j’aimerais te remercier de nous lire chaque semaine 🙂 Hésite pas à t’abonner pour recevoir les nouveaux articles par courriel. On a jamais envoyé un seul courriel de sollicitation en 4 ans.

Estimer en heures ou en j/p

Avant de pouvoir justifier le fait qu’il est impossible d’estimer un projet de façon précise en heures ou en jours-personne, il va falloir que j’explique ce qui fait que le développement logiciel est différent d’un autre domaine comme la construction.

Coder est un art

C’est assez difficile à conceptualiser parce qu’on a encore des gros préjugés envers l’informatique. Si on oublie la logique, l’algorithmie, les outils que les programmeurs utilisent, nous sommes des gens qui passent leur temps à taper du texte dans un logiciel qui ressemble beaucoup à un logiciel de traitement de texte :

(oui je code en rose… shhhhhhhh 🤫)

Oublie tous les boutons, le menus, etc.. Il reste la section du centre. C’est là que ça se passe. C’est là qu’on tape frénétiquement des lignes sans arrêt de 9 à 5…

Je me permets donc de faire cette comparaison. Imaginons que nous sommes des écrivains. Je te pose la question suivante :

Combien d’heures ça te prendrait pour m’écrire un roman?

Ça semble assez logique qu’il est impossible de répondre à cette question parce qu’il manque de détails. Jusque là tout va bien, on prend les requis concernant le roman un peu plus en détails, on essaie de comprendre le genre d’histoire que le client veut, mais en bout de ligne, on sort un chiffre de notre chapeau.

Mettons… 6 semaines?

Maintenant, il faut tenter de prévoir l’imprévisible. Et si une journée, il se passe quelque chose dans la vie de l’écrivain et qu’il n’arrive pas à écrire, que l’inspiration ne lui vient pas ou qu’il n’arrive pas écrire ce paragraphe-là à son goût?

Bon ok… mettons 7 semaines pour être sûr!

Et si le client n’aime pas l’histoire? Aussi bien lui montrer périodiquement pour faire des ajustements en live. Soyons Agile 😀

Donc… 9,1 semaines incluant les échanges et correctifs avec le client.

Mais là… pas le temps de répondre à ses mails, aux textos du client, de pause pipi rien. Pis… entre toi et moi, 9,1 semaines c’est laid, on va arrondir à 10.

Donc l’écrivain pense pouvoir écrire un roman en 6 semaines, mais il se protège pour toutes les incertitudes en ajoutant 4 semaines de contingence à son estimé, soit 40%. C’est ici que tout s’explique.

La contingence

La contingence sert à mesurer l’incertitude à l’aide de statistiques. Si l’écrivain pouvait garder un chiffrier Excel avec son estimé initial et le nombre que temps que ça a pris réellement, on pourrait à la longue sortir une moyenne avec un écart type et une intervalle de confiance, comme ça l’écrivain pourra dire :

Selon mon historique personnel, quand je pense à un roman de 6 semaines, ça prend en moyenne entre 5 et 8 semaines 95% du temps.

Et il est là le problème avec l’estimation en heures.

  • Pour être précis, il faut beaucoup de données, donc avoir préalablement réalisé et mesuré le temps d’écriture de plusieurs centaines romans
  • Chaque personne a sa propre contingence selon son type de personnalité (optimiste ou non, confiance en soi, etc.)
  • La plupart du temps, la personne qui estime n’est pas celle qui exécute

Bon… impossible d’être précis. Imagine si c’était un roman où plusieurs personnes travaillent, comment ça pourrait devenir complexe de penser aux échanges entre les auteurs, les meetings qui s’étirent parce qu’ils s’obstinent sur un chapitre, etc..

Et le pointage Agile?

Ah! Mes petits fervents de l’agilité vont probablement défendre le système de pointage auquel j’adhère à 100%. Par contre, le même problème s’impose.

Une autre technique d’estimation consister à estimer en « point », une unité abstraite qui représente la complexité de la tâche à accomplir. Par exemple, dans un roman, le dernier chapitre nécessite probablement plus d’effort qu’un pris au centre. Donc ici, au lieu de dire qu’on va prendre 14 heures écrire le dernier chapitre, on va dire que le dernier chapitre a un poids de 8 points, par exemple.

L’avantage du point par rapport à l’heure, c’est qu’il contient en théorie tout ce qui est imprévisible, mais qu’on peut quand même les comparer entre eux. Par exemple, si je sais qu’un paragraphe qui contient de dénouement d’une péripétie de l’histoire me prend plus de temps qu’un autre, on lui assignera simplement un pointage plus élevé.

Donc j’arrive à 214 points pour ce roman-là!

C’est là que le client demande : Ok, mais combien ça coûte?

Eh bien pour lui répondre, on doit encore utiliser les statistiques… On reprend un chiffrier Excel avec l’estimé initial en points et le coût réel du projet. Ensuite on peut calculer un coût moyen par point pour estimer les projets futurs.

Vous voyez le pattern? Qu’on estime en points ou en heures, on dépend d’un historique pour être précis. Cet historique-là dépend des gens qui font partie de l’équipe. Plus l’équipe bouge, plus il faut des données.

C’est quoi la solution alors?

La solution peut paraître simple, mais si elle l’était vraiment, je ne serais pas en train d’écrire ceci! Au lieu de dire :

Je veux un roman, combien ça me coûte? »

Il faut dire

J’ai 5000 $, je veux un roman. Est-ce que tu es capable?

Un peu comme l’achat d’une maison. J’ai un budget de x$, qu’est-ce que je peux avoir de mieux pour ce montant. Ça semble bon comme solution, mais pour répondre à « es-tu capable? », il faut quand même se baser sur des statistiques. La réponse à « es-tu capable? », c’est aussi « Oui, et je suis confiant à 90% »…

Conclusion

Donc aujourd’hui, l’objectif de l’article était de démontrer que les deux techniques d’estimation de projets en développement logiciel ne peuvent pas être précises par définition. Si tu sors un estimé à 90% de confiance, alors 1 projet sur 10 va soit prendre beaucoup moins de temps ou beaucoup plus de temps que la moyenne des autres projets. Puisque l’intervalle de confiance dépend d’incertitudes, il est même impossible de prévoir si le projet va être en déficit ou en surplus. On peut juste savoir qu’on a une chance sur 10 de s’être trompé. Est-ce que ton client est chanceux?

Je suis spécialement intéressé de savoir vos trucs en commentaires! Merci de partager dans vos réseaux 🙂

Suivez-nous par courriel!

Saisissez votre adresse courriel pour vous abonner au blog d'Ezo et recevoir une notification de chaque nouvel article par email.

Rejoignez 30 autres abonnés