# Et si vous arrêtiez de faire des estimations ? Découverte du mouvement #NoEstimates !
> Les estimations sont une vieille tradition. Elles ont cependant des limites. Et si estimer au fur et à mesure était une meilleure solution ?
Date: 2018-05-25
Authors: Axelle Boucher, David Endico
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](/fr/prestations/developpement-web).
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
[©️ CommitStrip](http://www.commitstrip.com/fr/2018/02/05/it-project-estimates/)
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](/fr/prestations/developpement-web) l’évolution du [projet](/fr/blog/articles/rex-deroulement-projet-ux-bearstudio), et de **se baser sur ce progrès pour prévoir et jauger la suite des évènements.**
[©️ Magnus Dahlgren](https://magnusdahlgren.com/2017/03/23/noestimates-just-story-points-done-right/)
## 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](/fr/prestations) 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.goood.pro/2014/07/25/developper-sans-faire-destimation-le-mouvement-noestimates/)
- [https://blog.cellenza.com/software-craftsmanship/estimer-sans-estimer/](https://blog.cellenza.com/software-craftsmanship/estimer-sans-estimer/)
- [https://magnusdahlgren.com/2017/03/23/noestimates-just-story-points-done-right/](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/axelle_boucher)
[https://twitter.com/DavidEndico](https://twitter.com/DavidEndico)