Nous sommes nuls dans l'estimation de projets logiciels

Vous pouvez planifier, élaborer une stratégie, fragmenter un projet pendant d'innombrables heures, vous ne connaîtrez toujours pas les difficultés qui vous attendent pour écrire le code.

D'accord, alors je vais juste aller de l'avant et le dire :

Il est impossible d’estimer avec précision un projet logiciel d’une quelconque importance.

Maintenant, un nombre non négligeable d'entre vous vont lire cette phrase et penser que je suis fou. Et peut-être que je le suis (probablement). Mais quelqu'un doit simplement dire ce que nous savons tous être vrai mais que nous ne voulons pas admettre.

Écoutez, il y a eu d'innombrables livres écrits, d'innombrables conférences organisées, d'innombrables heures de conseil achetées et d'innombrables articles de blog écrits sur la façon de mieux estimer les projets. Je comprends. Nous travaillons tous sérieusement pour faire de notre mieux afin d'apaiser les patrons affamés qui veulent savoir quand une nouvelle fonctionnalité sera prête. Nous fixons tous des délais en fonction d'une date de conférence et non du moment où le logiciel sera réellement prêt.

Mais l’essentiel est que nous ne pouvons tout simplement pas le faire. Eh bien, nous pouvons le faire – en fait, nous le faisons tout le temps – mais nous ne pouvons pas le faire correctement. Autrement dit, nous avons toujours tort.

Je veux dire, nous continuons à dépenser de l'argent, à assister à des séminaires et à lire des blogs et des livres. Nous faisons appel à des consultants hautement rémunérés qui agissent comme s'ils savaient de quoi ils parlent. Mais ça ne s’améliore jamais. Nous sommes nuls et nous continuons de penser que nous pouvons nous améliorer et que la prochaine mode sera vraiment la solution miracle. Mais nous n’admettons pas ce que nous savons être vrai : nous ne pouvons pas du tout estimer les projets avec beaucoup de confiance.

Nous avons tous réalisé des projets dont nous pensions qu'ils prendraient un certain temps, mais qui finissent par prendre deux ou trois fois plus de temps. Vous avez peut-être été impliqué dans un projet qui s'est terminé dans la moitié du temps prévu. Mais il s’agit d’un projet rare et étrange qui se termine dans une fenêtre étroite autour de l’estimation originale réelle. Et puis, lorsque nous appliquons la loi de Hofstadter (« Cela prend toujours plus de temps que prévu, même en tenant compte de la loi de Hofstadter ») et doublons l'estimation, cela s'avère également faux.

Il y a des raisons pour lesquelles c'est le cas. Le plus important, et celui avec lequel je pense que la plupart des gens ont le plus de mal, est que chaque projet est unique avec sa propre longue liste d'« inconnues inconnues ». Vous pouvez planifier, élaborer une stratégie, fragmenter, plier, broyer et mutiler un projet pendant d'innombrables heures-personnes, et vous ne connaîtrez toujours pas les difficultés qui vous attendent pour écrire le code. Certaines choses que vous pensez difficiles se révéleront faciles. Mais le plus souvent, vous sous-estimerez considérablement le défi que posera tel ou tel aspect particulier du projet.

Bien sûr, cela se produit parce que le gestionnaire de projet moyen croira toujours que le chemin emprunté sera une autoroute plate et droite avec un temps agréable jusqu'à sa destination. Et ce n’est tout simplement jamais le cas. Les exigences changent, sans jamais réduire la taille du projet. Les gens prennent une prise de force inattendue. D’autres projets ou priorités interfèrent. Le service commercial a besoin de ce petit ajustement pour conclure une affaire importante. Rien n’est un fleuve tranquille du début à la fin. Jamais.

J'ai un ami titulaire d'un diplôme avancé en ingénierie informatique qui se met tellement en colère contre moi quand je dis cela, mais le vrai problème est que le développement de logiciels n'est pas une discipline d'ingénierie. Il s’agit plutôt d’un processus embourbé dans l’évolution des désirs humains, des personnalités et des dynamiques en interaction, une compréhension changeante des clients et des solutions non scientifiques. Le développement de logiciels est un processus créatif et non scientifique, et les efforts créatifs ne peuvent pas être réduits à des étapes connaissables et à un système reproductible.

Hé, je comprends que c'est difficile à entendre. Les entreprises – et j'entends par là les clients – ne veulent pas entendre « Eh bien, nous ne savons vraiment pas quand nous aurons cela pour vous. » Ils rechercheront des entreprises qui leur diront ce qu’ils veulent entendre, même si c’est complètement absurde. Les entreprises doivent gagner de l’argent et, pour ce faire, elles doivent produire de la valeur le plus tôt possible. Cette démonstration de la nouvelle fonctionnalité doit en fait avoir lieu lors de cette conférence à cette date particulière.

Et nous devons trouver comment accepter et vivre avec cela. Je dis cela parce que je pense qu'en tant qu'industrie, nous sommes depuis des décennies à la recherche du Saint Graal de l'estimation logicielle, et nous le serons toujours. Mais nous ne le comprendrons jamais. Nous ne le ferons tout simplement pas. Jusqu'à ce que nous parvenions à accepter cela, nous lutterons, nous débattrons et continuerons à nous dire quelque chose dont nous savons qu'il n'est tout simplement pas vrai.

Je n'ai pas de solution et je doute même qu'il y ait une solution. Accepter cela est la première étape pour résoudre un problème qui ne disparaîtra tout simplement jamais.

Merci de m’avoir lu!