Les estimations : Une étape nécessaire?

Peu importe notre rôle dans l’équipe ou notre niveau dans la hiérarchie, nous avons tous eu à conjuguer avec les estimations de portées et d’échéanciers.

 

Estimer est l’exercice le plus complexe qu’il nous est donné de faire dans notre métier de développeurs de logiciels sur mesure. La complexité croît avec le nombre de paramètres et le risque continuel des demandes de changements. Oui, la seule constante est le changement.

 

Mais pourquoi ce besoin, cette nécessité d’estimer?

 

Cela nous donne le sentiment de contrôle et de prédictibilité. L’humain n’aime-t-il pas les garanties et les certitudes? Une date de début, une date de fin, une portée et un budget précis. Avec ces informations, nous pouvons décider d’une équipe et de la répartition du travail dans le temps; il n’y a rien de tel qu’un bon vieux diagramme de Gantt! Nous pouvons donc répondre à la grande question de notre client quant à la date où le logiciel sera terminé, et quant au montant d’argent qu’il en coûtera. Suivront les négociations, la signature du contrat, le processus d’approvisionnement, etc…

 

Combien d’énergie, d’argent, d’heures et de semaines sont requis pour satisfaire cette nécessité de contrôle?

 

Sitôt le projet entamé et l’équipe en place, les membre du projet commencent à poser des questions, dont les réponses complexifient la plupart du temps les paramètres ou invalident carrément les hypothèses posées lors de l’estimation. Parfois même, ce processus peut s’étirer au point que le contexte d’affaires a changé. Le projet n’a pas encore commencé que les hypothèses ne sont plus valides.

 

Peu de projets à échéancier et budget fixes sont réellement profitables, pour l’une ou l’autre des parties. Soit le projet est en retard parce qu’il a été mal estimé (effort et/ou portée), et donc le fournisseur mange ses profits, soit le projet est volontairement surévalué par le fournisseur pour inclure tellement de contingences que le client va payer beaucoup plus pour couvrir le coût des surprises que le projet réservera (Et si la loi de Murphy est juste, il y en aura!).

 

Pour développer un logiciel dans ce monde VUCA (de l’anglais Volatility, Uncertainty, Complexity, Ambiguity, soit Volatilité, Incertitude, Complexité, Ambiguïté)  il est primordial d’être flexible et capable de s’ajuster aux changements le plus efficacement possible. Les méthodologies Agile proposent d’y arriver, entre autres, en inversant le traditionnel triangle de fer (Iron Triangle). Dans un projet en mode traditionnel (Waterfall), on fixe la portée, puis on fait varier l’échéancier et le budget. Dans un projet en mode Agile, on fixe le budget et l’échéancier, puis on fait varier la portée.

 

Afin de s’assurer que le client en a pour son argent, il est donc primordial de valider nos hypothèses le plus rapidement possible. Puisqu’on ne peut pas estimer ce qu’on ne connait pas, il faut le découvrir. La façon la plus directe et indéniable d’y arriver, c’est de livrer constamment de la valeur au client tout en réduisant la boucle de rétroaction. Le client sera alors en mesure, un, de voir l’avancement du projet de façon complètement transparente, et deux, de décider des prochaines fonctionnalités à haute valeur ajoutée à développer dans la prochaine itération. Ainsi, il est maitre du budget dépensé et peut gérer ses risques à sa convenance. Les estimés devraient également être revalidés régulièrement, en fonction de l’état du système et de la portée (si elle a changé). Un estimé n’est pas une certitude, par définition.

 

Mais revenons sur cette phrase toute simple, et analysons ensemble les mots qui la composent : « Livrer constamment de la valeur au client tout en réduisant la boucle de rétroaction »

 

« Livrer », implique :

  • Des environnements fonctionnels chez le fournisseur
  • Des environnements fonctionnels chez le client
  • Des pratiques de développement (incluant les pratiques de test!) maitrisées

 

« Constamment », implique :

 

« De la valeur », implique :

  • Un responsable côté client (Product Owner) dédié au projet, capable de prioriser les items à développer en fonction des opportunités d’affaires dans son marché, les documenter (ou du moins partager sa connaissance d’affaire afin qu’on puisse les documenter) dans un carnet de produit.
  • Des utilisateurs réels capables de fournir de la rétroaction au responsable, idéalement incluant des métriques de performance (Temps pour effectuer leurs tâches par exemple)

 

« Au client », implique :

  • De la collaboration
  • De la transparence
  • De la confiance
  • Des termes contractuels qui permettent des ajustements rapidement

 

« Tout en réduisant », implique :

  • Des métriques
  • Un processus d’amélioration continue
  • Idéalement, une présence physique du responsable côté client au sein de l’équipe fournisseur
  • Une révision régulière de la portée en se demandant ce qu’on peut retirer ou faire plus simplement (avec la rétroaction des utilisateurs mentionnée plus haut)
  • Une stratégie d’automatisation de tests, qui garantit la non-régression et donc réduit les efforts additionnels

 

« La boucle de rétroaction », implique :

  • Plusieurs itérations
  • Un canal de communication bidirectionnel clairement établi
  • Des utilisateurs côté client qui testent le système à chaque livraison

 

En somme, on réalise aujourd’hui que de définir un projet à portée fixe, impliquant du même coup un budget et une durée fixes, en se basant sur une estimation initiale, comporte des risques importants pour les deux parties. Au départ, il est très difficile d’avoir une compréhension complète de la portée. Celle-ci se précise en cours de développement. Comment pouvons-nous intégrer cette notion dans le processus de développement? C’est exactement un des fondements de l’Agilité.

 

Dans le souci de livrer constamment de la valeur au client, l’estimation et le retour sur nos hypothèses en continu permettent de caractériser et de quantifier cette valeur. Ensemble, ces exercices assurent l’encadrement de la portée quant au budget et au calendrier, et mettent en lumière la valeur et la qualité de l’application pour le client. Ce dernier, par sa participation directe au développement, peut témoigner de cette valeur qui s’accroit tout au long du projet.

Image Team Askida

Team Askida

L'équipe d'Askida / Team Askida