Méthodes de gestion des projets

I. Prince2, Agile, Scrum… Quelle méthode choisir ?

Méthodes de gestion des projets : Avant de choisir, clarifier les choses un peu est nécessaire. Il faut connaitre les méthodes qui proposent une procédure complète, un cadre réel; des outils spécialisés sur un état spécifique : Gantt , Pert , WBS…

Une des méthodes les plus incontournables est Prince2 . Se basant sur les processus, l’approche réservée est de décomposer les tâches à faire en phases tout en se concentrant sur les livrables.

Moins formelles, les méthodes agiles permettent particulièrement de mettre les besoins du client au cœur des processus tout en priorisant le dialogue entre les différentes parties prenantes.

La rigidité se remplace par la souplesse , il y a une possibilité de retours, les spécifications non figées. C’est une conception différente qui laisse sa place à l’efficacité.

Il y en a plusieurs autres méthodes spécifiques s’adaptant avec les problèmes rencontrés, le MSP ( Managing Successful Programmes ) par exemple résume les bonnes pratiques concernant le changement de transformation.

II. Comment gérer la complexité des projets ?

On peut dire qu’un projet est complexe à l’instant où les entrées sont multiples, interagissent entre elles et forment des états (ou problématiques) qui ne sont pas prévisibles facilement.

Elles peuvent être des parties prenantes qui possèdent chacune la même capacité de décision, mais des avis différents, voire des objectifs opposés vis à vis les attentes des livrables.

Toujours, sur le plan humain, la prise de décisions inacceptées par les employés, engendre la complexification du processus.

La complexité peut généralement être technologique pour des applications et des tâches précises.

Quoi qu’il en soit la démarche doit être encore plus fine dans la gestion du projet. Le responsable doit être à l’écoute de toutes les parties prenantes, de leurs politiques, de leurs intérêts et de leurs stratégies.

Une petite révision de « l’acteur et le système » de Crozier et Sérieyx se manifeste pour assurer le déchiffrage des comportements des individus.

Il doit forcément maîtriser les méthodologies de conduite de projets et savoir gérer son équipe, pour pouvoir par conséquent gérer la complexité technique rencontrée.

L’approche systémique qui s’applique à la gestion de projets complexes est une approche à envisager. La modélisation et la simulation permettent en revanche de résoudre des problèmes complexes.

III. L’essentiel sur les méthodes Agiles

Découvrons les principes des méthodes Agiles et leurs apports comparés aux approches classiques de gestion de projet, notamment pour le framework Scrum.

1. Que signifie « Agile » en gestion de projet ?

Alors que les méthodes classiques ont pour objectif le traitement des diverses phases d’un projet d’une manière séquentielle (nommé aussi cycle de développement en cascade ou bien cycle en V ), le principe des approches Agiles est de le décomposer en sous-éléments (ou sous-projets) autonomes (on parle ici du développement itératif). Les « itérations » forment le projet dans sa globalité.

a. Le Manifeste Agile, les principes fondateurs

Ces méthodes sont issues du Manifeste Agile, des pratiques proposées par des spécialistes en 2001 pour simplifier le développement de logiciels.

Ce document met en place 4 valeurs :

-la prééminence des personnes et des interactions sur les processus et outils.
-un privilège pour un logiciel qui fonctionne plutôt qu’une documentation complète.
-une relation différente avec les clients : une collaboration continue qui remplace une négociation de contrat.
-une adaptation permanente au changement et non le suivi solide d’un plan.

Dépendant de ces valeurs, le Manifeste détermine 12 principes :

1 – La priorité est pour l’obtention de la satisfaction client au plus tôt par la livraison rapide et régulièrement organisée des fonctionnalités voulues.

2 – être flexible avec les besoins de changement en cours d’un projet. Ce sont des opportunités pour mieux valoriser le projet et se rattacher aux besoins réels des clients.

3 – Mettre en place des livraisons rapides se basant sur des cycles courts qui ne dépassent pas quelques semaines. Ces livrables doivent être opérationnels pour autoriser les tests de validation des fonctionnalités en question.

4 – Collaboration puissante et continue entre les utilisateurs et le développement. Inversement aux méthode traditionnelles où les rencontres entre les usagers et la maîtrise d’œuvre interviennent en particulier au début et à la fin du projet.

5 – Permettre de l’autonomie à des personnes engagées et leur donner confiance.

6 – Prioriser le contact direct (face to face) comme moyen de communication entre les différentes parties. Les interactions sont plus efficaces et plus enrichies. Tout va rapidement.

7 – Avoir une application opérationnelle est le plus important.

8 – Progresser avec un rythme constant qui convient avec ce que peut produire les différents acteurs.

9 – Concentration sur la qualité technique et la qualité de conception pour concevoir une base solide pouvant renforcer l’agilité.

10 – Demeurer simple dans les méthodologies de travail : ne réaliser que le nécessaire.

11 – Une équipe qui s’organise toute seule obtient des résultats plus meilleures.

12 – En revoyant ses pratiques de façon régulière, l’équipe adapte son comportement et ses outils pour être plus efficace.

b. Quels sont les avantages ?

Cette approche permet d’avoir :

  • plus de flexibilité en agissant sur des sous-parties autonomes. Elles peuvent être créées, testées, modifiées de nouveau sans que le projet dans sa totalité ne soit impacté. La prise en considération des besoins non définis dans la phase d’analyse ou bien l’émergence de nouvelles fonctionnalités au cours du développement peuvent être implémentées. Expérimentalement, il est difficile de réfléchir à tout dans la phase d’identification de besoin pour une approche traditionnelle de gestion de projet.
  • Plus d’efficacité et de qualité : en simplifiant la complexité, en testant continuellement, en favorisant les feedbacks des clients.
  • Réduction des risques : détection rapide par l’intermédiaire des cycles courts.
  • Maîtrise des coûts plus meilleure : pas de retours qui coûtent en arrière – le cas échéant le projet peut être arrêté immédiatement.

c. Mais aussi des limites

La flexibilité maximale peut amener à un enlisement du projet . Plusieurs itérations sans que des directions ou décisions ne soient figées peuvent être considérées comme un véritable danger.

Parmi les causes possibles des revirements continus des clients quant à leurs particularités.

Dans ces cas, le chef de projet (quelle que soit sa dénomination dans la méthode sélectionnée) doit être capable de faire l’arbitrage pour l’intérêt du projet, mais aussi celui…du client.

Méthodes agile
Méthodes agile

Le concept de l’agilité est repris d’une manière structurée par de nombreuses méthodes. L’une des plus populaires :

d. La méthode Scrum

Conçue par Hirotaka Takeuchi et Ikujiro Nonaka puis formalisée par Ken Schwaber et Jeff Sutherland, cette méthode met en place un cadre très structuré pour appliquer les règles de l’agilité.

Le Sprint, le coeur de Scrum

Ce concept se base sur des itérations de 2 à 4 semaines. Ce sont les fameux « Sprints ». Il s’agit des sous-parties d’un projet comme est défini par le principe Agile. Chaque Sprint vise à fournir au client une version potentiellement utilisable du produit.

Les Sprints successifs rajoutent des nouvelles options au produit ou développent celles déjà conçues. On l’appelle l’incrément de produit.

Un Sprint démarre juste après la fin d’un précédent. C’est un processus incrémental.

Ce cadre se base sur 3 piliers qui sont :

  • la transparence : mise en place d’un standard commun pour assurer une compréhension commune.
  • l’inspection : des vérifications sont réalisées de manière régulière.
  • l’adaptation : en cas de dérive remarquée pendant l’inspection, des corrections sont décidés.

Les Sprints se structurent autour de plusieurs outils organisationnels (appelés événements) :

-Sprint planning (Planification du sprint) : réunion pour définir et planifier les priorités de chaque Sprint en terme de fonctionnalités produit (Sprint Backlog).

-Scrum (Mélée quotidienne) : réunion quotidienne de coordination entre les membres de l’équipe qui travaille sur le projet. Elle prend souvent la forme de « Stand-up meeting » (réunion de courte durée, 10-15mn, tenue debout).

-Sprint Review (Revue de Sprint) : réunion de synthèse à la fin de chaque Sprint pour confirmer les fonctionnalités mises en œuvre.

-Sprint Retrospective (Rétrospective de Sprint) : vient juste après la revue de Sprint, c’est un bilan qui a comme objectif l’amélioration permanente des pratiques. L’équipe veille sur les succès, les contraintes, identifie ce qui fonctionne ou pas. Avec bien sûr des conclusions à utiliser pour les prochains Sprints.

Comprenant des entrants et sortants du processus, appelés « artéfacts »

*Product Backlog : liste des fonctionnalités du produit.

*Sprint Backlog : planification des éléments du Product Backlog à mettre en place pendant le Sprint pour livrer l’incrément de produit doté des options requises pour cette phase. Le Sprint Backlog n’est pas figé, mais est appelé à croître pendant le Sprint.

*L’incrément de produit : déjà évoqué précédemment.

Avec des rôles définis pour chacun :

*Product Owner – PO (propriétaire du produit) : le spécialiste métier, le maître d’ouvrage, représente le client et agit sur la partie fonctionnelle.

*Scrum Master (maître de mêlée) : le coordinateur du projet et le garant de la bonne application de la méthode Scrum.

*Team (équipe) : les autres acteurs travaillant sur le projet (également les développeurs).

e. Les autres méthodes de développement Agile

à côté de Scrum, il y en a d’autres approches, avec chacune ses caractéristiques :

-Extreme Programming (XP) : très utilisée dans l’ingénierie logicielle

-FDD (Feature-Driven Development)

-Dynamic System Development Method (DSDM) : parmi les plus anciennes

-Adaptive software development (ASD)

-Crystal Clear : orienté « petites équipes »

IV. Gestion de portefeuille de projets

Comment choisir les projets à faire selon la stratégie de l’entreprise et des ressources à réserver. Quels critères de choix adopter pour privilégier les problématiques à traiter ?

Plusieurs entreprises gagneraient en performance en appliquant une démarche précise ou du moins organisée, pour gérer leur portefeuille projets.

En effet, les possibilités d’investissement ne sont pas extensibles. De même, il y a des projets qui sont plus importants et plus urgents que d’autres. Ainsi, comment faire pour prioriser et faire ses choix ? Découvrons ce que dit les experts sur Internet.

V. Proof of concept : l’essentiel à connaître pour l’utiliser à bon escient

Vulgarisé avec l’apogée du digital et le style des startup, le proof of concept (ou preuve de concept, avec son acronyme PoC) est l’une des plus meilleures méthodes de gestion de projet.

1. Définition du proof of concept

C’est une démarche qui a le but de vérifier qu’une théorie, un concept ou encore une idée (souvent innovante) « est capable de fonctionner » sur le plan marketing, économique, et technique.

Elle s’applique à tous les sujets : conception d’un nouveau produit, réorganisation d’un service, développement d’un logiciel..etc.

Une preuve de notion a comme but de montrer la présence d’une opportunité (ou « désirabilité ») et/ou la faisabilité d’un système. La procédure se résume par la réponse à la question « Est-ce qu’on peut faire cela ? »

Avec les deux dimensions : est-ce que les clients désirent un tel produit ? / Est-on capable de le réaliser ? La réponse est oui ou non, « GO » ou « NO GO » .

On utilise Le proof of concept très tôt dans le processus de gestion de projets. Il contribue au cadrage. Il peut d’ailleurs être sous forme d’un « mini projet ». Prisé par les méthodes agiles, le PoC est notamment utilisé par le concept « design thinking ».

Ce concept/approche peut être sous la forme d’une étude, d’un petit prototype pour démontrer ce que peut être le produit ou service.

Cette nomenclature cache une pratique suivie depuis un certain temps dans plusieurs domaines. En effet, nombre de projets démarrent par une étape de test pour confirmer les hypothèses de départ.

Cet outil s’intègre alors complètement dans un contexte qui demande plus d’agilité et de rapidité en présence d’un consommateur qui devient de plus en plus insaisissable.

a. Différences avec le prototype et le Minimum Viable Products (MVP)

La littérature sur internet diffuse plusieurs définitions différentes, interprétations et utilisations de ces outils. Pour quelques uns, le PoC est un prototype qui, en parallèle avec des itérations et des interactions avec les usagers, devient un produit final.

Pour d’autres, il joue le rôle d’une phase limitée en début de projet, le prototypage qui représente une deuxième étape même dans le cas où un PoC peut représenter un prototype, l’objectif est toujours la vérification de la faisabilité et la désirabilité du livrable. C’est ce que nous allons présenter ci-après :

Le prototype

Parfois par confusion avec le PoC, le prototype se place par la suite dans le cycle de vie du projet. Il répond à la question  » Comment se fera-t-il ? « .

Il vise à vérifier l’efficacité des fonctions et de l’utilisabilité du produit (ou service) au besoin, à ses usages en fournissant une version simple aux usagers clés.

à titre d’exemple, pour une application mobile, on peut trouver des images écran successives pour la simulation de la navigation.

Pour un produit physique, il peut s’agir d’une maquette en carton pour une première utilisation. Le prototype permet ainsi d’étudier les dimensions techniques du produit.

Le Minimum Viable Products (MVP)

Le MVP – cher au Lean startup – est un produit complètement fonctionnel, ayant des caractéristiques essentielles pour être testé à grandeur nature sur un marché grâce à des « early adopters ».

Soit une version minimale du produit final qui, au contraire du prototype, peut être commercialisé. Il peut répondre à la question  » Est-ce viable ? » .

Il s’intègre dans une procédure itérative pour concevoir le produit optimal en le développant en parallèle par des retours. Il assure le lancement rapide d’une boucle d’apprentissage.

A noter : le concept de « Pilote » est proche du MVP, avec l’idée d’industrialisation et de commercialisation sur une zone limitée.

outil proof of concept

2. Les avantages du PoC

Cette phase clé permet de réduire le taux de risques et des incertitudes avant de s’approfondir dans le projet. Il confirme la bonne qualité du projet.

3. Les points de vigilance

Quelques bonnes règles et la rigueur sont à respecter pour obtenir un résultat satisfaisant :

-Bien choisir la zone du test (segments de client, domaines d’application…). Dans le cas inverse, les résultats pourraient être floues ou même erronés.

-Définir rigoureusement les hypothèses de départ.

-Posséder des instruments de mesure efficaces qui permettent de fournir des réponses aux questions de démarrage.

4. Comment mener un proof of Concept ?

Cette phase repose sur les outils ordinaires d’études que sont les recherches documentaires, les études marketing, l’analyse de données (big data)..etc.

On peut aussi tester la réaction des consommateurs sur des critères bien déterminés.

Il peut s’agir, par exemple, du nombre d’inscriptions enregistrées dans le but d’être renseigné sur un sujet associé au concept.

Cela permettra d’en définir l’intérêt. Il peut bien évidemment être sous forme d’un prototype de base très conceptuel.

5. Exemples de proofs of concept

Pour un projet mobile, le proof of concept peut viser à vérifier que deux technologies au moins peuvent fonctionner ensemble avant de passer à l’étape suivante. Sans cela le projet ne sera pas réaliste.

Pour une startup, le PoC sert à démontrer la viabilité du business model (modèle économique) pour convaincre des investisseurs potentiels de l’opportunité existante fournie par le projet.

VI. Connaître et utiliser l’Analyse de la Valeur (AV)

Voilà une méthode susceptible d’être plus employée aussi bien dans les approches techniques que marketing.

En effet, portée par une procédure et des outils pertinents, elle permet de recentrer la création d’un produit sur sa valeur d’utilisation réelle. Une valeur prévue par les clients.

Axée sur l’analyse fonctionnelle, cette méthode consiste à comprendre l’apport de chaque attribut d’un produit ou d’un service à l’offre proposée aux besoins d’un marché.

Elle prend en considération les autres dimensions associées à l’offre, également les coûts et les contraintes environnementales.

VII. Comprendre le modèle CMMI®

Pourquoi le CMMI®…? « En tout cas, comme les autres, ce projet ne se terminera pas dans les délais…». Ce type de sarcasme qui s’exprime en face d’une machine à café peut refléter une réalité peu flatteuse, mais néanmoins fondée : des problèmes structurels à créer le succès des projets.

Même lors de l’utilisation de méthodes ou de processus internes, ils ne permettent pas toujours de s’adapter à un environnement mobile et compétitif, et peuvent donc réduire leur réplicabilité – et in fine leur légitimité.

Dès lors, comment objectiver la mesure de ces problèmes structurels et mettre en place des processus de développement continu efficace et pérenne ? C’est là où il apparait le rôle du Capability Maturity Model Integration, regroupé derrière le sigle CMMI®.

1. Genèse et définition du modèle CMMI®

Le modèle CMMI® a été conçu par le DoD (département de la Défense des États-Unis) dans les années 1980, pour lequel seulement 5% des projets étaient délivrés conformes et respectaient les délais.

Ces contraintes ont amené à la création d’un référentiel de critères lui permettant d’évaluer ses fournisseurs de logiciels. Le modèle CMMI® amène en fin de compte en 1991, appliqué au début au génie logiciel (software) seulement.

Le CMMI a été ensuite prolongé vers d’autres secteurs : matériel informatique (hardware), fourniture de service, GRH…

La légitimité du CMMI® provient du grand nombre d’obstacles potentiels au succès d’un projet. Gestion du budget, réponse aux obligations, reporting, management…

Plusieurs éléments inhérents à une organisation qui peuvent, isolés, devenir une source de divergence au niveau du temps et du budget.

Le CMMI® donne un contexte méthodologique qui assure une efficacité organisationnelle globale, en partant d’un modèle de référence et de bonnes pratiques.

L’objectif est d’évaluer la capacité d’une structure à faire réussir des projets, au niveau de délais, de fonctionnalités et de budget.

Il est essentiellement utilisé par les grandes entreprises qui créent des projets informatiques de grande taille (Intel, Nokia, IBM, Motorola…).

2. Progresser dans la maturité des processus du management de projet

L’évaluation de cette capacité est réalisée par l’intermédiaire d’une échelle de mesure de la maturité à cinq niveaux, défragmentés en indicateurs permettant d’apprécier les activités surveillées par une « équipe » (groupe de collaborateurs, équipe projet ou organisation entière).

Bien que le modèle CMMI® est différent entre un métier et un autre, il est structuré autour d’un noyau appelé « core » qui englobe environ 60% des pratiques.

Généralement, l’approche par la maturité permet aux organisations de devenir plus solides face aux aléas de leur environnement (technologique, concurrentiel…) en mettant en œuvre des processus efficaces, communs et compris par tout le monde.

Chacun des cinq niveaux est relié à un ensemble de processus, classés selon quatre types : gestion de projet, ingénierie, support et gestion des processus. Les niveaux deux à cinq sont sujets d’une certification.

Modèle CMMI

Niveau 1 : Initial

Les processus sont aléatoires et « réactifs », ce qui augmente les risques de sous-qualité et de divergences.

Le succès des projets se base plus sur les capacités individuelles des porteurs de projets que sur des efforts collectifs et coordonnés.

Niveau 2 : Géré ( managed )

On est arrivé à un certain niveau de management de projet. Les projets sont planifiés, réalisés et évalués, mais il reste à améliorer plusieurs éléments.

Les processus commencent à devenir réplicables.

Niveau 3 : Définis

Les organisations qui sont arrivées à ce niveau sont plus proactives que réactives. Des standards au niveau de l’organisation sont mis en place pour gérer les projets. Les différentes composantes définissent leurs points faibles et leurs axes d’amélioration.

Niveau 4 : Gérés quantitativement

La mesure des écarts et leur pilotage ont été améliorés. L’organisation fonctionne à partir de données quantitatives pour exécuter des processus bien déterminés associés aux attentes des acteurs.

Les risques sont prévus et l’on dispose de plus de données sur les éventuelles faiblesses.

Niveau 5 : Optimisé ou en cours d’optimisation

On arrive à la phase ultime de l’amélioration continue, où les processus sont fixes et flexibles. C’est le terreau optimal pour mettre en place des procédures « agiles » et innovantes, dans un environnement de plus en plus maîtrisé.

à noter : le modèle CMMI® est compatible avec d’autres modèles (Scrum, Prince 2…) qui contribuent également à l’avancement sur l’échelle de valorisation des capacités.

3. Mise en œuvre

Une procédure CMMI® représente un projet indépendant, qui a besoin d’allouer des ressources humaines et financières importantes. L’équipe sera composée de :

-représentants de l’organisation évaluée ;

-représentants de la société évaluatrice. Celle-ci doit être certifiée par l’ISACA.

Le projet CMMI se réalise ainsi en cinq étapes, de l’initialisation jusqu’à l’évaluation finale, qui s’apparente à un audit de la mise en place des bonnes pratiques au sein de l’organisation.

Elle donne une image des pratiques au sein de l’organisation à l’instant de l’évaluation, mais n’aboutit pas à une certification.

On peut atteindre un niveau supérieur dès lors que la mise en place opérationnelle des bonnes pratiques exigées par le modèle CMMI® sur les projets est validée.

4. Résultats attendus

Selon le CMMI institute, la mise en œuvre de la méthodologie permet d’améliorer la qualité des produits de 70%, d’augmenter la productivité de 54% et la vitesse de développement de 23%.

Par conséquent, l’idée principale du modèle CMMI® est de mettre la performance des processus au centre de l’organisation, en associant les objectifs avec les opérations de façon directe et par l’intermédiaire d’une meilleure conduite des indicateurs.

Ensuite, la « sécurisation » des niveaux par effet de cliquet permet de fusionner agilité et résilience dans une même démarche, en exécutant des processus compatibles avec un environnement évolutif.

Les entreprises certifiées peuvent bénéficier des expériences et apprentissages qu’elles ont réalisé, mais aussi par d’autres formes à travers un contenu régulièrement révisé par le CMMI institute.

5. Inconvénients

Néanmoins, l’aspect exhaustif du modèle CMMI® représente aussi sa faiblesse : il peut être vu comme trop détaillé, et l’on est submergé rapidement d’informations dans une première approche (5 niveaux, 25 critères, 4 catégories de processus…).

Il exige donc une bonne expérience pratique, associée à une culture organisationnelle ouverte au changement (implication des employés, communication…). Il s’agira ainsi de choisir le «bon» niveau de maturité pour l’organisation.

De plus, le frais élevé d’une certification CMMI® doit être apprécié selon les bénéfices attendus, au-delà des taux de progrès annoncés par le CMMI institute.

VIII. Cycle en V en gestion de projet : définition et méthode

Le cycle en V est un modèle qui fait impliquer toutes les phases du cycle de vie d’un projet : conception, réalisation, validation.

1. Définition du cycle en V

Le cycle en V en gestion de projet est issu du modèle en cascade conçu aux années 1970, qui permet d’envisager des processus de développement linéairement et en phases successives.

Ce mode de gestion de projet a été amélioré aux années 1980 et appliqué au secteur des projets industriels, puis diffusé aux projets informatiques.

Il a subi des défis importants à partir des années 2000, à cause de l’accélération des évolutions technologiques, favorisant davantage les méthodes « agiles ».

La lettre V est issue de la schématisation de ce cycle, prenant la forme V : une phase descendante suivie d’une phase ascendante. Le cycle en V associe à chaque phase de réalisation une phase de validation, comme le montre le schéma suivant :

Cycle en V

2. Avantages de cette méthodologie

Le principal avantage du cycle en V est qu’il ne permet pas de revenir en arrière continuellement pour redéfinir les premières spécifications, comme un cliquet.

Chaque phase de conception a besoin de la rédaction d’une documentation rigoureuse et détaillée, où chaque élément doit être confirmé par le produit final.

Dès lors qu’une étape est confirmée, on ne recule pas et on passe à la phase qui suit sur une base solide; c’est la principale force du cycle en V.

En plus de son aspect rigoureux et intuitif en même temps, le cycle en V devient un processus qui peut être exécuté facilement.

Le travail préalable de détermination des spécifications au départ du projet fait que, une fois lancé, l’ensemble des phases est connu des contributeurs, qui peuvent se repérer facilement dans la temporalité du projet et connaître l’objectif de leurs actions.

De la même façon, les documentations requises pour chaque phase peuvent être répliquées d’un projet à l’autre au niveau structurel (cahiers des charges, cahiers de test…).

Généralement, le cycle en V convient mieux aux structures multisites, car il n’exige pas de réunions chaque jour, mais uniquement des réunions de conduite actant le passage d’une étape à l’autre.

Son aspect linéaire permet donc une structuration géographiquement éclatée, où le côtoiement des contributeurs n’est pas clé dans le processus.

3. Inconvénients

L’inconvénient principal du cycle en V se résume en deux mots : l’effet tunnel. Après une étape de définition précise du produit lequel doit l’équipe atteindre, le projet est lancé dans un « tunnel » composé des phases citées précédemment.

Mais qu’est ce qu’on fait si les spécifications initiales sont dépassées ? Si les attentes du client viennent à se modifier, ou ont été mal exprimées ? Le cycle en V supporte ainsi mal les changements, ce qui est en même temps sa force et sa faiblesse.

Il fournit donc moins de réactivité de point de vue technologique et économique, aux demandes du client, aux événements inopinés; la prise de risque s’en trouvera automatiquement limitée.

L’effet tunnel est aussi généré par le travail conséquent de production de la documentation en début de projet, qui ne peut pas être rectifiée plus tard.

Finalement, l’image du tunnel montre le temps parfois très long qui sépare l’expression du besoin de la recette du produit final.

4. Cycle en V vs. méthodes agiles

Généralement, on peut confirmer que le cycle en V se concentre sur le processus, alors que les méthodes agiles priorisent le produit.

Dans le contexte des méthodes agiles (Scrum, XP, RAD, …), le projet s’affine par itérations , en répétant un cycle d’opérations (le sprint dans la méthode Scrum).

Comme a été cité plus haut, le cycle en V détermine l’intégralité du produit final dès les premières phases, et ne laisse que peu d’espace à l’adaptation dans ce qui suit du cycle.

Puis, les méthodes agiles permettent de concevoir le produit par incrémentation. On produit un peu plus à chaque fois, morceau par morceau, pour atteindre le résultat final.

Le cycle en V concentre contrairement l’établissement de l’ensemble en une seule phase, qui est complètement produite en amont et vérifiée en aval.

Ce manque d’adaptation et de flexibilité du cycle en V a provoqué l’émergence des méthodes agiles, notamment dans le secteur de logiciels et du marketing, pour réagir aux changements accélérés des technologies et des besoins de consommateurs.

5. Mise en œuvre du cycle en V

a. Pour quels projets ?

Face aux éléments présentés plus haut, les éléments suivants favorisent l’adoption du cycle en V :

-Des besoins très précis émis par les clients, par exemple dans les appels d’offres.

-L’existance d’un prestataire, qui maîtrise l’ensemble des phases de réalisation et exige alors moins de communication entre les différents intervenants.

-La possibilité de suivre un cahier des charges qui ne change pas du début à la fin, de par la nature du produit ou du projet.

-Un projet dont l’évolution de son environnement technologique est faible, réduisant ainsi les risques de décalage propres à l’effet tunnel.

b. Une phase cruciale : la conception

Les besoins du client doivent être reçus exhaustivement et rigoureusement. Les particularités fonctionnelles doivent être sujets d’un processus de confirmation suivi et final.

Elles doivent faire la synthèse des demandes du client tout en faisant la couverture du programme du projet.

La description des moyens pour atteindre le produit final ne doit intervenir qu’à l’étape des spécifications techniques (conception générale), de manière à éviter que les moyens ne déterminent la fin !

c. Qui valide ?

Last but not least, par défaut, le cycle en V définit des étapes sans en préciser les rôles ou les responsabilités.

Ainsi, il fallait bien au début du projet de préciser les personnes ou les entités qui vont jouer le rôle (par niveau de détail croissant) de :

-Maîtrise d’ouvrage (fonctionnel), ou MOA

-Maîtrise d’œuvre (système), ou MOE

-L’équipe d’architecture (de conception générale)

-L’équipe de développement

Les rôles sont mentionnés par séquence du cycle en V dans le schéma plus haut.

Laisser un commentaire