Cessons les estimations ! par Frédéric Leguédois – Printemps Agile 2015

Frédéric Leguédois est un agiliste évangéliste, libriste et geek humaniste. Au quotidien, il anime des équipes de développement logiciel.

Premier rappel : les coûts d’un projet sont les charges, le délai de réalisation et la qualité de finition. Un coût peut être modulé à condition d’affecter les deux autres. En Agilité, la qualité est le coût non négociable d’un projet, ce qui se traduit le plus souvent par un étalement dans le temps afin de conserver des charges raisonnables.

Cet étalement est d’ailleurs préconisé par l’intervenant, au travers d’un modèle économique basé sur l’abonnement, rendu possible par des livraisons fonctionnelles fréquentes.

Ce modèle raisonne sur la nature du métier et s’oppose à la rédaction préalable de cahier des charges pour les raisons suivantes :

  • Un cahier des charges est rédigé en amont du projet, par des personnes qui ne sont bien souvent pas développeurs, qui ne peuvent ni estimer le travail à réaliser, ni anticiper la complexité d’une création nouvelle
  • Un cahier des charges comporte en conséquence des estimations de coûts et de temps imaginaires, qui sont néanmoins acquis comme Vérité
  • Par la contractualisation des pénalités de retard, l’équipe de développement reçoit une pression anti-qualitative qui génère la dette technique
  • Annoncer un délai annihile la capacité des développeurs à prendre des initiatives, pour automatiser, refactoriser, optimiser, et à être moteurs
  • L’équipe réalise le projet, mais si elle est considérée en retard sur la prévision arbitraire qui lui est appliquée, elle se démotive (cercle vicieux)
  • Ce type de projet entraine automatiquement un perdant : le prestataire ou le client arnaque l’autre, car la prévision de délai est fausse

Pour Frédéric Leguédois, le Planning Poker permet bien d’estimer à 15j la complexité des tâches à réaliser mais demande plusieurs itérations. Cette méthode ne permet toujours pas d’annoncer une prévision de coût ni de temps en amont du projet, qui sont la raison même de consommer du temps et de l’argent à réaliser des estimations.

En revanche, les estimations mesurent si les gens travaillent, ce qui est biaisé et faux à la fois. Tenir un délai n’est pas synonyme de travailler proprement, mais ne pas tenir un délai permet de désigner un ou plusieurs coupables.

L’intervenant constate que s’il est impossible d’estimer quelque chose qu’on fait pour la première fois, on peut mesurer ce qui est reproductible et en déduire une estimation, bien que cette méthode ne soit pas réceptive au changement.

Si Frédéric n’aime pas les estimations, c’est qu’il estime qu’elles créent du retard là où il y a des gens qui travaillent, alors que prendre du temps est un investissement dans l’amélioration continue pour gagner en efficacité au fil du temps. Estimer est donc contre-productif.

Une constatation simple est ce qu’attend le client : être livré. Dès lors, des estimations non fiables suffisent, réalisables non pas en amont mais tout au long du projet, en prenant des mesures sur le travail réalisé.

L’intervenant présente ainsi différentes approches pour amener le client à dévoiler ses motivations de délai : est-ce une contrainte financière ? Légale ? Arbitraire ? Quelle serait la gravité de ne pas tenir le délai face au gain de fonctionnalités dans le MVP ?

Coopérer avec ses partenaires évite de créer des conflits qui servent notamment la concurrence, en lui laissant le temps de prendre de l’avance.

La solution avancée repose donc sur un modèle itératif, par exemple mensuel, où l’équipe rencontre le client pour lui présenter l’évolution du produit en production et recueillir ses nouvelles demandes.

La vision du client évolue avec son produit, ce qui lui offre de la flexibilité mais aussi la possibilité de contrôler le travail livré : le client et le prestataire ont un intérêt convergent à collaborer.

Dans ce modèle par abonnement, le prestataire doit tout faire pour conserver un client satisfait. En lui offrant la possibilité de rompre le contrat à tout moment, il créé la confiance nécessaire pour que le client se sente d’égal à égal, et que ce dernier puisse faire pression (suspension du contrat) si le travail ne correspond pas à ses attentes.

La création de logiciel est souvent illimitée dans le temps, il peut être judicieux d’offrir ou d’avancer la première semaine de travail au client afin de le mettre en confiance. Le prestataire conserve la possibilité de rompre à tout moment avec un client qui serait malhonnête.

2 réflexions au sujet de « Cessons les estimations ! par Frédéric Leguédois – Printemps Agile 2015 »

  1. Merci Vincent pour ce compte rendu détaillé, c’est sympa d’avoir pris le temps de la réaliser.

    Et une jolie remise en cause car à la lecture de ton article, je m’aperçois de la perte en ligne qu’il peut y avoir entre ce que l’on souhaite exprimer et ce qui est réellement transmis.

    Donc quelques axes d’améliorations pour commencer : préparer des conférences moins denses, reformuler plus, enrichir et diversifier les exemples. Avec le recul, il y avait largement de quoi alimenter une journée de formation sur le sujet, faire tenir cela sur 1 h 30 était une gageure 😉

    Sur le fond, voici quelques commentaires.

    Les quatre facteurs d’un projet sont les ressources (coût), la qualité, le délai et le périmètre fonctionnel. Jouer sur un de ces leviers a systématiquement un effet sur les autres.

    Pour aller plus loin sur le rapport entre gagnant et perdant, je suis convaincu que dans le domaine du logiciel il y a soit 2 gagnants, soit 2 perdants et qu’en voulant faire perdre l’autre (pour être le gagnant), on se tire une balle dans le pied. Encore un sujet à développer.

    En fait, la mesure des charges et des délais passés, s’oppose aux estimations, qui sont des prédictions de l’avenir. Donc je pense qu’il faut même éviter les estimations non fiables (pléonasme ?), idéalement ne plus en réaliser du tout, ce qui est souvent possible.

    Quand au fait de rompre les relations vis-à-vis d’un client, ou réciproquement vis-à-vis du prestataire, c’est effectivement une possibilité mais qui est une issue ultime car elle signifie la fin du projet. D’un autre côté, c’est un des avantages de l’Agilité : pouvoir constater très rapidement qu’un projet échoue et arrêter les frais très rapidement. Cela évite les développements sur mesure au tarif exorbitant qui fonctionnent mal, voire pas du tout, mais où le client est pieds et mains liés au prestataire.

    Encore merci pour ton compte rendu !

  2. Effectivement il faut passer un peu de temps pour Estimer les charges et délais d’un projet et la question de l’utilité de ce travail de cadrage est légitime. Alors du coup, pour un projet dont les utilisateurs ont un besoin clair et bien cadré, quel délai doit on leur annoncer ? Revenez dans 6 mois et on vous montrera ce qu’on a fait ? Et au bout d’un an ou 2 quand les équipes agiles ont consommé quelques millions d’euros, et ont produit et livré des fonctions très utiles mais qu’il en manque encore les 3/4, que dire aux clients ? Revenez l’année prochaine on vous montrera des nouveaux services… et pour votre besoin complet… bah c’est pas important tant pis… C’est vraiment cela que les clients attendent des équipes informatiques ? Moi je ne le crois pas…

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.