Le danger des estimations en dev

Introduction

Dans l'industrie du développement logiciel, les estimations sont considérées comme un pilier de la gestion de projet. Pourtant, elles reposent sur des hypothèses fragiles et coûtent cher en temps et en énergie. Cet article explore pourquoi les estimations sont surévaluées, et en quoi elles peuvent nuire au processus de développement.

L'illusion de la précision

Les estimations créent une illusion de contrôle dans un domaine imprévisible. Cette fausse précision conduit à des attentes irréalistes, des déceptions, et une perte de confiance entre les équipes et le management.

"Les estimations sont le plus grand mensonge que nous nous racontons dans l'industrie du logiciel."

Le coût des estimations est réel. Une étude a montré que les développeurs passent en moyenne 20% de leur temps à estimer. C'est du temps qui n'est pas consacré à produire de la valeur.

Le stress lié aux estimations contribue au burnout, à une baisse de la qualité du code et à un turnover élevé. Un prix lourd pour une illusion de contrôle.

Estimations et agilité, une contradiction

Dans un contexte agile, les estimations sont un frein. Elles orientent les développeurs vers le respect des délais plutôt que vers la qualité du produit.

Les estimations à long terme sont particulièrement problématiques : elles deviennent obsolètes avant même d'être finalisées. L'agilité demande de l'adaptabilité, une qualité que les estimations rigides ne permettent pas.

Les avancées en développement logiciel viennent souvent d'explorations imprévues, de détours créatifs qu'on ne peut ni planifier ni estimer. Imposer des contraintes artificielles basées sur des estimations ferme la porte à ces opportunités.

L'obsession des estimations encourage aussi une mentalité de "feature factory", où le succès se mesure au nombre de fonctionnalités livrées plutôt qu'à la valeur apportée aux utilisateurs. Le résultat : des produits surchargés, difficiles à maintenir et déconnectés des besoins réels.

Le mythe de la comparabilité

Un argument courant en faveur des estimations : elles permettraient de comparer les projets et d'améliorer la planification future. En pratique, chaque projet a ses propres défis, son propre contexte et sa propre dynamique d'équipe. Se baser sur des estimations passées est trompeur.

L'alternative, c'est de se concentrer sur la valeur. Au lieu de passer du temps à estimer, on peut :

• Livrer de la valeur en continu avec de petits incréments, ce qui permet un feedback rapide et une adaptation constante.

• Prioriser par impact avec des méthodes comme le "value streaming" ou le "impact mapping" pour identifier ce qui apporte le plus aux utilisateurs.

• Communiquer sur les progrès, les obstacles et les opportunités plutôt que sur des dates estimées.

• Mesurer les résultats (adoption, satisfaction, impact business) plutôt que le respect des délais.

Cette approche aligne mieux le développement avec les objectifs de l'entreprise et les besoins des utilisateurs.

Ce qu'il faut retenir

• Les estimations créent une illusion de contrôle dangereuse : les développeurs passent en moyenne 20% de leur temps à estimer au lieu de créer de la valeur, avec un stress qui dégrade la qualité du code.
• L'obsession des estimations encourage une mentalité "feature factory" où le succès se mesure en fonctionnalités livrées plutôt qu'en valeur réelle apportée aux utilisateurs.
• L'alternative : livrer de la valeur continuellement en petits incréments, prioriser par impact business (value streaming, impact mapping), et mesurer les résultats plutôt que le respect des délais.

Questions fréquentes

Comment planifier sans estimations ?

Adoptez une approche itérative avec des livraisons fréquentes de petits incréments de valeur. Priorisez par impact business plutôt que par complexité estimée. Communiquez les progrès, obstacles et opportunités de manière transparente au lieu de donner des dates.

Les estimations sont-elles toujours inutiles ?

Les estimations grossières (T-shirt sizing) peuvent aider à la priorisation initiale. Ce qui est toxique, ce sont les estimations précises (en heures/jours) utilisées comme engagements contractuels. Plus l'estimation est précise, plus elle est fausse et génère de la pression contreproductive.

Comment convaincre son management d'abandonner les estimations ?

Proposez un pilote : une équipe qui travaille par flux de valeur pendant un trimestre, avec des métriques centrées sur l'adoption utilisateur et l'impact business plutôt que le respect des délais. Les résultats parlent d'eux-mêmes.

Conclusion

Les estimations précises en développement logiciel coûtent cher pour un bénéfice discutable. Elles créent une fausse impression de contrôle, génèrent du stress et détournent l'attention de ce qui compte : livrer de la valeur aux utilisateurs.

Le changement de mentalité demande un effort à tous les niveaux de l'organisation. Mais les équipes qui mesurent leur succès par l'impact réel plutôt que par le respect des délais estimés produisent de meilleurs résultats.