Agilité pour un contrat au forfait

Le contrat au forfait tel qu'il est couramment pratiqué n'est pas la meilleure façon de travailler entre une MOA et une MOE. Mais s'il est imposé, il n'est pas incompatible avec des pratiques agiles, qui peuvent contribuer à son succès.

J'ai eu récemment des discussions, dans 3 domaines différents, sur l'adéquation d'une méthode agile (Scrum) à des projets réalisés au forfait. On évoque souvent la nécessité d'avoir des specs détaillées pour estimer le prix comme l'argument qui empêche de travailler par itérations. Or dans les 3 contextes évoqués, les contrats ont démarré sans que les specs soient détaillées, loin s'en faut. Je ne veux pas discuter dans ce billet de la façon dont sont faites les estimations, de ce qui pourrait être amélioré dans les relations contractuelles, mais seulement de l'intérêt de l'agilité pour réaliser le contrat.
Un contrat raisonnable met en face d'un prix une obligation de résultat portant sur une liste d'exigences. Quand on utilise Scrum, la liste d'exigences, c'est le backlog de produit.
Quels avantages présente l'utilisation d'une méthode agile à partir du moment où le contrat est signé et le projet démarre ?

  • le client (MOA) reçoit une version partielle -mais qui marche- à chaque itération. De plus c'est lui qui a décidé du contenu -les exigences-, il peut donc bénéficier en premier de ce qui lui apporte le plus de valeur.
  • le client peut fournir très tôt un feedback concret sur ce qui lui est fourni, ce qui assure de converger vers la conformité au contrat.
  • le client peut changer d'avis et remplacer une exigence -pas encore réalisée- par une autre de même taille sans changer le contrat.
  • toutes les parties ont une visibilité totale sur l'avancement réel du projet.

Commentaires

1. Le mercredi 12 juillet 2006, 23:50 par Oaz

Je suis un peu gêné par la présenation ainsi faite des avantages de l'utilisation d'une méthode agile qui laisserait penser à un 'repas gratuit'.
Citons au moins un inconvénient : laisser le client décider de l'ordre d'implémentation a un coût (de refactorisation, principalement). Si on est sûr qu'il faut réaliser ce qui est décrit dans le contrat, rien de plus, rien de moins, alors utiliser cette possibilité des méthodes agiles peut gonfler, au final, le coût de développement.
Mais sinon je ne vois effectivement pas pourquoi on ne pourrait pas utiliser nombre de pratiques agiles dans un contrat au forfait.

2. Le jeudi 13 juillet 2006, 09:46 par claude aubry

C'est vrai que je suis plus enclin à parler des avantages de l'agilité que de ses inconvénients... Le changement pour passer à une méthode agile a évidemment un coût, ne serait-ce qu'en formation.

En revanche, je ne comprends pas votre exemple sur la refactorisation. Pourriez-vous préciser ? Je suis "client" sur le projet IceScrum, je décide de l'ordre des exigences (et je le change régulièrement) et il ne m'est pas apparu que cela nécessitait plus de remaniement du code.

3. Le jeudi 13 juillet 2006, 10:31 par Freddy Mallet

Toujours dans cette idée de concilier (dans la mesure du possible) les contrats au forfait classiques et les méthodologies agiles, il existe deux articles de très bon niveau de Pascal Van Cauwenberghe sur son site : www.nayima.be/writing/pap... .
Les deux articles sont "Succeeding with "Agile Fixed Price" projects Part 1: The Price is right!" et "Succeeding with "Agile Fixed Price" projects Part 2:"Do you want agility with that?".

4. Le jeudi 13 juillet 2006, 12:08 par Stephane

J'ai lu quelque part (un bouquin XP en français il me semble) que le meilleur cadre contractuel pour l'agilité était la régie forfaitisée..
A mon avis c'est la problématique du contrat en France est un sujet important, surtout aux yeux des décideurs..

5. Le dimanche 16 juillet 2006, 18:28 par claude aubry

Merci Freddy. Je ne connaissais pas ces articles et ils sont vraiment très intéressants. J'ai en particulier apprécié les conseils (Implementation Tip 6) sur qui doit jouer le rôle du client XP (product owner pour Scrum).

6. Le lundi 17 juillet 2006, 16:25 par Oaz

"En revanche, je ne comprends pas votre exemple sur la refactorisation. Pourriez-vous préciser ?"

Par exemple, si le client décide que l'exécution d'un cas nominal d'une fonctionnalité est plus important que certains cas limite pour lesquels il faut détecter des erreurs, on peut se retrouver à implémenter en 1ère approche un cas nominal de manière très simple. Par la suite, on peut être obligé de revoir l'architecture du code pour gérer correctement toute une panoplie d'erreurs.
Procéder dans cet ordre induit inévitablement un coût plus élevé en temps.

Ceci étant dit, la remarque ne vaut que pour les cas où on est sûr de la liste complète des fonctionnalités et que l'on ne prévoit à aucun moment de revenir dessus suite à un feedback client. Autant dire quasiment jamais, même en contrat au forfait...