[Lean Kanban France 2014] Real #NoEstimates project planning using Monte Carlo simulation

Monte Carlo

L’édition du Lean Kanban France réservait une nouvelle fois une série de conférences très prometteuses. Une de celles qui m’a vraiment interpellé est la session Real #NoEstimates project planning using Monte Carlo simulation. Sous ce titre barbare se cache la promesse d’une recette pour ne plus estimer un projet mais en utilisant des méthodes probabilistes inspirées de la méthode de Monte Carlo. J’ai donc ouvert la porte de la salle en me préparant à en ressortir avec un petit mal de crâne, enfin probablement….

Un retour d’expérience

Pour rentrer dans le sujet, notre orateur, Dimitar Bakardzhiev, nous plante le contexte de cette session. Il est directeur d’une société de développement bulgare qui est constamment confrontée à des clients qui arrivent avec une idée en tête et qui veulent juste un prix (budget) et une date (délai). Mais par expérience nous savons que les estimations s’éloignent vite du réel et comme nous ne pouvons pas prédire l’avenir, comment faire pour prendre en compte ces aléas ? Arrêtons-nous là un moment ; le titre de la session nous prédisait du No Estimate et nous parlons d’estimations… Pour expliquer cette contradiction, Dimitar nous explique sa vision du No Estimate qui se divise en trois types : pas d’estimation, pas d’estimation de l’effort, des estimations sans effort. C’est dans la troisième catégorie que nous nous trouvons ici.

Les classes de référence

Pour mettre en place le système d’estimation sans effort, il faut savoir ce que nous manipulons. L’hypothèse faite est de considérer les projets comme des systèmes Kanban qui représentent un ensemble de tâches à réaliser. La taille des tâches à traiter est considérée négligeable dans ce système, ce qui me paraît une hypothèse forte. Je trouve qu’on déplace une partie de l’effort d’estimation dans le découpage des éléments de travail. Certes, continuons. Le principe ici est donc de donner une idée du budget et du planning sans rentrer dans le détail et pour cela il introduit la notion de Classe de Référence soutenue par l’économiste Daniel Kahneman. Pour faire simple, une classe de référence est un ensemble de projets comparables entre eux.

comparaisons

Les critères de comparaisons sont, entre autres :

  • La structure et la taille de l’équipe
  • Les technologies
  • Les process de développement
  • Le type de client
  • Les domaines métiers

Métriques et mise en pratiques

Afin de calculer le temps mis pour les différentes tâches, Dimitar nous présente la notion de Takt Time. Le Takt Time représente le temps de production et de livraison. Il se différencie du temps de cycle par le fait que seul le premier élément d’un ensemble de livraisons aura un temps comptabilisé. Les Takt Time et le temps de cycle seront égaux si chaque élément fini est livré en déploiement continue par exemple.

TaktTime

 

Une fois cette métrique posée, il est possible de calculer le Takt Time moyen et de s’en servir pour estimer la durée de livraison du projet en posant simplement l’équation :

Temps de livraison = (Nombre de tâches à faire) * (Takt Time moyen)

Simple, non ? Notre estimation se résume à une multiplication d’une moyenne. Et bien c’est là que nous allons commencer à rentrer dans les détails mathématiques car l’équation est fausse. En effet, la valeur moyenne n’est pas représentative et va induire des écarts très importants. C’est à ce moment que Monte Carlo entre en jeu. Je vous renvoie sur la page Wikipédia pour le détail de la méthode, concentrons-nous sur son application dans notre cas.

A la place d’une valeur unique moyenne, nous allons utiliser des tirages aléatoires, suffisamment nombreux, pour obtenir des Takt Time moyens distribués. Bien entendu les temps sont à prendre parmi ceux déjà connus des projets comparables de notre classe de référence. Ces tirages aléatoires vont permettre de présenter une estimation basée sur des projets comparables et intégrant une part d’aléa matérialisée par la distribution aléatoire.

Courbe en Z

Pour complexifier un peu ça, il faut intégrer la phase projet dans nos estimations. En effet il est plus difficile de livrer au tout début d’un projet lorsque tout est à mettre en place. De la même manière, il y a moins d’éléments à livrer en phase de finalisation de projet.

Pour modéliser ce fait, on parle de la courbe en Z des projets :

  • 20% du temps pour 5% de travail finalisé à l’initialisation
  • 60% du temps pour 90% du travail environ
  • 20% du temps pour les 5% restant

 

Il s’agit donc de pondérer notre formule précédente et de séparer notre distribution aléatoire en fonction de ses différentes phases.

A partir de là, nous avons tous les éléments mathématiques promis et nous commençons à en voir la complexité. Pour finir de nous convaincre, la session se termine par un calcul d’estimation de projet simple sur Excel en utilisant les fonctions de probabilités.

Mon sentiment

Je sors finalement un peu déçu de cette session. J’attendais beaucoup de la partie No Estimate et je retrouve finalement un système de prévision complexe et avec des hypothèses fortes. Pour qu’un système à distribution aléatoire soit pertinent il faut une base conséquente de données de référence classées par Classe de Référence et phase projet. Il parait compliqué de mettre en place ce genre de données pour les utiliser rapidement. Un outil tel que Swift Kanban ou LeanKit semble proposer des fonctionnalités natives pour utiliser cette méthode et pour des résultats apparemment très satisfaisants. Par ailleurs outre l’outillage et la mise en place de la base de données j’ai l’impression qu’une partie de l’estimation est déportée sur le découpage en tâches, la répartition du nombre de tâches sur la courbe en Z et surtout sur la définition des classes de référence.

Il me faut encore un peu de recul pour utiliser ce genre d’estimation.

 

Pour le détail, vous trouverez le diaporama de la session ici :

http://www.slideshare.net/slideshow/embed_code/34569547#

Et la vidéo à suivre avec l’équipe du Lean Kanban France

 

Nombre de vue : 118

COMMENTAIRES 6 commentaires

  1. […] pouvez lire l’article de Pascal Poussard sur la session NoEstimates pour en savoir plus sur le sujet. Je vous laisse également consulter sur le site officiel […]

  2. Dimitar Bakardzhiev dit :

    Dear Pascal,

    As fas as Google can translate you have doubts that to forecast projects, features or epics you have to break them down to user stories. I agree that it requires quite significant analysis process and it can easily happen that great part of this effort will be a pure waste.

    That is why I experimented with a probabilistic approach for estimating the number of work items in a project. You can see it here http://www.slideshare.net/dimiterbak/probabilistic-project-sizing

    Please let me know what you think.

    Cheers,
    Dimitar

  3. Pascal Poussard dit :

    Hi Dimitar,

    Thanks again for your session at LKF and thanks to take the time to discuss this here with additional infos.

    I have no doubts that the law of large numbers can be applied to the software development.
    My concern is more about the match between this application on homogeneous work item and the real projects I’ve seen.

    To go on with your example I see most of a time not an estimate of the number apple on a apple tree but the estimate of all the fruits in one part of a wood, with different kind of tree and shrub.

    The real challenge would be to have standard size of item work and that seems to me the biggest work.
    With a correct and standard split up of items, the need of forecast could be even more simple, but I may miss something here.

    Best Regards
    Pascal

  4. Dimitar Bakardzhiev dit :

    The purpose of forecasting is to reduce uncertainty not to eliminate it. As I put it here http://www.infoq.com/articles/noestimates-monte-carlo

    “Present day’s project management paradigm…does recognize that uncertainty play a role in project management but believes uncertainty could be eliminated by a more detailed planning. We argue that planners could not know everything they needed to know and that the world as such is uncertain and every number is a random variable.”

    Dimitar

  5. Dimitar Bakardzhiev dit :

    Dear Pascal,

    Here is my article on probabilistic sizing: http://www.infoq.com/articles/probabilistic-project-sizing

    I will present the content at at LKNA15 in Miami on June 8th.

    Cheers,
    Dimitar

  6. Pascal Poussard dit :

    Thanks Dimitar,

    I will read this with pleasure.
    Unfortunately I will not travel to Miami but I hope for a french session at Lean Kanban France 2015

    Best Regards
    Pascal

AJOUTER UN COMMENTAIRE