- 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
Aucun commentaire pour le moment.