Premier billet écrit entre 2 présentations et avant mon petit quickie tout à l’heure.
J’ai assisté tout d’abord à une présentation sur les techniques d’estimation du temps de développement appliquées à notre secteur. Le speaker, Gioavanni Asproni, a donné un ton très sympa à cette présentation.
Dans un premier temps, un bon mot pour commencer:
Estimation : Prediction is a very difficult task especially about future ones… »
Giovanni demande à l’assistance qui donne des estimations de temps de développement ? la majorité de la salle. Qui se fait négocier par son managment ces temps de développement ? Encore une fois pas mal de monde.
Il explique ensuite la différence entre « Estimation » et « Engagement ».
L’estimation est la mesure objective du temps nécessaire pour faire une tâche. Cette estimation n’est donc pas négociable. L’engagement représente le but à atteindre et donc la promesse. Cette promesse regroupe un niveau de qualité, un certain nombre d’itérations, bref c’est bien la promesse de ce que le client aura. L’estimation c’est le prix à payer.
Sur une route vous roulez avec un camping-car dont la hauteur est de 2m30. Arrive un pont dont la hauteur est limitée à 2m00. Est-ce que vous penser réussir à fare passer votre camping-car sous ce pont ? non. Vous pouvez toujours estimer si « ça passe » mais dans ce cas, à vous d’assumer les conséquences.
Donc l’estimation étant une mesure approximative, mais une mesure, vous ne devez pas négocier cette estimation. Vous devez donc négocier les engagements. Je reprends l’image du réservoir d’essence : lorsque le voyant s’allume car le réservoir est presque vide, sans le savoir votre cerveau bascule en mode « estimation ». Et vous êtes d’accord pour dire que cette estimation n’est pas négociable.
Il fait ensuite référence à un très bon livre de Steve McConnell « Software Estimation » afin d’expliquer finalement en quoi consiste une estimation.
En tant que développeur nous allons nous efforcer de donner une valeur pour la taille, le coût, l’effort en jours et les risques pour réaliser une tâche. Lorsque votre responsable vous demande une estimation vous devez donc répondre « 3 jours avec un risque important que la base ne tienne pas la charge, à 2 développeurs par jour avec une licence de GridGain »
Les estimations sont par nature sources de problème et de frustration, car le managment tient pour acquis le contrat passé entre vous et eux. Pour cette raison, Giovanni pense que les processus Agile par leurs cycles itératifs sont plus adaptés au développement logiciel que l’effet escalier, basé sur la contractualisation des échanges entre les développeurs et les personnes du business. Une spécification ne pourra jamais résoudre un problème de communication.
Il présente ensuite un cône sur une échelle de temps afin d’expliquer qu’en général, les estimations données pour une activité sont fausses, et que la marge d’erreur va de 0.25 à 4 sur une échelle verticale. Si je réponds 3 jours pour faire ce développement, il pourra en fait en prendre 4 fois plus. Ce travail est basé sur l’analyse de gros projets dans l’industrie de l’armement américaine, et des travaux de la NASA.
Ce cône est donc une fenêtre de tir pour nous clairement que nos estimations sont en générales fausses.
Comment alors réussir à travailler et répoondre aux attentes des clients ?
Dans un premier temps, il faut passer beaucoup plus de temps sur l’engagement, sur la notion du fini, sur ce que désire le client. Regardez le temps que vous passez pour acheter une cuisine chez IKEA ou pour acheter une voiture. Pour quelles raisons le client refuserait-il de vous répondre sur un projet d’un million d’euros ?
Comment gérer les changements du client ?
Vous devez penser que les changements sont gratuits et qu’ils vont arriver en cours de développement. Pour cette raison, les estimations doivent aussi être revues à la hausse ou à la baisse. Il est aussi important de rappeler à votre client que s’il décide de prendre les jantes alliages, cela coûte alors 400 EUR de plus… Pensez à toujours ajuster vos estimations afin que le client ne découvre pas au dernier moment l’addition.
Faut-il surestimer ou sous-estimer ?
A cette question, Giovanni répond que les développeurs sont trop optimises de 30%. Par sécurité il faut donc mieux ajouter un peu plus à une estimation initiale. Cependant, l’effet inverse s’appelle la loi de Parkinson : le temps de travail temps à rejoindre le temps donné pour effectuer une tâche. Si tu me donnes 10 jours pour faire cette tâche, je vais tendre à remplir ces 10 jours, c’est humain.
Avoir trop de temps disponible entraine aussi le phénomène de procastination (décidemment avec le Touilleur Express vous faîtes aussi de la psycho). On tend à remettre à demain des tâches (payer ses impôts…) car on sait que l’on a jusqu’au « XXX pour payer ».
Les techniques d’estimation
Il en existe un grand nombre, certaines basées sur l’observation du passé pour prédire le futur. A noter que dans la finance c’est une technique de calcul du risque sur un produit financier. Il y a des techniques scientifiques basées sur les probabilités, mais comme il le montre avec des formules un peu complexes, cela ne remplace pas l’humain.
Son point de vue est que les techniques suivantes fonctionnent bien :
– faire faire les estimations par les développeurs, surtout pas les chefs de projet
– faire des estimations collégiales pour que tout le monde donne son avis
– utiliser des analogies pour améliorer la précision d’une estimation
– ne pas oublier les activités connexes comme les tests, la mise en prodution, les tests en UAT par exemple.
– utiliser vos experts pour avoir de bonnes estimations mais ensuite pensez à augmenter ce temps. Tout le monde n’est pas un expert.
Les domaines où les prédictions/estimations sont appliqués sont la Finance, avec le succès que l’on sait aujourd’hui et sinon la dame en mini-jupe le dimanche soir sur TF1 : la météo de la semaine. Il y a aussi Mme Irma dans sa roulotte et Mr Marabout à Barbès.
Bref les estimations sont par nature fausses, il faut simplement travailler avec le client afin de le rassurer, de mettre en place des plans d’atterrissages d’urgence si le budget est dépassé. Et il faut aussi rappeler au client que le prix à payer n’est pas négociable.
Voilà pour cette première présentation
0 no like
Très bon article, merci nicolas.