Conduite de projet : démarche agile vs démarche monolithique

Cet article a été publié il y a 11 ans 5 mois , il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Le choix d’une méthode de projet peut influer grandement sur le succès de ce dernier. Il convient donc en amont d’une prestation de se poser les bonnes questions pour choisir la méthode la plus adaptée. Voyons ici deux approches : l’une que l’on pourrait qualifier de classique et une plus « moderne » issue des méthodes de développement agiles.

La MOA et la MOE sont sur un bateau

L’organisation classique des projets est souvent architecturée autour de deux entités :

• La MOA : la Maîtrise d’OuvrAge s’occupe des aspects fonctionnels, de la formalisation des besoins et du suivi du déroulement du projet. Elle est en relation avec les utilisateurs ;
• La MOE, Maîtrise d’OEuvre a en charge la réalisation de l’application informatique. Elle gère les équipes du projet et les éventuels sous-traitants.

Cette organisation est ancienne et héritée des projets de construction et de travaux publics. Elle se veut de prime abord rassurante, les rôles de chacun sont définis et l’interaction entre les parties évidentes. Ces deux entités sont en général chapeautées par un comité de pilotage chargé de superviser et d’arbitrer les éventuels conflits entre la MOA et la MOE.

Cette organisation va souvent de pair avec une méthodologie projet classique basée sur le processus :

• Analyse des besoins;
• Spécifications;
• Conceptions détaillées;
• Implémentation;
• Tests;
• Recette;
• Mise en production.

Le passage d’une phase à une autre est soumis à une validation. Tant que celle-ci n’est pas obtenue, on ne passe pas à l’étape  suivante.

La conduite de projet à l’ère du temps réel

Tout va plus vite, tout doit aller plus vite. Les technologies disponibles permettent aujourd’hui de mettre en place des solutions en des temps records. Ces démarches que je qualifie de monolithiques sont-elles encore adaptées ?

Ces méthodes classiques souffrent de deux maux qui ne sont pas récents :

• Elles considèrent que tous les besoins ont été exprimés et sont parfaitement compris de toutes les parties prenantes du projet;
• Les besoins ne peuvent pas évoluer au cours du projet.

Pour prendre en compte ces deux facteurs qui peuvent selon les projets être plus ou moins sensibles, il est possible d’adopter des méthodologies issues des « démarches agiles« . Il s’agit là de fonctionner selon un schéma itératif pour arriver à la solution finale.

Ainsi l’analyse des besoins va déboucher sur une liste de spécifications qu’il faudra classer par lot de réalisation et à l’intérieur de ces lots par priorité d’implémentations. On gardera à l’esprit bien sûr que certaines fonctionnalités sont dépendantes d’autres. Un point qui sera pris en compte lors de la définition des priorités.

On va donc lancer un certain nombre d’itérations basées sur ces lots. Une itération est constituée par l’implémentation d’une liste de spécifications plutôt courte. L’application est alors développée, testée et livrée aux utilisateurs pour qu’ils puissent faire leur retour. Les demandes de modifications sont prises en compte et implémentées pour donner lieu à une autre livraison.

La définition du nombre d’itérations permet de garder la maîtrise du déroulement du projet tant en terme de charge que de planning.

Cette méthode a plusieurs avantages selon moi :

• Elle est bien adaptée aux clients qui veulent rapidement disposer de l’application. La livraison même partielle est rassurante car montre l’avancement du projet;
• Elle permet de prendre en compte une expression de besoin floue ou incomplète. Car c’est devant l’application que l’utilisateur prendra conscience des oublis ou des erreurs de conception qu’il a pu commettre;
• L’interaction permanente entre les utilisateurs et l’équipe de développement. Pas d’effet tunnel, où les utilisateurs doivent attendre de longues semaines la livraison de l’application. Une meilleure compréhension des besoins utilisateurs par les développeurs.

Toutes ces considérations sont bien sûr à adapter et relativiser en fonction de chaque projet. Et vous quelle méthode préférez-vous ?