Le prestataire donnera le prix du point d'effort

Telle est la formule désormais consacrée dans certains appels d'offre demandant une méthode agile.

Les habitués auront compris qu'il ne peut pas y avoir de réponse à cette question, car la notion de point d'effort est contextuelle à l'équipe et au projet. Elle ne sert qu'à gagner du temps pour rompre avec les habitudes à chiffrer des centaines d'exigences en Hommes.Jours en suivant des méthodes sophistiquées (analytiques, paramétriques, analogique, statistiques, DELPHI etc). C'est l'approche ceinture et bretelle, on veut se rassurer sur notre maîtrise des coûts. Les points d'effort, c'est une façon de cultiver la valeur simplicité et d'accepter la grande incertitude des estimations, ce que nous montre clairement l'histoire des projets.

Alors que faire, puisqu'il s'agit d'une exigence gravée dans le marbre ? Si on n'y répond pas... exit la propale !

Résumons

La bonne nouvelle, ce que le donneur d'ordre a gagné en maturité et comprends désormais les enjeux de l'agile. Il ne demande plus d'engagement stricte de périmètre et accepte qu'on affinera des choses lors d'une courte phase préliminaire (sprint 0, exploration etc). Mais quand on gratte un peu, l'engagement demandé revient presque au même ! En effet : à la place, il demande une vitesse de croisière, c'est-à-dire une vélocité et le prix du point. Donc il demande le coût d'une itération. Ainsi, il achète des itérations et le fournisseur s'engage sur sa vélocité. Déjà une révolution en soi. Or, à la fin de la phase de calibrage, on demandera au prestataire de s'engager définitivement sur sa vélocité. De plus, on demande un prix. Et comme l'effort est linéaire au coût, cela revient à calculer le nombre de jours que représente le point (le facteur de focalisation ou focus factor). CQFD : ayant un backlog et une vélocité fixe, on est donc capable de s'engager sur le montant total de la réalisation. Ainsi, dès la première itération, on s'embarque sur un forfait déguisé.

Bon. Il nous reste quand même la possibilité de changer de périmètre au cours du projet, à condition de ne jamais dépasser le nombre total de points estimé initialement.

Pour certains cette pratique ressemblera à une trahison de l'agilité. Factuellement, c'est un détournement de la pratique des points d'efforts telle qu'elle a été inventée. N'en restons pas là : c'est aussi une première étape significative des changements de mentalités. On s'oriente progressivement (j'espère) sur des contrat à bande passante, plus convenable à la démarche agile. Il ne reste plus qu'à prêter attention à la valeur et à la qualité du code, d'en fixer des règles contractuelles et on ne sera plus très loin de contrats adaptés (valeur systématiquement quantifiée, couverture des tests automatisés, nombre de bugs par itération etc)

Nous sommes ici en plein dans un logique de conduite du changement, qui s'inscrit sur une échelle de plusieurs années. Alors patience et persévérance...