Pourquoi est-ce si dur d'estimer le temps de développement ?

Beaucoup de développeurs juniors que je rencontre m'avouent avoir une difficulté majeure dans leur travail de tous les jours : estimer le temps de développement d'une fonctionnalité ou d'un projet au complet. Ma réponse est très simple :

C'est normal.

La première cause étant que les développeurs qui souffrent d'un manque d'expérience n'ont pas les bagages techniques nécessaires pour réaliser une estimation correcte du temps.

Ce n'est pas pour rien que la racine du verbe "prévoir" c'est "voir", pour prévoir quelque chose il faut déjà l'avoir "vu" au moins une fois !

Mais ce n'est pas tout, car même si l'on s'améliore avec le temps et avec l'expérience cela ne veut pas dire qu'en devenant un développeur confirmé ou sénior nos estimations serons justes 100% du temps, loin de là.

La différence entre le temps estimé et le temps effectif peuvent différer à cause de nombreuses raisons, parmi lesquelles :

La complexité cachée

Il arrive que certaines fonctionnalités basiques à première vue aient été proposées en option au client sans consulter l'équipe technique (ce qu'il ne faut évidemment pas faire) mais qui renferment en fait une complexité bien plus importante.

Prenons l'exemple d'une "simple" barre de recherche par exemple : une telle fonctionnalité sur une liste fixe d'éléments (ou une liste très réduite) s'implémentera effectivement en quelques lignes de code avec un affichage conditionnel.

Mais pour gérer une recherche textuelle dans une liste de ressources complexes et dont le nombre augmente au fur et à mesure de la vie de l'application, il faudra sans doute mettre en place un moteur de recherche externe comme ElasticSearch, lequel devra être synchronisé avec la base de données et rendra l'architecture du projet bien plus complexe.

La complexité accidentelle

Appelée "Accidental Complexity" en anglais, cette notion correspond à la complexité additionnelle liée au projet au fur et à mesure de son développement et à prendre en compte lors de la création d'une nouvelle fonctionnalité.

Par exemple une feature X pourra être très simple à développer dans un projet vierge, mais dans un projet basé sur une architecture complexe avec des dizaines de modules métiers et des dizaines de milliers de lignes de code, la même feature mettra un temps beaucoup plus important pour être intégrée.

Cette complexité est compliquée à estimée de par sa nature, mais aussi car il faut déjà très bien connaitre le projet et l'état de l'existant afin de pouvoir l'évaluer.

La différence de vision

Si vous demandez à plusieurs développeurs d'estimer le temps de développement de la même fonctionnalité, vous pouvez vous retrouver avec des différences qui vont du simple au triple, voir plus parfois.

Les raisons citées précédemment peuvent en être la cause, mais il y a aussi un biais dans cette démarche, car l'on pense souvent que l'estimation la plus courte sera donnée par un développeur sénior qui saura tirer profit de son expérience.

Mais au contraire, il arrive que plus un développeur soit expérimenté, plus ses estimations soient longues, car il n'aura plus seulement la vision de la fonctionnalité lorsque toutes les conditions sont réunies pour que tout se passe bien (aussi appelé le "happy path"), mais il sera en mesure de prévoir tous les cas spéciaux où il faudra être vigilant lors de l'implémentation (les fameux "edge cases").

Voilà donc quelques raisons qui pourront vous aider à comprendre pourquoi il est très difficile (voir impossible) d'estimer précisemment le temps de réalisation d'un projet en tant que développeur, junior comme sénior.