La planification traditionnelle (waterfall) d’un développement logiciel peut être comparée à un voyage en voiture. Le chef de projet s’appuie sur une méthodologie et les expériences passées afin de définir un plan expliquant, étape par étape, les directions à prendre, les différents obstacles qui vont être rencontrés et comment les appréhender, et le rôle des membres de l’équipe (je conduis, tu tiens la carte, qui s’occupe de la subsistance …). La distance étant connue, une règle permet de calculer le coût. Les limitations légales de vitesses étant connues, le temps du parcours peut être calculé. De plus, la qualité (se rendre du point A au point B) fait partie des spécifications initiales. Le triangle du projet est donc connu.

Lorsque l’équipe de projet démarre son voyage du point A, la densité du  trafic peut déprendre  de l’horaire. La vélocité calculée peut-être, sur certains tronçons, bien en deçà de la vélocité planifiée. De plus, l’équipe peut faire face à des obstacles non planifiés : le plan me dit de prendre la première sortie au rond-point, mais des travaux m’en empêche. Que faire, et le plan qui ne donne pas de solution. La voyage prend du retard … De plus, le plan, basé sur l’expérience d’un trajet  passé, indique un raccourcit. Problème : entre-temps la signalisation a été changée, et la route n’est plus utilisable. Les coûts et délais prennent l’ascenseur. Tout cela sans imager un changement dans la qualité (tout compte fait, après trois jours de voyage, le client décide de faire un léger détour par une région limitrophe …), et la rendement de l’équipe (le chauffeur, un membre de l’équipe,  se fatigue après 2 heures de conduite, et perds sa concentration). Le modèle traditionnel montre donc ses limites.

Le chef de projet ne comprend pas : il a utilisé une méthodologie réputée, et l’a suivi à la lettre. Puis il se tourne vers l’équipe de projet, qui forcément n’a pas suivi le plan … Alors que celle-ci a simplement dû faire face, durant la vie du projet, à une série de problèmes l’empêchant d’avancer. Et elle a fixé ces problèmes, tout en suivant, le mieux possible, le plan définit.

Comme l’a dis Eisenhower : “No battle was ever won according to plan, but no battle was ever won without one” .

Un mixe d’une technique d’estimation (temps) des tâches et des mathématiques des probabilités donne une règle relativement simple :
• Dans 99,73% des cas, la tâche sera terminée dans le temps estimé +- 1 déviation standard
• Dans 95,44% des cas, la tâche seta terminée dans le temps estimé +- 2 déviations standard
• Dans 68,26% des cas, la tâche sera terminée dans le temps estimé +- 3 déviations standard

La probabilité que l’estimation initiale soit correcte est donc très faible.

Prenons donc l’exemple d’une tache A : réalisation d’une application mobile.

La technique d’estimation de la tâche est la technique dite des trois points : l’estimation est effectuée par trois sources différentes. Cela donnera trois valeurs :
1. Optimiste (38 jours) : Dans notre exemple, un développeur qui désire ardemment effectuer ce développement et donc qui inconsciemment sous-estime la tâche afin d’obtenir le travail
2. Pessimiste (57 jours) : Dans notre exemple, un développeur qui ne désire pas effectuer ce développement et qui donc surestime la tâche afin qu’elle ne lui soit pas attribuée.
3. Moyenne (45 jours) : L’estimation normale

La formule pour obtenir l’Expected Value est la suivante :
(Optimiste + Pessimiste + (4 * Moyenne)) / 6
Soit :
EV = (38 + 57 + (4 * 45)) / 6 = 45.83 jours

La formue pour obtenir la Deviation Standard est la suivante :
(Pessimiste - Optimiste) / 6
Soit :
SD = (57 – 38) / 6 = 3.17 jours

Pour reprendre la règle ci-dessus :
• Il y a 68,26% de probabilité que la tâche soit effectuée entre 42.66 et 49 jours
• Il y a 95,55% de probabilité que la tâche soit effectuée entre 39.49 et 52.17 jours
• Il y a 99,73% de probabilité que la tâche soit effectuée entre 36.32 et 55.34 jours