Arrêtons de se faire mal avec les contrats au forfait et le cycle en V

Sur ce sujet, l'article suivant de Guillaume Bodet de la société Xébia : "Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait" constitue un bon point de départ.
Personnellement je suis assez d'accord avec son point de vue. L'article suivant de Valtech apporte également quelques lumières sur le sujet : "La contractualisation agile, une affaire de bon sens !".
Par ailleurs, si vous êtes disposé à accepter la réalité sur le Cycle en V, voici un article de Claude Aubry très instructif : "Le cycle de vie en V n'existe pas"

En résumé

• L'approche en cascade ou Cycle en V (je m'autorise un petit raccourci) est amenée à disparaître pour la majorité des projets de développement et le contrat au forfait classique avec si possible. Contrat qui pousse le fournisseur à se méfier du client car toutes les règles du jeu sont contre lui, à respecter son plan initial parfois au risque de compromettre la qualité, à faire supporter à son équipe une pression forte. Des changements précieux inévitables pour le client et ses utilisateurs peuvent être écartés pour des raisons de budget. Autrement dit le produit livré à la sortie ne répond pas parfaitement au besoin des utilisateurs.
• Un projet purement Agile ne peut être mené correctement en forfait

Vers l'assouplissement

A mon sens, comme je le détaille ici, il est cependant possible d'utiliser au sein d'une approche traditionnelle certaines pratiques Agile comportant peu de risques dans le cadre d'un contrat au forfait :

• Pratiques de gestion de projet simples et efficaces (réunions quotidiennes de 15 minutes, tableau des tâches, objectifs à 3 semaines - itérations courtes, graphique d'avancement, démonstrations,...)
• Pratiques d'ingénierie pour la qualité (Intégration Continue, TDD, TDR,...)
• Management (équipe auto organisée, moins de pression, plus de cohésion, multi-compétence,...)

Puis sautons le pas

Un projet purement Agile va bien plus loin et à juste titre :

• Il ne part pas d'un gros cahier des charges et repose encore moins sur des spécifications fonctionnelles détaillées exhaustives validées en début de projet. Personne ne peut spécifier son besoin dans les moindres détails à l'avance, soyons réalistes.
  
• Le client priorise ses besoins en mettant en premier les fonctionnalités les plus importantes pour lui et challenge leur priorité tout au long du projet
• Le fournisseur livre une application potentiellement utilisable par les utilisateurs à la fin de chaque itération (je m'explique un peu plus loin là dessus)
  
• Le rapport au contrat est très faible, le plan peut changer (Qui n'a jamais rencontré d'imprévu sur un projet ?), le seul livrable vraiment attendu est l'application incrémentée à la fin de chaque itération. Pas de liste énorme, contraignante et coûteuse de livrables à émettre à date.
  
• Les gaspillages sont éliminés

Pour arriver à la contractualisation d'un tel projet, les conditions peuvent être simples :

• Régie, forfaitisation de chaque itération, contrat "Target-Cost" ou plus original mais plein de bon sens : "Idée de Bob Martin"
• Le client peut arrêter le projet à la fin de chaque itération
• Les principes de collaboration client/fournisseur sont établis
  
• Définition des indicateurs du projet
  
• Le fournisseur s'engage sur sa vélocité en fonction de la charge de travail estimée et l'équipe choisie (c'est quand même beaucoup plus facile d'estimer 3 semaines de boulot que 5 mois)
• La première itération peut se contenter de produire un prototype qui permet de valider l'architecture et générer la confiance du client

Nota Bene : Si votre client vous dit qu'il ne juge que par le Cycle en V et le contrat au forfait, demandez lui combien de ses projets ont vu le jour dans les temps et en respectant le budget (j'ajouterai sans bras de fer avec le fournisseur lors de la négociation des avenants et avec des utilisateurs satisfaits à 100% à la sortie). La réponse risque d'être proche de 0. Demandez-lui alors s'il ne serait pas temps d'essayer une autre approche qui a fait ses preuves ailleurs ?

Mais en pratique, que peut-on produire en 3 semaines ?

Sur le côté "Application potentiellement utilisable par les utilisateurs à la fin de chaque itération" ça mérite peut être une explication :

Imaginons que votre équipe doive développer un logiciel équivalent à Micosoft Word (beau challenge), le client vous prends à l'essai sur une itération forfaitisée (pas trop risqué pour lui niveau budget).
En 3 semaines avec 5 développeurs on peut - sans se faire mal - réaliser un prototype qui permet d'éditer du texte avec 3 fonctions de mise en forme, sauver dans un fichier et rouvrir le fichier (les fonctionnalités qui ont le plus de valeur pour les utilisateurs).
Vous en faites la démo, le client est content et signe pour une itération de plus dans laquelle vous allez ajouter des fonctions et ainsi de suite.
L'éditeur de texte en l'état est livrable et utilisable, il peut y avoir des bugs (non bloquants), l'utilisateur se familiarise avec l'outil et devient plus précis dans l'expression de ses besoins lors des itérations suivantes.

Sur des projets plus complexes (d'intégration avec des SI par exemple), c'est un peu plus compliqué, il faut peut être 2 ou 3 itérations pour pouvoir avoir un produit utilisable ou rassurant pour le client.
Mais le client en a conscience et peut se contenter d'un prototype brut de décoffrage qui à le mérite de valider l'architecture et de rassurer tout le monde.

Une fausse crainte consiste à être amené à casser l'architecture sur une itération future suite à un changement important.
A cela je propose deux réponses :

• D'abord il faut oublier l'approche traditionnelle de développement par couche. On développe verticalement (fonctions après fonctions en couvrant toutes les couches).
• De plus, les outils de refactoring s'améliorent et l'intégration continue permet de détecter pas mal de régressions (l'outillage a énormément évolué ces dernières années).

Bénéfices

Une fois que la soif de votre client est rassasiée (besoins comblés à l'itération 'x' en fonction de son budget), le client dispose d'un produit sur mesure, ses utilisateurs sont comblés.