Antoine.Guiral.Info

En ce moment je suis confronté à plusieurs problèmatique concernant l’estimation d’un projet et ce qui en découle (les devis entre autre). C’est un exercice auquel nous sommes peu souvent confronté et qui se révele être très difficile.

Dans le contexte dans lequel je me trouve les contraintes sont les suivantes :

• analyse et temps de devisage très court (coût supporté par l’entreprise et non pas par le client…)
• date de livraison fixe
• périmetre du projet fixe (ce qui a été devisé doit être livré à la bonne date )

Ce qui en découle est que les devis étant fait rapidement, ils sont souvent approximatifs et bien en deça des temps réels. L’entreprise a donc un surcout relativement important a supporter. D’autre part les dates de mise en production deviennent très dures à respecter.

Dans le livre « agile estimation and planning » de mike cohn (un des gourous des methodes agiles) j’ai trouvé un bon exemple qui stigmatise ce problème.

Si je vous demande d’estimer le temsp que vous mettrez pour lire un livre, a première vu vous serez juste me dire si c’est un roman, un essai, une nouvelle ce qui vous donnera un ordre d’idée approximatif. Puis vous regarderez le nombre de pages. Ce qui vous permettra d’affiner votre estimation.

A ce moment il fait une très net difference entre l’estimation de l’étendue du projet (le livre pour l’exemple) et l’estimation du temps necessaire pour le réaliser. L’estimation du temsp necessaire à sa lecture prend en compte d’autre paramètres tels que la taille des caractères, le nombre de lignes, la taille des marges, la facilité que vous aurez à lire ce livre là, etc etc.

Entre en jeu une deuxième donnée. Vous commencez à lire le livre et vous constatez que vous mettez un certaain temsp a lire 1 page. Disons 2 minutes. Dès lors vous êtes capable de donner une estimation beaucoup plus précise du temps necessaire pour achever sa lecture en multipliant votre vitesse par le nombre de pages!

Autrement dit, évaluer le temps necessaire à réaliser un projet sans le connaitre est mission impossible.

Plusieurs cas peuvent alors se présenter. On vous donne une date limite pour le lire. Vous lisez jusqu’a cette date et vous le rendez en ayant lu les 3/4. L’équivalent dans une entreprise serez une deadline fixe et la livraison d’un produit fonctionnel ne contenant pas toutes les fonctionnalités. L’autre option est qu’on vous dise, termine le livre et rends le moi quand tu l’auras fini. Vous avancez une date approximative que vous tenterez de respecter. Besoin de parallele? LE client veut son produit entierement fini pour cela il est souple sur la date de livraison dans la limite du raisonnable.

Quelles conclusions tirer? Je pense que dans tout les cas il est nécessaire d’avoir une variable. Soit la date de livraison, soit le nombre de fonctionnalité. Si toutes les données sont fixe l’estimation est vouée à l’echec. Les methodes agiles permettent de s’adapter dans tout les cas (les itérations permettent de livrer un produit utilisable à chaque fois et donnent la vélocité qui permet d’estimer le nombre d’iterations restantes pour boucler le projet). Au contraire l’utilisation de méthode traditionnelles (bien rigide comme peut l’etre merise) nous donne une foultitude (dédicasse à mr goumi) d’exemple de retard de livraison (même dans les plus grande entreprise) et de surcout phénoménaux…

Et vous ca se passe comment? quelles sont vos solutions?

Et puis allé je vais poser la question à babozor (allez voir son blog, plein de truc intéressant sur les méthodes de travail dans le monde du web et puis son désormais célèbre screencast : la grotte du barbu ). Donc si tu as l’occaz de faire un billet avec ton point de vue, je suis preneur