Pour ce faire, il faut passer par des “paliers de décompression” : il faut donc continuer à s’engager initialement sur un triptyque général (qualité – cout – délai) mais un peu moins précis que dans les projets classiques sans doute ; le sprint “0″ ayant pour but de mettre le curseur sur ces 3 critères et de rassurer tout le monde ; après un ou deux projets ayant donné satisfaction, le client aura un sentiment de CONFIANCE dans la méthode et le fournisseur , et il entrera plus volontiers dans le jeu agile, à son bénéfice ; on pourra alors passer un palier de plus vers la surface… et optimiser les bénéfices de cette méthode (adaptabilité, correspondance livrable/ besoins réels, satisfaction des commanditaires).

Je crois en revanche que le paramètre [cout] ne disparaitra jamais car l’informatique doit bien prendre en compte la dimension économique de l’entreprise et de son ROI; en revanche, délai et qualité (au sens du périmètre applicatif , pas la qualité des livrables !) sont susceptibles d’être modulés d’un projet à l’autre en fonction des priorités et des situations du client.

Si je ne pense pas que tous les projets justifient une approche agile, mais je suis convaincu que certains gagneraient à passer par cette méthodologie (à chaque fois que le projet est mal défini ou que le périmètre est à majoritairement à l’initiative du fournisseur) ; le dilemne reste de savoir si fournisseur et client seront assez complices pour atteindre le stade de maturité requis pour réussir ce type de projet. Il faut du courage pour abandonner un modèle imparfait pour un modèle inconnu…

Christophe