Comment estimer le travail logiciel
(seangoedecke.com)- Estimer avec précision la durée d’un projet logiciel est impossible, et la plupart des travaux sont dominés par des « inconnues » imprévisibles
- Les estimations servent d’outil politique pour la direction plutôt que pour les ingénieurs, en aidant à décider des priorités de projet et de l’allocation des budgets
- En pratique, c’est l’estimation qui définit le travail : les équipes cherchent une approche technique réalisable dans le délai imparti
- Pour estimer efficacement, les ingénieurs doivent se concentrer sur la compréhension du contexte politique, l’évaluation des risques liés aux inconnues et la présentation de plusieurs scénarios d’exécution
- Cette approche privilégie la confiance et une collaboration réaliste plutôt que la précision, et met en avant la compétence d’ingénierie consistant à comprendre la structure décisionnelle de l’organisation
La fiction des estimations logicielles
- Dans le secteur, il existe une « fiction polie » selon laquelle une équipe expérimentée, avec suffisamment d’efforts, peut prédire précisément les délais
- En réalité, la plupart des ingénieurs savent qu’une prévision exacte est impossible
- Certaines équipes utilisent des tailles de t-shirt pour estimer, mais celles-ci sont finalement converties en unités de temps avant d’être transmises à la hiérarchie
- On emploie aussi des heuristiques irréalistes comme « prenez l’estimation initiale, doublez-la, puis ajoutez 20 % »
Pourquoi l’estimation est impossible
- Les petites tâches bien définies sont prévisibles, mais la plupart des projets s’exécutent dans des systèmes incertains et complexes
- Exemple : modifier le texte d’un simple lien peut être estimé à 45 minutes, alors qu’un changement dans un système à grande échelle ne le peut pas
- La majeure partie de la programmation est une activité de recherche exploratoire : on ne peut pas savoir à l’avance tout le travail nécessaire par la seule planification
- Les anciennes méthodes d’architecture centralisée ont échoué, et les décisions doivent être prises par les développeurs qui manipulent le code réel
- Au final, seuls 10 % du travail sont connus, les 90 % restants étant impossibles à estimer à cause de l’inconnu
L’estimation est un outil de direction, pas d’ingénierie
- Les estimations n’ont rien à voir avec l’amélioration de la productivité de l’équipe, et beaucoup d’équipes efficaces travaillent sans elles
- La direction cherche souvent à ajuster les estimations pour obtenir le résultat souhaité : un calendrier long subit une pression à la baisse, un calendrier court reçoit une demande d’ajout de marge
- Seuls les projets techniquement impossibles permettent parfois d’aboutir à un jugement réaliste
- Dans les domaines qui suscitent peu d’intérêt dans l’organisation, les procédures formelles peuvent simplement rester inchangées
- Ainsi, les estimations fonctionnent comme un outil politique permettant à des non-ingénieurs de sélectionner ou d’annuler des projets
L’estimation définit le travail
- Contrairement à l’idée courante, ce n’est pas le travail qui détermine l’estimation, c’est l’estimation qui est fixée d’abord, puis l’approche technique adaptée est choisie
- Exemple : l’approche pour implémenter une fonctionnalité de type « discuter avec un PDF » en six mois n’a rien à voir avec celle d’une implémentation en une journée
- La contrainte de temps détermine la profondeur et la qualité de la conception du code, et les ingénieurs choisissent la solution possible dans la fenêtre donnée
Comment on estime réellement
- Il faut d’abord comprendre le contexte politique afin d’identifier l’importance du projet et le calendrier attendu
- Ensuite, on explore les approches possibles à partir d’un délai déjà fixé
- Plus il y a d’inconnues (
unknowns), plus l’estimation grossit, et plus il faut réduire le périmètre de l’approche - Au final, on présente non pas une durée exacte, mais une évaluation des risques et plusieurs scénarios d’exécution
- Exemple : tout résoudre directement, contourner certains points, demander l’appui d’une autre équipe, etc.
- Le rôle de l’ingénieur n’est pas de répondre à « combien de temps cela prendra ? », mais à « quelles méthodes sont possibles dans le délai donné ? »
Objections et réponses
- Certains ingénieurs évitent d’estimer dans des conditions incertaines, mais cela conduit simplement à laisser des non-techniciens faire l’estimation à leur place
- Une attitude consistant à être constamment dans l’opposition plutôt que de coopérer avec la direction est contre-productive et affaiblit la confiance
- Les équipes qui ne ressentent aucune pression se trouvent peut-être simplement dans une zone qui échappe à l’attention de l’organisation
Conclusion
- En pratique, les managers abordent déjà l’équipe avec un délai en tête, et l’équipe cherche une solution technique réalisable dans ce cadre
- L’estimation est un outil de négociation entre dirigeants, et seuls les projets impossibles servent exceptionnellement à faire remonter la réalité
- Une bonne estimation doit inclure non pas un chiffre précis, mais la présentation des risques et des options
- Une estimation exacte du travail logiciel est impossible, et une estimation réussie dépend de la capacité à reconnaître et gérer les risques liés à l’inconnu
2 commentaires
Oh oh
Commentaires sur Hacker News
Je partage mon barème d’estimation de projet un peu humoristique
Pour les projets internes (par ex. migration de fournisseur, sans impact utilisateur), on prévoit autant de temps qu’on peut en faire accepter au manager
Pour les projets ayant un impact utilisateur (par ex. ajout de nouvelles fonctionnalités), on continue tant que le ROI reste positif
Pour les projets nécessitant une collaboration avec des partenaires externes, l’équipe commerciale fixe la date de livraison, et l’équipe d’ingénierie ajuste légèrement la définition du MVP pour tenir l’échéance
Je me demandais pourquoi personne ne parlait de planning poker ou de story points
Ce n’est pas parfait, mais c’est une méthode assez bonne. Toutes les tâches doivent être terminées dans le sprint, et si elles sont trop grosses, il faut les découper
Toute l’équipe doit se mettre d’accord sur les points, et c’est là que naît la vraie valeur de la discussion
Au bout de quelques mois, la vélocité de l’équipe se stabilise et on peut prévoir avec une précision d’environ ±10 %
Ce n’est pas magique, mais cela permet de livrer de la valeur de façon régulière et de réévaluer à chaque sprint le rapport coût/bénéfice
Une personne qui vient d’arriver peut mettre plus de deux fois plus de temps sur le même ticket
En plus, l’organisation crée des règles comme terminer les reviews de PR en 24 heures, ce qui crée un décalage avec la réalité
Les développeurs et la QA estiment ensemble en comparant la complexité, et la QA évalue la difficulté des tests ou les possibilités d’automatisation
Grâce à cela, les indicateurs de vitesse de développement sont stables et les estimations par version sont assez précises
Cela n’a de sens que si toute l’équipe partage une compréhension commune de l’unité minimale et peut la convertir en temps
Mais à ce moment-là, autant utiliser directement le temps, donc les points eux-mêmes deviennent inutiles
J’estime en posant la question en unités de « 2 heures, 2 jours, 2 semaines, 2 mois, 2 ans », avec une approche fondée sur les intervalles de confiance
Si la plage est trop large, on découpe davantage ; et si ce n’est pas possible, on évalue si cela vaut la peine de passer du temps à collecter plus d’informations
Sinon, on abandonne le projet
Si l’on définit clairement le résultat attendu et qu’on découpe l’idée en étapes détaillées, on peut faire des estimations réalistes
Si on n’arrive pas à descendre au jour ou à la semaine, c’est qu’on est encore dans un état de planification insuffisant
Dans ce cas, j’ai l’impression qu’il est difficile d’estimer, puisqu’on est justement dans un processus d’apprentissage par essais d’approches différentes
Cela pousse à raisonner en termes d’action plutôt qu’en simple estimation de durée
Autrefois, j’avais prévu un sprint pour une simple migration des mots de passe du texte en clair vers le hash, mais en réalité cela a pris 6 mois
On l’a découvert parce qu’un client a montré en vidéo qu’il utilisait son mot de passe sans distinction entre majuscules et minuscules
Et en plus, une image PHP a été supprimée, provoquant aussi un échec de build
L’estimation est toujours une aventure passionnante
Il montre des statistiques de dépassement budgétaire fondées sur des données réelles de projets
Les projets IT dépassent en moyenne de 73 %, ce qui en fait le quatrième pire secteur après les sites de stockage nucléaire, les Jeux olympiques et l’hydroélectricité
18 % des projets IT dépassent de plus de 50 %, et leur dépassement moyen est de 447 %
Cela montre qu’au final, dans la plupart des secteurs, les estimations sont structurellement optimistes
Je trouve étonnant que beaucoup d’ingénieurs et de managers ne fassent pas leurs estimations à partir des métriques de projets passés
En regardant les données de débit de l’équipe, on peut calculer une durée approximative et des intervalles de confiance (par ex. 90 %, 70 %, 50 %)
Cela permet aussi de donner aux parties prenantes externes un contexte probabiliste
Mais beaucoup d’ingénieurs considèrent cela comme une charge administrative
Une bonne pratique consiste à utiliser des estimations par intervalle, en modélisant trois cas comme dans la méthode PERT : meilleur cas, cas attendu et pire cas
Plus un technicien est excellent, plus il a tendance à surestimer sa capacité à estimer son propre temps
Une méthode où chacun estime puis applique une correction de 20 % a plutôt bien fonctionné
Quand la direction impose un calendrier, il faut expliquer ce qu’il est possible de faire dans ce délai, ou proposer une réestimation après clarification du périmètre
Référence : PMI PMP, Lessons Learned Repository du PMBOK
La prediction permet d’apprendre via l’erreur, tandis que la prescription se transforme au contraire en pression sur la productivité
Je vois l’estimation comme un processus de négociation
Comme pour les finitions automobiles, je propose trois options : Economy, Mid-tier, Luxury
Le business veut toujours les fonctionnalités du niveau 3 avec le budget du niveau 1, donc au final j’ajuste en fonction de la situation
Avoir un plan n°1 prêt permet de basculer rapidement en cas de crise, et de visualiser pendant la négociation le coût des raccourcis
Grâce à cela, j’ai pu éviter plusieurs fois des décisions irrationnelles de PM ou de dirigeants pris de panique
Je travaille sur de grands systèmes distribués de niveau FAANG, et dans ce contexte des estimations précises sont presque impossibles
Il y a trop d’unknown-unknowns, et même un prototype nécessite déjà énormément de données et de temps
Donc au lieu d’estimer, je me concentre sur la gestion de l’incertitude
La méthode la plus fiable consiste à comparer avec des projets similaires
Du genre : « c’est 20 % plus complexe que le projet X, donc cela prendra 20 % de plus »
Mais pour cela, il faut enregistrer de manière continue les données réelles de durée des projets passés
Au départ, je voulais m’opposer à l’idée que « les estimations sont impossibles », mais j’ai fini par comprendre qu’en pratique le rôle de l’organisation est plus important
Même si l’équipe juge, en comparant estimation et capacité, que ce n’est pas faisable, le calendrier ne change pas
Au final, on s’adapte par réduction du périmètre ou compromis sur la qualité
Donc il est peut-être plus exact de dire que « les estimations sont inutiles »
J’ai l’impression que le cœur de l’estimation, c’est l’ambiguïté
Des choses qui semblent petites, comme des ajustements fins d’UI, sont en réalité souvent des travaux où l’on apprend en avançant
À l’inverse, même un gros changement peut être terminé vite s’il est clairement défini
À l’ère des LLM, plus que l’ampleur du changement, c’est le degré d’incertitude qui déterminera le temps nécessaire