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 ?

C’est normal. Personne ne sait figer ses exigences avant que les développements ne commencent.

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 !

C’est normal. Aucun développeur, chef de projet ou directeur de projet ne peut chiffrer un développement à l’avance. S’il dit le contraire, il n’est pas de mauvaise foi, il se voile juste la face en se rassurant avec des feuilles de calcul Excel, des points de fonction et des abaques. Un développement est une fonction avec trop d’inconnues.

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.

C’est normal. Dans le cas de forfaits, l’application livrée a rarement la qualité attendue, faute de temps pour mieux faire. Pour se protéger, les clients fixent donc des normes de développement, des outils de vérification (type cast), des jalons de livraisons, des processus complexes, …
En fait, nos clients cherchent à nous faire porter les risques en fonctionnant en forfait. Mais comme nous n’arrivons pas à livrer la qualité attendue dans le temps imparti, ils doivent passer en mode flicage.

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 ?

Il faut aider nos clients à utiliser les méthodes “agiles”. Les bénéfices sont multiples :

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 :

  1. D’arrêter les développements 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.
  2. De contrôler l’augmentation de budget 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.

Les meilleurs développeurs travaillent pour vous : Les méthodes agiles attirent en effet les développeurs expérimentés ou en quête de nouvelles compétences. Grâce au pair programming ou au rythme des itérations, ils seront plus motivés, plus efficaces et le turn-over est réduit.

Voila pour un court long article sur les bénéfices des méthodes agiles. Un dernier point en passant : L’itératif n’est pas forcément agile. Ne vous trompez pas, il manque beaucoup à UP pour devenir agile. Pour moi, la plus grosse différence tient au fait que l’on doit aider le client à décider le contenu des itérations lui-même. C’est donc bien le client qui tient les commandes ! (Pas juste le porte monnaie)

One thought on “Les bénéfices des Méthodes “Agiles””

Comments are closed.