Tags : #NoEstimates
Avant propos
Voilà ! Après de longs mois de préparation, le Business Plan est enfin clôturé et votre premier POC (Proof of Concept) a été couronné de succès : vous êtes fin prêt à lancer votre projet ! Recruter une équipe de développement en interne ? Trop long et risqué… Vous n’avez donc plus qu’une seule solution : contacter de potentiels prestataires et leur demander… Des estimations !
L’Estimation, cette vieille tradition
Passage obligé à la bonne relation entre le porteur de projet et ses prestataires techniques, les estimations font aujourd’hui figure d’habitude lors du lancement d’un projet. En même temps, difficile de s’en passer. Sans elles, comment peut on :
- Prédire le budget, la vélocité et le niveau de qualité du projet
- Savoir si le projet est assez abordable pour générer du profit
- Choisir le prestataire avec qui travailler et à qui accorder sa confiance
- Décider des fonctionnalités à développer et de leur priorisation
- Engager le prestataire à respecter les différents points précédents
- Se rassurer
En gros, les estimations vont nous servir à prendre de bonnes décisions (techniques, stratégiques, business…), essayer d’anticiper les différentes étapes du projet et comparer les choix possibles sur la base de données empiriques.
Ces données une fois validées permettront d’établir les critères de succès du projet (fonctionnalités à développer, budget à tenir, délai à ne pas dépasser) et par la même occasion fixer les garanties que le prestataire devra s’engager à respecter durant toutes les différentes phases de développement.
Mais ces grilles d’évaluations sont-elles toujours pertinentes ? Que penser d’un projet respectant sur le papier son cahier des charges / budget / planning, mais en pratique inutilisable par l’utilisateur ? Que dire de cet autre au périmètre partiellement développé, mais dont le ROI (Retour Sur Investissement) rapide et important permet d’amortir la suite des évolutions ? La notion de réussite ou d’échec est ici assez relative.
Limites des estimations
Ces exemples sont plus courants qu’on ne le pense, et permettent de relever un certain manque d’Agilité et de souplesse du modèle, que ce soit du côté commanditaire ou prestataire. Entre le lancement du projet et sa mise en ligne, il n’est pas rare de voir de complets revirements de situation : pivots stratégiques, changements de cible ou évolutions du marché… Le projet est finalement en perpétuelle évolution, là où le rôle de l’estimation est justement de le figer dans le temps.
Résultat ? D’un côté, le client ne peut plus adapter son projet aux fluctuations du marché, de la législation, des retours qu’il reçoit de ses utilisateurs, ou encore de ses ambitions. Il perd totalement la main sur le devenir de celui-ci.
D’un autre, le prestataire perd la possibilité de conseiller son client au fur et à mesure de l’avancée du projet, de s’adapter aux évolutions de celui-ci et de surtout privilégier les meilleurs choix techniques, autrement dit faire ce pour quoi il est payé !
Au lieu de ça, l’accent est mis sur la déculpabilisation de chaque partie, qui n’a plus que pour objectif principal de prouver qu’il n’est pas en faute. Un contexte de projet sain ? On ne pourrait pas en être plus éloigné…
Et si l’alternative aux estimations était de ne pas en faire ?
Née des débats animés des deux experts en Agilité Woody Zuill et Neil Killick, la philosophie No Estimate tente d’apporter une vision un peu plus moderne des estimations. Le principe ? Se baser sur l’évaluation non plus d’un périmètre global et fixe dès le début du projet, mais de petits lots de fonctionnalités – appelées User Stories – (ex.: “Se connecter via Facebook”, “Rechercher un produit par date de mise en ligne”, “Modifier les informations de tous mes collaborateurs”…). L’idée est ainsi de pouvoir mesurer régulièrement et tout au long du développement l’évolution du projet, et de se baser sur ce progrès pour prévoir et jauger la suite des évènements.
Avantages du No Estimate
Mais “Pourquoi tant de mauvais sites web produits ?” me demanderez-vous. C’est simple, dans le marketing et la communication classique, l’objectif est de plaire au plus gros salaire de la réunion pour remporter le budget de la campagne publicitaire. En anglais, le terme est “HIPPO” (Highest Paid Person Opinions)3. Sur votre moteur de recherche préféré, vous trouverez d’ailleurs beaucoup de méthodes sur comment gérer ce type de profil lors d’un projet.
Qu’est-ce que cela apporte ? D’abord un rapport de confiance mutuel entre le porteur de projet et son prestataire. Tandis que le premier peut modifier intelligemment son périmètre (et ne plus être prisonnier d’une estimation signée en amont), le second peut quant à lui s’adapter avec souplesse aux aléas du projet tout en assurant la qualité de ce dernier.
Le fait de travailler sous forme de petits lots plutôt que sur une enveloppe globale permet également de mieux rationaliser les coûts : comme le paiement n’est plus en fin de prestation mais plutôt effectué sous forme de forfait mensuel (provisions d’un certain nombre de jours, paiement au mois en fonction du temps passé…) et sans engagement pour le client, celui-ci devient ainsi libre d’arrêter les développements à tout moment. L’objectif du prestataire, s’il veut pérenniser la collaboration, devient alors, non plus le respect strict du cahier des charges, mais bien la satisfaction du client et la qualité du projet. De son côté, le prestataire n’est pas réticent aux modifications car il est rémunéré tant que le projet continue et que le client est satisfait.
Enfin, la plupart des tâches de planification en amont étant éliminées, c’est d’autant plus de temps et d’énergie alloués au projet. En promettant par exemple de livrer un lot en semaine 30 tout en faisant se rencontrer le porteur de projet et son prestataire de manière régulière (1 fois toutes les 1 ou 2 semaines par exemple), il devient plus simple d’échanger sur les progrès effectués et définir les étapes suivantes.
Bien entendu, je ne suis pas en train de dire qu’il faut tracer une croix sur les concepts d’échéance ou de performance, bien au contraire ! Les estimations pourraient ne pas disparaître, mais le temps et les efforts qu’on y consacre pourraient diminuer.
Pour résumer, nous pourrions dire que le No Estimate nous invite à :
- Rationaliser le budget, la vélocité et le niveau de qualité du projet
- Adapter le projet en fonction des besoins et des impératifs du marché
- Travailler en toute confiance et transparence avec le prestataire choisi
- Se concentrer sur les fonctionnalités apporteuses de valeur pour l’utilisateur
- Collaborer intelligemment, de manière itérative et agile
- Se rassurer
N’est-ce pas finalement tout ce que nous recherchions en mettant en place des estimations ?
Sources
- https://blog.goood.pro/2014/07/25/developper-sans-faire-destimation-le-mouvement-noestimates/
- https://blog.cellenza.com/software-craftsmanship/estimer-sans-estimer/
- https://magnusdahlgren.com/2017/03/23/noestimates-just-story-points-done-right/
Auteurs
Axelle Boucher et David Endico
https://twitter.com/axelle_boucher
https://twitter.com/DavidEndico
Publié le 25/05/2018 dans Développement