L'artisan développeur

Blog de Sébastien Cormier
A la Une Startup

#BalanceTonEstimation, pourquoi un modèle basé sur les estimations est voué à l’échec

Comment ne pas se planter dans l’estimation d’un projet ? La question semble complexe tant elle se pose régulièrement, sans réponse satisfaisante. Dans cette article, je ne vais pas vous donner une nouvelle recette miracle qui de toute façon  ne fonctionnera pas mieux que les autres, mais plutôt donner des pistes pour faire vivre un projet sans estimation.

Un modèle inspiré du bâtiment

Quand j’étais encore étudiant, la gestion de projet nous était enseignée en reprenant les principes utilisés dans le domaine du bâtiment : étude, conception, réalisation et recette. Vous vous souvenez du fameux cycle en V ? A partir d’un cahier des charges, le but était de réaliser un planning dans lequel on serait capable de prévoir au jour prêt combien de temps il serait nécessaire pour :

  • La capture des besoins
  • La conception générique
  • La conception détaillée
  • Le développement
  • Les tests / debugs
  • La recette

Et nous arrivions à un résultat comme : 4 mois, 1 semaine et 2 jours, basé sur un cahier de charges qui était bien entendu complètement à coté de la plaque. Une chose était certaine, c’est que 6 mois après, le projet allait être en retard.

Les projets dans le bâtiment dérapent souvent, mais pas autant que dans l’IT. En effet, dans le bâtiment, les matériaux et les techniques de constructions varient peu d’un chantier à l’autre. Quand on construit un logement presque identique au précédent, la marge d’erreur est faible. Les risques sont liés aux impondérables : la météo, l’indisponibilité ponctuelle d’un artisan, etc.

Si dans l’Informatique tous les projets avaient les mêmes contraintes et besoins (sécurité, performance, fiabilité), et que l’on utilisait à peu de chose prêt les même technologies éprouvées au fil des ans, les estimations seraient relativement fiables. Cependant, les choses évoluent rapidement dans l’informatique. Nous sommes bien content d’ailleurs de ne plus démarrer un projet en Java 1.3 avec des EJB et des services SOAP. Aujourd’hui nous développons des services bien plus complexes et puissants, et de plus en plus rapidement. Le revers de la médaille, c’est que l’incertitude dans l’estimation est gigantesque !

Et si l’on s’inspirait d’un club de foot ?

Il m’arrive souvent de comparer la gestion d’un club de football professionnel à la gestion d’une équipe I.T. Demander une estimation sur un projet à un développeur revient à demander à un attaquant combien de buts il marquera dans la saison : vous aurez probablement une réponse qui sera plus un objectif personnel qu’une réelle estimation. Difficile pour un attaquant de savoir si l’entraîneur le fera jouer régulièrement, ou s’il se blessera. Il pourra marquer 20 buts, ou .. 3 seulement, impossible de le savoir avec certitude.

Un ami m’a dit il y a quelque temps : si tu n’aimes pas te prendre de murs, il ne faut pas faire ce métier: Etre développeur, c’est se prendre les murs les uns après les autres. Un développeur passe la majorité de son temps à chercher pourquoi ce qui était censé fonctionner ne fonctionne pas. Alors comment estimer avec fiabilité dans ces circonstances ?

Au final, c’est la qualité qui trinque

Une des conférences les plus intéressantes de la dernière édition de Codeurs en Seine était celle de Frédéric Leguesdois. Il n’y a malheureusement pas de vidéo disponible mais j’en fais un résumé dans mon article sur cette conférence.

Dans son talk, Frédéric nous explique pourquoi les estimations sont un frein à la qualité de nos projets : quand on s’engage sur une date et un périmètre fonctionnel, et que le projet prend du retard, on est obligé de rogner sur quelque chose :

  • La date ? Non, on s’est engagé !
  • Le périmètre fonctionnel ? Non, c’est contractuel !
  • La qualité ? Parfait, c’est difficile à mesurer et c’est pas ce qui saute aux yeux immédiatement.

Les conséquences des estimations

Il n’arrivera pas à l’heure estimée…

Si vous travaillez en méthode agile, sur un produit spécifique, alors le poker planning restera une méthode d’estimation sur laquelle il sera possible de s’appuyer. Bien entendu, seulement après une période de rodage et si l’équipe ne change pas trop souvent. Dans les autres cas, toute estimation vous mènera dans le mur. Si votre estimation est trop serrée, le projet sera en retard. Même terminé avec un bon niveau de qualité et répondant au besoin, cela restera un projet terminé « en retard ».

Si au contraire vous terminez avant le délai imparti, votre boss ou votre client aura l’impression de se faire « rouler » avec un coût de développement surestimé.

Enfin, les estimations peuvent avoir un effet pervers sur la motivation de l’équipe. En effet, avec un objectif à plusieurs mois, on se sent très confortable et on prend le temps de faire tranquillement les choses., il manque cette petite pression qui nous fait avancer. Quand  la date fatidique approche, on commence à se précipiter et à prendre des décisions plus « court-termistes ». Au final, que la deadline soit large ou non, le projet se terminera la plupart du temps dans le rush. Pour garder un rythme de développement plus régulier, l’idéal est de fixer de petits objectifs sur de petites périodes.

Convaincre son boss ou son client de procéder autrement

Quand vous tentez de convaincre des effets néfastes des estimations, vous avez souvent 2 types de réactions :

1/ J’ai besoin de visibilité : sans visibilité, impossible de piloter le business !

2/ Je veux une équipe qui est capable de tenir ses engagements !

Dans le premier cas, on peut en effet répondre que si la visibilité est quelque chose de très important pour le business, c’est que le business repose sur quelque chose d’absolument pas fiable. Peut-être est-il temps d’envisager de piloter son business autrement ?

Dans le deuxième cas, c’est pousser l’équipe à ne pas prendre de risque. Soit que l’on parle d’estimation et il y aura une marge d’erreur dans un sens ou dans l’autre, soit que l’on parle d’engagement. S’il faut absolument s’engager sur une date, nous allons voir que le concept de M.V.P. peut nous aider même si son objectif est à la base bien différent que de tenir un engagement.

Le M.V.P. à notre secours

Cycle vertueux du Lean Startup

S’il faut tenir une date, une bonne façon de procéder consiste a bien définir le M.V.P (Minimum Viable Product), ainsi que les fonctionnalités les plus intéressantes mais dont on pourrait se passer. Le M.V.P. correspond au fonctionnalités indispensables permettant de tester ce produit.

Dans le modèle du lean startup, le concept de M.V.P. est important pour être en mesure de tester au plus tôt une idée. Cela permet de rentrer dans une boucle vertueuse qui consiste à construire, mesurer, apprendre puis construire à nouveau à partir de ce que l’on a appris.

Dans le cas qui nous intéresse, l’idée sera de construire un premier livrable qui permettra au client d’avoir un premier retour de façon très rapide, même si le périmètre fonctionnel est limité. Si le temps le permet, on pourra ensuite ajouter certaines fonctionnalités « nice to have ».

Le fait de pouvoir livrer le M.V.P. avant la date d’engagement permettra de rassurer. De plus, la construction de ce M.V.P. permettra au client de revoir son besoin et changer en cours de route. Cela sera donc le moment idéal pour convaincre que se baser sur des estimations n’est pas la meilleure de solution. Procéder par de petites itérations sans engagement à moyen/long terme est bien plus efficace.

Conclusion

Le but de cet article est de démontrer pourquoi un modèle qui repose sur les estimations est voué à l’échec. Pour sortir de ce modèle, je propose une piste qui ne conviendra pas à tous les cas de figures. De façon général, le plus difficile est d’établir cette relation de confiance et cela peut se faire en limitant au maximum l’effet tunnel. Mais soyons honnête, cela reste encore très compliqué.

En attendant, nous pouvons toujours raconter nos estimations les plus folles avec le hashtag #BalanceTonEstimation !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.