On ne présente plus en détail les deux méthodes de projets suivantes : Agile & Cycle en V.
Rappelons-en tout de même les principes fondamentaux.

Les méthodes Agiles (dont les plus utilisées sont aujourd’hui les méthodes Scrum, Kanban et Extrem Programming) procèdent par étape avec des objectifs à court terme. Le client, garant du produit (Product Owner), est placé au centre des démarches. Le besoin Métier est découpé en « User Stories » développées de manière itérative. Son évolution est encouragée.
Les projets sont découpés en « sprints » (jusqu’à un mois de durée), qui commencent par une vérification de la planification opérationnelle et se terminent par une démonstration de ce qui a été achevé, puis une rétrospective.

Le modèle « classique » de Cycle en V (ou en Cascades) se découpe en plusieurs phases identifiées dès le démarrage du projet (Définition des besoins, conceptions générale puis détaillée, réalisation /développement, tests et mise en production). La validation d’une phase entraîne le début de la suivante. Cette méthode limite les retours aux étapes précédentes.
Le Métier définit un objectif à long terme.

Les méthodologies classiques de projets s’attachent à planifier le projet de bout en bout et sont résistantes aux changements, on les dit « prédictives ».
Afin d’adapter le besoin à l’évolution rapide du marché, les projets doivent gagner en souplesse et recentrer l’objectif sur la vision produit, non seulement la vision projet.

Cependant, comment évoluer vers une nouvelle méthode lorsque l’organisation complète, ou presque, suit une approche en Cascades ? Comment être sûr que celle-ci fera ses preuves face à un référentiel déjà en place depuis des décennies ?
Une période de tests et de transition peut s’avérer rassurante ou nécessaire pour convaincre l’entreprise, prouver l’efficacité de l’agilité.

Notons 3 différences majeures entre les deux méthodes de gestion de projet :

  1. L’organisation des équipes : Management hiérarchisé pour la méthode classique, où la méthode agile met l’accent sur des équipes collaboratives et autonomes.
  2. Le séquencement des étapes du projet dans le cadre d’un modèle de cycle en V, contre une évolution et adaptation possibles du besoin et des spécifications pour les méthodes Agiles.
  3. La définition d’une date de fin de projet (méthode classique) à l’opposé d’une réalisation continue cadencée par des livraisons itératives (méthode agile).

La combinaison de ces deux méthodes au sein d’un même projet n’est pas préconisée, puisqu’elle en complique chaque étape. Néanmoins il est possible, pour les raisons évoquées ci-dessus, que certains associent ces différentes approches : sur une période de transition d’une méthode à une autre, dans le cadre d’un projet de grande ampleur stratégique ou applicative, ou au sein d’une organisation qui gère habituellement les deux méthodes en parallèle.
Nombreux sont les cas qui pourraient être cités.

Une organisation additionnant : Direction de projet, Management de projet, responsables d’applications/de département, développeurs, architectes, … est alors souvent déclinée.
Au-delà des théories et référentiels, vous trouverez ici quelques conseils, tirés de retours d’expériences, pour accompagner au mieux la réalisation de tels projets. 
Aux bonnes pratiques habituelles de réussite d’un projet (organisation claire, communication, acteurs impliqués, objectif commun ….) s’ajoutent certaines « Quick Wins » spécifiques aux projets réunissant diverses méthodes, divers référentiels.

  • S’assurer que chaque partie prenante est au fait des deux approches. Il est important que les acteurs du projet comprennent la méthode de travail et les principaux objectifs de leurs collaborateurs.
  • S’assurer plus encore que la Direction de Projet (MOE / Métier) est familière avec les deux modèles et saura trouver les solutions en tirant le meilleur des deux méthodes.
  • Former une dynamique de groupe. Cette remarque est valable pour tous les projets (y compris mono méthode), mais primordiale dans ce cas où les équipes ont des manières de travailler différentes. Cette bonne pratique peut par exemple se concrétiser par la mise en œuvre d’un plateau projet commun où les acteurs du projet sont physiquement réunis. Ceci facilite la communication, la compréhension et donc l’efficacité.
  • S’assurer que le Product Owner (PO) a le pouvoir de décision adéquat vis-à-vis du chef de projet Métier. C’est à dire un fort pouvoir de décision de ce qui doit être conçu et un devoir de validation de ce qui a été réalisé. Idéalement, le PO est le chef de projet Métier, afin de centraliser les sujets à l’aval d’une seule et même personne.
  • Mettre en étroite relation le Chef de Projet informatique (MOE) et le Scrum Master, afin que chacun ait constamment conscience des besoins, risques et réalisation de chaque équipe.
  • Réduire les évolutions du besoin exprimées par le Métier. La méthode agile permet habituellement une flexibilité totale sur les évolutions, contrairement à la méthode dite de cycle en V. Il faudra ici veiller à ce que le besoin s’adapte aux contraintes du projet mais n’évolue pas (ou très peu) vis-à-vis de la conception initiale. Ce qui est d’autant plus vrai si le projet doit être livré à date fixe.
    Le Product Owner devra être conscient de cette contrainte.
  • Adapter la phase et le planning de tests (fonctionnels et techniques) aux développements agiles. Les tests devront être anticipés afin que la phase de tests habituelle de l’approche classique inclue les diverses itérations de développements et de tests de la méthode Agile.
  • Limiter, tant que possible, la combinaison des deux méthodes sur certaines phases. Les phases de conception et réalisation (méthode classique) peuvent se dérouler en parallèle des périodes d’écriture des User Stories et de développement (méthode agile). La phase de tests fonctionnels de la méthode en V permettra aux développements agiles des itérations supplémentaires pour stabiliser la cible.
    En revanche, une phase de tests techniques (pour assurer la performance et la robustesse des applications livrées) sera nécessaire à partir d’une réalisation terminée.
  • Enfin, rappeler aux équipes impliquées sur le projet le besoin de coopération. On mettra ici en avant les pratiques agiles qui insistent sur l’engagement groupé de tous les acteurs du projet. Seule la collaboration de toute l’équipe conduit aux respects des engagements, à l’aboutissement du projet.

Combiner les deux approches divergentes n’est pas idéal et l’exercice est complexe. Néanmoins avec une telle configuration de projet, il est tout à fait possible de faire converger les équipes vers un objectif commun : la réussite du projet.
Les méthodes ne seront parfois pas appliquées à la lettre, et des adaptations seront nécessaires de part et d’autres, mais leurs principes fondamentaux devront être maintenus.