Le cône d’incertitude, décrit par Steve McConnel, montre ce que tout professionnel expérimenté du logiciel sait. Ce qui est au début de tout projet, nous ne savons pas exactement combien de temps un projet va prendre.
Les raisons pour cela sont nombreuses. Aucun projet n’a jamais :
- les mêmes exigences.
- les mêmes personnes.
- le même contexte d’affaires.
- la même technologie.
- les mêmes priorités& contraintes.
Chacun est unique. Chaque ligne de code est faite à la main. Et le travail de connaissance impliquant des personnes créatives intelligentes ne se prête pas à la précision comme le fait le creusement de fossés.
Pourtant, la précision est ce qui est demandé. Les sponsors veulent savoir exactement quand le projet sera terminé, et combien il coûtera.
Gérer cette énigme est presque aussi vieux que le temps lui-même. Voici quelques façons dont les équipes et les entreprises gèrent cette incertitude.
Gérer le cône
Pad l’estimation
Après avoir ressenti la piqûre de la sous-estimation, une réaction commune est de doubler ou tripler l’estimation la fois suivante. Cela réduit définitivement le risque initial, mais gonfler les chiffres est plus difficile qu’il n’y paraît.
Donnez un chiffre trop élevé, et les sponsors rechigneront et n’approuveront pas votre projet. Donnez un chiffre trop bas et vous risquez de manquer d’argent. Cela devient doublement risqué lorsque vous soumissionnez sur des contrats à prix fixe où il y a encore plus de pression pour garder les chiffres bas.
La plupart des projets ajoutent une sorte de rembourrage sur les chiffres finaux pour se donner une marge de manœuvre suffisante. Une autre chose que les équipes peuvent faire est de comparer ce projet avec d’autres.
Dimensionner le projet relativement
Les humains sont vraiment bons pour dimensionner les choses relativement. Nous ne pouvons pas vous dire précisément quelle est la taille d’une pierre. Mais nous pouvons vous dire quelle est sa taille par rapport à quelque chose d’autre. Nous pouvons utiliser cela pour dimensionner les projets aussi.
Soyez franc et honnête
Le mode de fonctionnement par défaut d’Agile est la transparence et la visibilité. Il ne devrait donc pas être surprenant que la façon Agile de traiter le cône soit d’être franc et honnête.
Regardez. Nous ne savons pas combien de temps cela va prendre. C’est notre meilleure supposition. Mais si vous nous donnez quelques itérations, nous pouvons construire quelque chose, mesurer combien de temps cela prend, et ensuite dire vous donner un bien meilleur sens de la taille de cette chose.
Une autre approche que certaines équipes Agile prendront pour aider à communiquer l’incertitude est de présenter les estimations comme une fourchette.
Cela a l’avantage de montrer visiblement aux sponsors l’incertitude qui accompagne le projet, et de laisser ensuite les sponsors décider de la quantité de risque qu’ils peuvent se permettre d’assumer.
Financer de façon incrémentale
Une autre approche qui a beaucoup de sens, mais que je ne vois malheureusement pas appliquée assez souvent, est le financement incrémental.
Avec le financement incrémental, vous ne demandez pas tout le sac d’argent au départ. Seulement assez pour faire des pointes dans une partie suffisante du travail, pour rapporter un meilleur chiffre sur le temps que cela va prendre.
Ce n’est pas infaillible. Vous pouvez toujours avoir des problèmes plus tard. Mais en donnant aux équipes 30-50K $, en les laissant construire quelque chose et en voyant combien de temps cela prend, cela peut grandement contribuer à réduire la variance de ce chiffre initial.
Vous pouvez en savoir plus sur cette façon de planifier et les avantages qu’elle apporte dans Beyond Budgeting
La cause profonde
Nous vivons dans un monde de budgets annuels. Et malheureusement, cela conduit à une grande partie de la tension et du drame dans notre lieu de travail. À certains égards, les budgets annuels sont naturels (nous vivons et suivons le temps dans des cycles annuels), mais à d’autres, ils sont terribles pour la planification, car une année est une longue période sur le marché.
Si vous vous retrouvez à vous faire piéger par le cône d’incertitude, rappelez-vous simplement que tout l’intérêt de l’estimation logicielle est de déterminer si le projet est même possible.
Ou comme le dit Steve McConnell :
Le but premier de l’estimation logicielle n’est pas de prédire le résultat d’un projet ; c’est de déterminer si les objectifs d’un projet sont suffisamment réalistes pour permettre de contrôler le projet afin de les atteindre.
-Steve McConnell, Software Estimation : Démystifier l’art noir
.