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

closeCet article a été publié il y a 8 ans 3 mois 23 jours, 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 ?

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

6 réponses

  1. david dit :

    Excellent article.

    1 petite coquille

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

    =>

    Ces méthodes classiques souffrent de deux … MAUX …. qui ne sont pas récents

  2. Philippe dit :

    Merci c’est corrigé

  3. Bonob0h dit :

    Le problème de l’agile, c’est que nombre, la majorités, des personnes n’y sont pas « formées/adaptées » tellement ancrées dans le monolithe 😉 Et c’est très dure de faire changer / évoluer les mentalités etc !

  4. Christo dit :

    Oui, les méthodes agiles sont attirantes.
    mais elles nécessitent une implication (très) forte des utilisateurs : s’ils ne sont pas disponibles cette méthode tombe à l’eau.
    En fait le mot « agile » est mal choisi : c’est une démarche projet qui demande un pilotage serré et une collaboration forte entre MOA et MOE.

    Elle ne dispense pas de partir d’une expression de besoins déjà bien aboutie car si les utilisateurs changent d’avis à chaque livraison, alors on va dans le mur.

    Donc oui pour les méthodes agiles, si les deux parties MOA et MOA sont formées à cette approche et conscients des contraintes.

  5. toto dit :

    Ces méthodes ont à l’origine été faites pour gérer des choses assez simples que le client voit. Non ce qu’il y a « sous le capot ».

    L’exemple type en développement logiciel, c’est les interfaces graphiques ou le look&feel d’une application: Rajouter une icone ici, changer un élement de pérsentation là. Des choses au final assez simples à faire évoluer mais d’expérience assez difficiles à faire bien sur spec.

    Le souçi, c’est que des gourous de l’agilité y ont vu un filon et on pris pour objectif de le faire croitre: Certaines sociétés y sont venues pour du soft bas niveau: Portage d’OS, drivers… voire pour le développement du matériel!

    Sauf que là on est dans le domaine qui dépasse souvent les compétances du client (sinon ferait-il appel à vous?), dans lequel rajouter une fonctionnalité ne sera pas forcément aisé ni forcément possible (sauf à refaire une carte).

    Le concept dévie donc sur un truc qui tue la gestion de projet classique au profit de scrum master par exemple (mais sans évolution hiérarchique car les 2 sont dissociés, donc responsabilités sans salaire: Top motivation à attendre)… tout en sapant la relation hiérarchique qui n’est plus qu’administrative. Ne parlons pas de l’opinion des développeurs perdant leur temps dans des réunions journalières inutiles et autres prises de participation dans ce qui était initialement le role de la gestion de projet (chacun prenant son ticket de fonctionnalités pour l’itération à venir… dans qu’il sait faire vite, repoussant fort humainement… les emmerdes à la fin!), là aussi couteuses en temps (compter 3 journées par mois de perdues globalement)… lui donnant en prime l’impression d’être « collé au rapport journalier » déguisé.

    Le pire étant quand en prime il y a du fric pour ces conneries (formation, consultants à la con…) et non pour vous augmenter.

    Ces méthodes étaient sans doute adaptées pour ce pour quoi elles ont été faites… Le pb est l’écosystème très américanisé qui s’est crée autour ce ceci et qui comme souvent, arrivé à une certaine croissance, s’embale et cherche à augmenter/diversifier son marché.

    Comme ce ne sont plus des ingénieurs qui sont aux manettes des grands groupes, mais des financiers, ils trouvent une oreille attentive 🙁

  6. Philippe dit :

    @toto : je suis d’accord pour dire que les méthodes agiles ne se prêtent pas à tous les projets, ni tous les clients… C’est à rappeler effectivement