Non, non… Rassurez-vous ! Je ne vais pas vous expliquer qu’il faut se mettre à la gym ou aux arts du cirque pour mener à bien un projet informatique.
Je veux juste objectivement aborder la gestion de projet sous un angle qui est très souvent négligé car peu ancré dans la culture des directions de projet.
Je veux vous parler de la « méthode » Agile.
La gestion classique VS la démarche Agile
Tout d’abord, Agile n’est certainement pas une méthode, mais plutôt une approche différente de la dimension projet. Ce n’est pas une approche nouvelle car le « Manifeste Agile » date de2001.
Trop souvent Agile est associé à du RAD (développement rapide d’application), le réduisant ainsi à l’activité de développement de logiciels. Qu’Agile s’adresse à cette activité, ce n’est pas faux, mais trop réducteur.
Le principe fondamental d’une démarche Agile est de fonctionner par itérations, c’est-à-dire de découper le projet en plusieurs parties. Cela permet d’éviter, notamment, l’effet tunnel, parfois désastreux, dans la gestion classique d’un projet.
La gestion classique est dite « projet cycle en V » ou « en cascade ». La globalité du projet se base sur un cahier des charges initial très détaillé, suivi d’une phase de spécifications, puis de réalisation avec une recette finale.
C’est à ce moment là, au moment de la recette, qu’on l’on peut souvent constater un décalage entre les attentes et le rendu. Cette démarche n’autorise surtout aucun changement, aucune adaptation, et implique très peu le client final, seul le cahier des charges initial faisant foi pour la recette.
La démarche Agile, justement, considère qu’un projet ne doit pas être figé et doit s’adapter à l’évolution du besoin. Une phrase illustre très bien ce propos : « Oubliez le cahier des charges, soyez agiles » (Anthony Bleton).
Attention, il n’est pas question, non plus de jeter en bloc la gestion « Prédictive » d’un projet, il y a des cas de figures dans lesquels cette démarche fonctionne très bien et est parfois obligatoire.
L’exemple du dîner, ou comment servir les plats chauds
Pour illustrer le propos, prenons en exemple le projet d’organiser un diner.
Dans une gestion classique, il nous faut prévoir et minuter toutes les composantes du diner : nombre de convives, durée de chaque étape, intervenants nécessaires.
L’expression de besoin étant claire, il faut maintenant constituer le cahier des charges, et décrire minutieusement ce que l’on attend de ce projet : durée de l’apéritif, de l’entrée, du plat de résistance, du fromage, du dessert. Mais aussi spécifier les ingrédients qu’il est nécessaire de commander, les durées de cuisson, et les heures de démarrage des cuissons.
Une fois le cahier des charges constitué, on le confie à un prestataire pour la réalisation.
Mais les imprévus ne vont certainement pas manquer : convives en retard ou manquant, apéritif plus long que prévu, ingrédient introuvable ou plus cher que prévu, rendant très vite les spécifications caduques. Les plats risquent d’être servis froids.
La déception de la MOA de ne pas voir son plan appliqué à la lettre risque d’être grande, avec en plus des résultats non conformes aux attentes. Le sentiment d’avoir passé beaucoup de temps à la rédaction du cahier des charges pour un résultat final insatisfaisant renforcera les tensions de fin de projet.
Dans la démarche Agile, cela consisterait à être beaucoup plus pragmatique, et à lancer la succession des tâches au fur et à mesure. Par exemple dans la démarche Agile, on ne lancerait la cuisson qu’au démarrage de l’entrée.
L’idée est de fixer un objectif simple et accessible au début, et de faire interagir les autres phases en fonction de l’évolution des opérations menées et du feed-back. Beaucoup parlent d’une « approche empirique » des processus de systèmes, quelle que soit leur complexité, en opposition à l’ « approche déterministe ».
Alors qu’est-ce qu’un projet Agile ?
C’est la capacité de pouvoir très rapidement montrer une maquette opérationnelle au client, de lui laisser ainsi la possibilité de pouvoir voir très vite dans quel sens va son projet et en quoi la solution déployée peut y répondre.
Cela lui permet, surtout, de pouvoir faire des feed-back rapides, et réorienter les exigences pour obtenir la meilleure valeur ajoutée en fonction des ressources allouées.
Un projet n’est pas Agile lorsqu’il est exigé que les réalisations soient exactes aux exigences initiales, forcément incomplètes et qui ne tiennent pas compte d’une évolution dans la réflexion, le besoin et les contraintes non prévisibles.
Thierry, Directeur du Consulting chez Apsynet
