Les projets contraints par des estimations sont voués à l’échec – ou les bienfaits des méthodes (vraiment) agiles

Les estimations constituent le socle de beaucoup de projets informatiques. On estime pour organiser un projet, on estime pour mettre en place un planning, on estime pour déterminer une date de livraison, on estime pour s’engager et contractualiser… et surtout, on utilise ces estimations préalables pour juger de la réussite ou de l’échec d’un projet. Un projet est considéré comme réussi lorsque la deadline est respectée, il est considéré comme raté lorsque la deadline est dépassée. Au Web2day, Frédéric Leguedois, Agile Evangelist chez Cloud Temple, propose une autre lecture. Et si tous les projets étaient déjà en échec dès lors qu’une estimation est effectuée ?

Les justifications préférées des chefs de projet

Il arrive fréquemment que des projets disposant d’une échéance ne soient pas livrés dans les temps. Dans ce cas, les responsables trouvent souvent des excuses.

“Mon planning était bon, mais le client a changé d’avis”

Cette première justification est difficile à justifier. Le fait que le client change d’avis n’est pas une mauvaise chose en soi. Il a réfléchi, son projet a mûri, il estime qu’une modification peut rendre service aux utilisateurs. C’est potentiellement bon, mais ce n’est pas compatible avec les plannings.

“Mon planning était bon, mais les développeurs sont en retard”

Dans le second cas, le fait de dire que les développeurs sont en retard fait planer le doute sur leur compétence. Ils sont en retard : comprenez mauvais ou fautifs. Pourtant, Frédéric Leguedois estime que la faute est imputable à ceux qui font le planning, pas ceux qui font le travail. “Le retard est une différence de délai entre ce qui est prévu et ce qui s’est vraiment passé. C’est la différence entre un rêve et la réalité. La réalité ne peut pas avoir tort, contrairement au planning. C’est comme les prévisions météo : elles ont une certaine fiabilité, tandis que le temps qu’il fait est nécessairement exact”.

“Mon planning était bon, mais il y a eu des imprévus”

Les imprévus ont cette faculté de justifier l’ensemble des problèmes auxquels peuvent être confrontés les projets. Si la deadline n’a pas été respectée, c’est souvent parce que des bâtons sont venus se loger dans les roues des membres qui travaillent sur un projet. On peut voir ces événements comme des imprévus, on peut également les accepter et considérer qu’il est impossible de tout prévoir et de tout planifier. “Planifier, c’est un métier : celui des voyants, celui des oracles, et parfois celui des chefs de projet”.

La recette miracle de l’agilité autoproclamée

Pour en finir avec ces frictions et ces projets imparfaits, “tout le monde parle d’agilité”. Aussitôt employée, aussi galvaudée. Tandis que les principes de l’agilité et la réflexion qui entoure ces concepts a du bon, on a trop souvent tendance à placer des termes liés à l’agilité un peu partout, pour prouver sa modernité. “On prend le chef de projet, il devient product owner, on installe Jira, on met le mot Agile sur la plaquette commerciale : et soudain, tous les problèmes disparaissent, comme par enchantement”.

La réalité est bien évidemment tout autre. Sans formation aux méthodes agiles, sans explication de leur intérêt pour la conduite des projets, et surtout sans changement d’état d’esprit dans la gestion effective des projets, ces derniers ne peuvent être mieux menés. “Quand on change la terminologie et qu’on ne change pas la réalité, les mêmes causes amènent les mêmes conséquences. Les liens de causalité sont immuables. Il faut repenser sa manière de fonctionner et ne plus faire de planning uniquement parce que c’est la tradition, parce qu’on a toujours fait comme ça”.

L’impact des estimations sur la productivité des développeurs

Selon Frédéric Leguedois, les estimations ont au moins deux conséquences néfastes. Premièrement, lorsqu’elles sont effectuées, elles constituent le seul et unique indicateur de la réussite d’un projet (alors qu’en réalité, un projet peut être livré à temps et être un échec). La deuxième conséquence concerne les équipes de développeurs. Admettons que l’équipe ait une deadline ce jeudi soir. En fin d’après-midi, ils comprennent qu’ils ne pourront pas livrer les fonctionnalités finalisées dans les temps. Ils ont alors le choix :

• Repousser la mise en production à une date ultérieure
• Mettre en production à la date convenue, malgré les bugs

Les développeurs vont choisir en fonction des conséquences de leur choix. Si le fait de ne pas mettre en production dans les délais les exposent à des reproches importants de la part du chef de projet, de la direction ou du client, ils vont mettre en production – malgré les risques inhérent à la MEP. Dans le cas contraire, si le product owner et les autres maillons de la chaîne comprennent que ce décalage est plus prudent, ils n’hésiteront pas à en parler, à repousser la mise en production si nécessaire et ils continueront à travailler jusqu’à ce que les fonctionnalités soient terminées. “Cesser les estimations, c’est livrer des fonctionnalités qui fonctionnent. La deadline mène à la peur”. Certains continueront ce constat en précisant que “la peur mène à la colère, la colère mène à la haine, la haine… mène à la souffrance”.

La planification a aussi pour conséquence d’engendrer de la dette technique. “Pour ceux qui ne sont pas familiers avec le sujet, la dette technique correspond à un prêt effectué à la banque. Vous n’avez pas les ressources pour acheter une voiture, vous contractez un prêt, vous payez votre voiture ainsi qu’une dette sur plusieurs mois. La dette technique, c’est exactement le même principe : vous n’avez pas le temps de faire du bon travail, vous faites du mauvais travail, les utilisateurs ne le voient pas, mais toutes les modifications effectuées ultérieurement seront plus longues, plus risquées et donc plus chères”.

Le fait de contraindre les développeurs à des délais plus ou moins aléatoires a aussi pour conséquence de les rabaisser au rôle de simple exécutant. Le message est le suivant : “vous devez faire ceci pour telle date”. Un développeur a besoin de temps pour prendre des initiatives, pour concevoir, pour échanger avec ses pairs. En basant votre organisation sur des délais, vous contraignez les développeurs dans une fonction restreinte, leur valeur ajoutée est limitée, leur motivation est de facto dégradée.

La problème des méthodes d’estimation

Le principal problème des méthodes d’estimation est qu’elles ne sont jamais fiables. Des chefs de projet estiment les délais en relisant plusieurs fois le cahier des charges (la fameuse méthode du doigt mouillé).

Des clients présentent trop brièvement leurs besoins pour qu’une estimation cohérente soit effectuée. “On veut d’abord connaître le budget nécessaire, on précisera nos spécifications plus tard. Essayez cette méthode avec votre épicier, passez le voir en lui demandant simplement combien cela va vous coûter sans lui dire précisément ce que vous souhaitez acheter. Il n’y a que dans l’informatique que ce genre de méthode perdure”.

D’autres méthodes comme COCOMO (COnstructive COst MOdel) tentent de prévoir l’imprévisible avec des formules plus ou moins scientifiques. Ici, le nombre de lignes de code attendues permet de connaître le temps nécessaire au développement du projet. Mais le nombre de lignes de code n’est pas connu à l’avance et toutes les lignes de code ne nécessitent pas le même temps de développement. Frédéric Leguedois estime également que les process pour faciliter les estimations dans la méthode SCRUM (comme le planning poker) ont également des défauts. En début de sprint, vous allez passer du temps à estimer l’imprévisible ; en fin de sprint, vous passerez du temps à essayer de comprendre pourquoi votre estimation initiale ne s’est pas vérifiée. “Le planning poker est une pratique de divination pseudo-agile extrêmement longue et complexe, donc coûteuse, ayant pour but de deviner une information dont personne n’a besoin. Il traduit la défiance de la personne qui le met en place, car une deadline est toujours liée à la défiance”.

Quelle solution, au-delà des estimations ?

La conférence de Frédéric Leguedois au Web2day, qui reprenait presque les codes du one man show, était proposée dans le but de faire réfléchir les personnes qui participent à des projets. Selon lui, pour permettre aux projets d’être de vraies réussites, il faut commencer par arrêter avec le management par la peur. “Il faut arrêter de dire qu’il faut faire telle chose pour telle date. Il faut laisser les développeurs discuter, échanger, trouver des solutions. Les gens n’ont pas besoin de deadline pour partager, la motivation suffit. Il faut créer une émulation pour que les développeurs soient fiers de leur travail et le partage avec l’équipe”.

Mais comment vendre un projet à un prospect sans se baser sur des estimations, alors que les clients sont habitués à acheter un cahier des charges associé à un prix et un délai ? “En réalité les clients choisissent les projets en lesquels ils ont confiance. Si on veut arrêter de faire des estimations, il faut aller auprès des clients, expliquer l’intérêt de nos méthodes pour générer de la confiance. Ceux qui ont connu les projets non-satisfaisants au forfait vous comprendront. La variable d’ajustement doit toujours être le périmètre d’un projet et non pas sa qualité, son coût ou son délai. Rien n’est indivisible, tout constitue un ensemble de fonctionnalités. Quand on commence par les fonctionnalités prioritaires, quand on a confiance dans les développeurs, quand on arrête de faire des promesses, quand on s’adapte au contexte, on est vraiment dans l’agilité et les projets réussissent”.