Les bénéfices des Méthodes "Agiles"

Voici quelques situations qui doivent vous amener à penser méthodes agiles (XP, Scrum, Crytal Clear, …) :

Votre client/MOA sait exprimer ses besoins mais ne se sent pas capable de spécifier complètement sa nouvelle application ?

Les clients qui vous le promettent ne sont pas de mauvaise foi, par contre leurs utilisateurs en voudront pour leur argent et changeront forcément de point du vue en cours de projet. Sans parler des changements d’environnement tout au long du projet (fusion, changement de stratégie, nouvelle législation, infaisabilité technique, mauvaise compréhension du besoin, …)

Votre client/MOA ne croit plus aux développements forfaitisés à prix fixe. Ce soit disant prix fixe explose dès la deuxième itération !

La pire des situations est l’appel d’offre ouvert qui incite les prestataires à évaluer à la baisse sans jamais voir le client en face pour lui poser des questions sur son projet.

Au mieux, on doit pouvoir donner une estimation du type : Votre projet a 70% de chances de prendre 1000hj, plus ou moins 200hj. Ceux qui ont un peu étudié les statistiques, savent que les résultats de sondages doivent être donnés sous cette forme, même si les médias pensent que communiquer un pourcentage est suffisant. Votre client/MOE souhaite contrôler la qualité de vos livrables sans savoir trop comment s’y prendre.

Le pire c’est que ce mode flicage nous rapporte, puisque l’on aide d’autres clients à mettre au point des normes, des processus, des plannings,…

Le seul indicateur de qualité devrait être le produit livré, confronté aux utilisateurs finaux. Pour tester la satisfaction de ses clients, Sun ne pose plus qu’une question : Seriez-vous prêt à recommander nos produits ? Alors que faire ?

Plus de big upfront design, donc des coûts réduits : Le projet classique (architecture technique, POC, socle technique personnalisé, développement) est remplacé par une architecture émergeante au fil de l’eau plus légère et plus flexible. Cela ne veut pas dire que l’on ignore les règles d’architecture ou d’urbanisation du client. Cela reste des exigences en entrée du système.

Plus de dépassement de budget incontrôlé : Si le budget maximal est atteint, on peut choisir :

 + <strong>D'arrêter les développements</strong> et d'utiliser le produit tel quel. Avec les méthodes agiles, on a un produit fini à chaque itération. Avec les méthodes classiques (même itératives), le projet est rarement utilisable en l'état.
 + <strong>De contrôler l'augmentation de budget</strong> car le produit est affiné à chaque itération sans risque de régression (grâce au test driven development). Pourquoi pas ne pas mettre le logiciel en production tout en repoussant l'ajout de fonctionnalités à l'année prochaine ? C'est d'ailleurs ce que l'on fait en achetant un progiciel.