Agile ou Waterfall ?

En France, contrairement à d'autres pays, il y a une tradition qui est de diviser le rôle de Chef de Projet en deux: celui de Chef de Projet MOA (Maîtrise d'Ouvrage) et celui de Chef de Projet MOE (Maîtrise d'Oeuvre) du moins dans le contexte des Grands Comptes dans lesquel je travaille essentiellement. Cette séparation rentre sans doute dans le cadre de la théorie de la Séparation des Pouvoirs voire de la Dialectique Hégélienne mais cela engendre des conflits entre la MOA et la MOE qui ne se résolvent pas forcément dans le sens d'un juste compromis. La source de ces conflits est évidente. La MOA étant le client et la MOE étant le fournisseur, on retrouve les comportements typiques suivants: la MOA aura à tendance à en demander toujours plus, la MOE à en proposer toujours moins de peur d'être débordée. Un Directeur de DSI, dans un article de 01 Informatique, proposait comme solution de supprimer cette division en fusionnant les deux services mais cela est une idée qui mettra un certain temps à se généraliser.

A défaut il est possible de prendre un Chef de Projet portant ces deux casquettes à la fois comme cela m'est déjà arrivée. Ceci me convient parfaitement car j'apprécie plus d'être à l'interfaçage du fonctionnel (compte tenu de ma formation d'ingénieur généraliste) et du technique (compte tenu des nombreux projets techniques que j'ai eu à conduire) que dans l'un ou l'autre rôle exclusivement. Cela serait en fait dans la tendance selon 01 Informatique, néanmoins dans le cadre d'une organisation bicéphale qui subsiste encore fréquemment, la résolution des intérêts et conflits ne peut donc se faire que sur la bonne intelligence entre les deux parties.

La première intelligence passe par le sens du "bien commun". Les deux services sont certes séparés mais ils font partie de la même organisation. Le bien commun est d'aboutir à un produit de qualité qui satisfasse les utilisateurs. Pour cela il faut respecter un certain process, en l'occurrence la prioritization des besoins et la mise en adéquation de solutions adaptées à ces besoins. Cette prioritization, qui est du ressort de la MOA, devrait se faire en concertation avec les utilisateurs afin que cela corresponde à la réalité. Quant aux choix de solutions, le Chef de Projet MOE doit être particulièrement vigilant vis à vis de celles conseillées par les équipes techniques qui ont une certaine tendance à choisir les outils ou frameworks derniers cris mais qui ne sont pas encore forcément mâtures (l'histoire des EJB2 sur J2EE l'a bien montré).

La deuxième intelligence est de ne pas couper totalement les développeurs des utilisateurs, de ne pas les considérer comme seulement des "pisseurs de code" incapables de comprendre le langage des utilisateurs. Certains développeurs n'aiment pas effectivement le contact des utilisateurs, mais pas tous loin de là, et dans ce cas, il est profitable que les élicitations de certains besoins puissent se faire en direct car même si des spécifications papiers existent dans le cadre d'une méthodologie, force est de constater que pour certains types de besoin, il est difficile de les formaliser dans les détails. Même quand cela serait possible, cela prendrait tellement de temps que cela est anti-économique. Hors dans le cadre du respect d'un Budget, il est pertinent de choisir la voix optimale en terme de coût/délai/qualité. L'agilité est un process qui a pour objectif majeur de répondre à ces contraintes même dans un cadre restreint au sein d'un autre plus vaste qui pourrait être celui du cycle en V où des spécifications auront déjà été établies mais seront raffinées ensuite entre les développeurs et le product owner qui est un Expert Métier facilitant ainsi la remontée généralement fastidieuse de la deuxième branche du cycle en V. Cette approche avait été en fait déjà suggérée dans mon précédent article ("Adapter le Process Agile à une Organisation Grand Compte: Concilier avec la Gouvernance").

La troisième intelligence est de sensibiliser et de former les développeurs aux méthodologies de test et de gestion de configuration logicielle afin qu'ils ne se contentent pas de juste coder et compiler sans vérifier qu'ils n'ont pas engendré des régressions sur l'application et/ou de se reposer sur la Recette MOA pour livrer un produit correct. En effet la Recette MOA est une approche de type boîte noire et donc par la force des choses, elle ne peut pas réaliser toutes les combinatoires possibles. Les développeurs et l'architecte ont la connaissance interne de cette boîte et peuvent mettre au point des tests plus pertinents. Du point de vue des procédures qualités, il vaut toujours mieux faire du pré-contrôle que du post-contrôle. Même si le post-contrôle reste nécessaire ne serait-ce que du point de vue contractuel, le vrai contrôle qualité doit se faire en amont.

La quatrième intelligence est d'éviter la langue de bois. Les deux chefs de projet doivent adopter un niveau de discours commun afin de se comprendre l'un et l'autre car l'un étant plus métier et l'autre plus technique, l'incompréhension guette. Chacun devrait donc faire l'effort d'expliquer les vocabulaires et concepts de base de son domaine à l'autre afin que les échanges puissent s'effectuer de manière plus fluide sur des termes communs. Par exemple l'usage d'UML n'est pas impossible pour communiquer avec des utilisateurs ou des managers à condition de bien faire attention à être synthétique, pédagogique et attractif dans la présentation afin de gommer son aspect trop technique.

Il y aurait sans doute de quoi écrire un livre entier mais je pense que j'ai émis quelques idées phares qui sont issues des observations sur le terrain sur mes propres projets ou sur les projets des collègues.

Articles en relation:
01-Informatique: Des modèles en constante évolution