Afin d’organiser le bon déroulement d’un projet, le management est une donnée clé.
Différentes méthodes sont envisageables pour en assurer le bon avancement et inscrire le projet
dans le fameux triangle Qualité-Coût-Délais. Aujourd’hui, deux façons de développer se distinguent,
la méthode classique du cycle en "V" et celle dite "Agile".
Pour autant, ces pratiques sont-elles à opposer ?
Créée pour l’industrie puis appliquée à l’informatique dans les
années 80, la méthode de gestion de projet traditionnelle, dite
en "V", appelée aussi Waterfall s’est longtemps imposée dans
les logiques de développement. La méthode classique pose le
principe d’un découpage du projet en six ou neuf étapes
successives qui seront validées avant de passer à la suivante.
D’où le "V" éponyme de l’appellation. Par ailleurs, la forme de la
lettre rappelle aussi le schéma quand on décrit le process.
Les différentes phases sont séquencées de la façon suivante :
analyse des besoins, rédaction et validation des spécifications
fonctionnelles, étapes de conception architecturale puis
fonctionnelle, réalisation, tests unitaires, tests d’intégration, test
de validation puis recette fonctionnelle. Quant à Waterfall, par
analogie à cette suite de tâches exécutées en séquentiel, il faut
imaginer une cascade d’eau qui dévale la pente et qui d’ailleurs
ne peut plus la remonter.
Dès qu’une étape est terminée, le développement passe à la
suivante, sans retour en arrière possible. L’un des avantages
de la méthode est de faciliter le contrôle de gestion.
Elle permet d’établir un calendrier et d’envisager des étapes
pour accompagner le processus de développement. Bien
entendu, les étapes se suivent dans un ordre strict, sans aucun
chevauchement ni étapes itératives. Aussi, le développement
en cycle V ne permet pas la révision ou même la réflexion.
Dès lors, il est très difficile de revenir en arrière pour modifier un
élément mal conçu antérieurement. Par ailleurs, chaque phase
étant consacrée à des tâches spécifiques, elle dépend des
résultats de la phase précédente.
Les avantages de la gestion en V résident dans sa facilité de
mise en œuvre et expliquent son adoption par l’industrie puis
dans la conception et le développement de logiciels
informatiques. Cette planification systématique permet un
développement sans implication du client jusqu’à la livraison
du projet. Ses attentes ayant été intégrées dès le démarrage
du projet. Avec une prévision globale en amont, la méthode
Waterfall donne aussi une parfaite visibilité en termes de
budget, de réalisation à chaque étape et donc de livraison.
Mais le manque de flexibilité peut aussi être gênant. En effet, ce
cadre très structuré de progression ne permet pas l’intégration
d’imprévus tels que les évolutions de technologies, l’émergence
de nouveaux concurrents, la création de nouveaux marchés,
l’évolution des normes de production et de distribution, etc.
Bien entendu, prendre en compte ces éventuelles survenues
implique une remise en question du travail des équipes, risque
de générer retards et coûts additifs. Enfin, le résultat devra être
parfait pour satisfaire le client puisque dans ce modèle, il ne le
découvrira qu’à la livraison. Alors, attention au risque de
décalages entre les attentes initiales et le produit final !
En alternative, il existe d’autres solutions de substitution.
Pour n’en citer que quelques- unes : Agile Scrum, la méthode
adaptative, celle du chemin critique, la méthode PERT,
PRINCE2, Kanban.
Pour la flexibilité qu’elle permet au sein de la conception du
produit, la méthode agile est celle qui a la faveur des startups
notamment. A l’origine des pratiques "agiles", on note une
observation de contre-productivité. On s’est aperçu qu’il était
inutile de planifier en détail un projet et qu’il était essentiel
d’améliorer la communication entre les différents acteurs du
projet. Dans une procédure agile, la demande du client est au
cœur de l’action. Les équipes sont dès lors plus réactives dans
un cadre de développement où les modifications sont plus
simples à apporter en cours de route pour améliorer le produit.
Le projet est souvent découpé en plusieurs mini-projets,
chacun nécessitant la validation du client pour passer au
suivant. Les pratiques agiles reposent sur l’adaptabilité, le
dialogue et la coopération avec le client. La méthode agile
s’appuie aussi davantage sur les interactions entre les membres
de l’équipe plutôt que sur la documentation. Le facteur temps
est également à prendre en compte. Ici, les objectifs se posent
davantage à court terme. Les délais sont plus courts et la suite
du projet sera planifiée en fonction de la réalisation précédente.
A l’issue de chaque étape, la livraison est testée. Si le résultat est
concluant, on passe à la fonctionnalité suivante, dans le cas
contraire, on corrige.
Avec cette approche plus souple, il est bien plus facile de
s’adapter aux changements et aux imprévus. Aujourd’hui,
la méthode agile la plus utilisée est la méthode Scrum.
Les différences entre cycle en V et gestion Agile
- Cycle de vie du projet : séquentiel en V vs itératif en mode
agile.
- Livraison : un produit final, toutes fonctionnalités réalisées
en cycle en V correspondant au produit imaginé. En gestion
agile, les besoins sont priorisés sans attendre le
développement complet de la fonctionnalité. Les contrôles
qualités sont plus fréquents et évitent l’effet tunnel du cycle
en V.
- Demande client : En cycle en V, revenir sur des
spécifications validées est complexe et générateur de coûts
car considéré comme une évolution du besoin initial.
En gestion agile, il est possible d’ajouter des fonctionnalités
d’une itération à l’autre de manière souple.
- Planification : Détaillée en cycle en V, elle ouvre sur une
bonne visibilité du développement, donc du budget.
En amont la préparation permet de limiter les adaptations
en cours de route. À l’inverse, le mode agile permet la prise
en compte des nouvelles demandes du client.
- Documentation : elle est la base essentielle d’un projet en
cycle V quand elle est réduite au minimum dans le cadre
d’un projet agile.
Les deux méthodes répondent à des exigences de contextes
bien différents. Les projets les plus simples, définis avec
précision et pouvant faire l’objet d’une planification détaillée en
amont de la réalisation pourront être gérés en cycle en V.
Cette méthode convient parfaitement pour cadrer un projet
aux contours bien délimités.
Dans le cas d’un projet plus complexe, il sera plus cohérent
de le conduire sous un mode agile. Dans un environnement
instable, complexe et évolutif, il est toujours plus approprié de
garder au projet une marge d’évolutivité. En effet, si les objectifs
de l’entreprise peuvent varier, les contraintes extérieures sont
mouvantes également : données environnementales,
concurrence, réglementation, nouveaux outils disponibles, état
du marché, sans oublier les pandémies… Les pratiques agiles
restent alors un excellent atout pour gérer le risque quand la
visibilité se réduit. En conclusion, plutôt que de les opposer, on
peut envisager de combiner les deux approches pour gagner
sur tous les tableaux.
Sources : techtarget.fr, nutcache.com, planzone.fr, bpce.com, blog.lesjeudis.com, wimi-teamwork.com
Partager cet article :
Plus court, plus vite
Afin d’organiser le bon déroulement d’un projet, le management est une donnée clé. Différentes méthodes sont envisageables pour en assurer le bon avancement et inscrire le projet dans le fameux triangle Qualité-Coût-Délais. Aujourd’hui, deux façons de développer se distinguent, la méthode classique du cycle en "V" et celle dite "Agile". Pour autant, ces pratiques sont-elles à opposer ?
Créée pour l’industrie puis appliquée à l’informatique dans les années 80, la méthode de gestion de projet traditionnelle, dite en "V", appelée aussi Waterfall s’est longtemps imposée dans les logiques de développement. La méthode classique pose le principe d’un découpage du projet en six ou neuf étapes successives qui seront validées avant de passer à la suivante. D’où le "V" éponyme de l’appellation. Par ailleurs, la forme de la lettre rappelle aussi le schéma quand on décrit le process. Les différentes phases sont séquencées de la façon suivante : analyse des besoins, rédaction et validation des spécifications fonctionnelles, étapes de conception architecturale puis fonctionnelle, réalisation, tests unitaires, tests d’intégration, test de validation puis recette fonctionnelle. Quant à Waterfall, par analogie à cette suite de tâches exécutées en séquentiel, il faut imaginer une cascade d’eau qui dévale la pente et qui d’ailleurs ne peut plus la remonter.
A tel point d’ailleurs qu’il ne le quittera qu’à l’âge de trente-trois ans. Son père lui explique
que pour être tranquille dans la vie, il faut être sérieux. Il l’est. Mais à l’orée de la seconde,
la motivation décline. Un conseiller le remotive en lui parlant d’un BEP de comptabilité.
Obtenu brillamment, il rattrape sa route vers un bac G2 où la compta est reine.
Les résultats sont bons. On conseille à Michel de s’orienter vers de longues études.
Mais lui préfère un parcours plus court pour entrer plus vite dans la vie active.
Sa décision est prise, ce sera un BTS. Il enchaîne ensuite sur une maîtrise de gestion.
Comptable en uniforme
Dès qu’une étape est terminée, le développement passe à la suivante, sans retour en arrière possible. L’un des avantages de la méthode est de faciliter le contrôle de gestion. Elle permet d’établir un calendrier et d’envisager des étapes pour accompagner le processus de développement. Bien entendu, les étapes se suivent dans un ordre strict, sans aucun chevauchement ni étapes itératives. Aussi, le développement en cycle V ne permet pas la révision ou même la réflexion. Dès lors, il est très difficile de revenir en arrière pour modifier un élément mal conçu antérieurement. Par ailleurs, chaque phase étant consacrée à des tâches spécifiques, elle dépend des résultats de la phase précédente.
Les avantages de la gestion en V résident dans sa facilité de mise en œuvre et expliquent son adoption par l’industrie puis dans la conception et le développement de logiciels informatiques. Cette planification systématique permet un développement sans implication du client jusqu’à la livraison du projet. Ses attentes ayant été intégrées dès le démarrage du projet. Avec une prévision globale en amont, la méthode Waterfall donne aussi une parfaite visibilité en termes de budget, de réalisation à chaque étape et donc de livraison.
Et puis il a aussi des contraintes, notamment celles du service militaire "Pendant dix mois, à Montauban puis Vincennes" reprend Michel. Là, il endosse l’uniforme du comptable pour
s’occuper de la solde du contingent. "J’étais chanceux avec ce poste tranquille après des classes plus rugueuses", précise-t-il. Juste après l’armée, la chance l’attend encore dans une agence d’intérim. On lui propose de remplacer au poste de comptable une collaboratrice qui s’est cassée la jambe. "En fait, le PMU me met le pied à l’étrier", s’amuse Michel. Il y restera trois ans. Puis d’autres horizons s’ouvrent à lui. Notamment publicitaires chez Publicis Conseil.
Des sociétés de services l’accueillent. Jusqu’à Kaba. Ce spécialiste des portes coulissantes lui ouvre les siennes. "Souhaitant renouveler leur système d’information, ils avaient besoin de mon expérience pour être accompagnés dans ce changement". Les solutions du marché ne plaisent pas à Michel. C’est alors que des consultants de Navision viennent le voir. Leur offre plait au Directeur comptable de Michel et l’implémentation est mise place avec succès. Michel ayant découvert le métier de consultant est tenté par l’activité. Intéressé par la compétence comptable de Michel, Navision lui propose de le former au consulting.
Puis Michel entre chez Colombus, intégrateur AX. Les projets s’enchaînent, spécialement
chez Saint-Gobain Glass. Ensuite, il entre chez Avanade et quelques années plus tard
il intègre l’ESN Viseo.
Premiers contacts
Deux ans après, Flexmind le contacte avec un argument décisif : "Ici tu n’auras pas une kyrielle de projets mais un seul, important et captivant". C’est ainsi que Michel démarre en 2012 sur le projet Geodis et fait la connaissance de nombre de ses collègues d’aujourd’hui. En 2017, il quitte le salariat pour le statut d’indépendant et opère pour le groupe Saur. "Pendant ce temps, Geodis s’était séparé de Flexmind pour rejoindre FiveForty°. Jonathan m’appelle pour me proposer de reprendre en sous-traitant sur Geodis en conservant mon nouveau statut", résume le consultant finance Dynamics.
"De toute façon, quand Jonathan a voulu monter sa structure, je n’ai pas hésité une seule seconde". Celui que la chance n’a jamais lâché précise : "Ici, on ne sent pas le poids de la structure, l’aspect famille est palpable. Ce lien social ajouté à la diversité des clients, c’est ce qui donne envie de bosser avec eux".°
Risques de décalages
Mais le manque de flexibilité peut aussi être gênant. En effet, ce cadre très structuré de progression ne permet pas l’intégration d’imprévus tels que les évolutions de technologies, l’émergence de nouveaux concurrents, la création de nouveaux marchés, l’évolution des normes de production et de distribution, etc. Bien entendu, prendre en compte ces éventuelles survenues implique une remise en question du travail des équipes, risque de générer retards et coûts additifs. Enfin, le résultat devra être parfait pour satisfaire le client puisque dans ce modèle, il ne le découvrira qu’à la livraison. Alors, attention au risque de décalages entre les attentes initiales et le produit final !
En alternative, il existe d’autres solutions de substitution. Pour n’en citer que quelques- unes : Agile Scrum, la méthode adaptative, celle du chemin critique, la méthode PERT, PRINCE2, Kanban.
Pour la flexibilité qu’elle permet au sein de la conception du produit, la méthode agile
est celle qui a la faveur des startups notamment. A l’origine des pratiques "agiles", on note une observation de contre-productivité. On s’est aperçu qu’il était inutile de planifier en détail un projet et qu’il était essentiel d’améliorer la communication entre les différents acteurs du projet. Dans une procédure agile, la demande du client est au cœur de l’action. Les équipes sont dès lors plus réactives dans un cadre de développement où les modifications sont plus simples à apporter en cours de route pour améliorer le produit. Le projet est souvent découpé en plusieurs mini-projets, chacun nécessitant la validation du client pour passer au suivant. Les pratiques agiles reposent sur l’adaptabilité, le dialogue et la coopération avec le client. La méthode agile s’appuie aussi davantage sur les interactions entre les membres de l’équipe plutôt que sur la documentation. Le facteur temps est également à prendre en compte. Ici, les objectifs se posent davantage à court terme. Les délais sont plus courts et la suite du projet sera planifiée en fonction de la réalisation précédente. A l’issue de chaque étape, la livraison est testée. Si le résultat est concluant, on passe à la fonctionnalité suivante, dans le cas contraire, on corrige.
Avec cette approche plus souple, il est bien plus facile de s’adapter aux changements et aux imprévus. Aujourd’hui, la méthode agile la plus utilisée est la méthode Scrum.
Les différences entre cycle en V et gestion Agile
- Cycle de vie du projet : séquentiel en V vs itératif en mode agile.
- Livraison : un produit final, toutes fonctionnalités réalisées en cycle en V correspondant au produit imaginé. En gestion agile, les besoins sont priorisés sans attendre le développement complet de la fonctionnalité. Les contrôles qualités sont plus fréquents et évitent l’effet tunnel du cycle en V.
- Demande client : En cycle en V, revenir sur des spécifications validées est complexe et générateur de coûts car considéré comme une évolution du besoin initial. En gestion agile, il est possible d’ajouter des fonctionnalités d’une itération à l’autre de manière souple.
- Planification : Détaillée en cycle en V, elle ouvre sur une bonne visibilité du développement, donc du budget. En amont la préparation permet de limiter les adaptations en cours de route. À l’inverse, le mode agile permet la prise en compte des nouvelles demandes du client.
- Documentation : elle est la base essentielle d’un projet en cycle V quand elle est réduite au minimum dans le cadre d’un projet agile.
Les deux méthodes répondent à des exigences de contextes bien différents. Les projets les plus simples, définis avec précision et pouvant faire l’objet d’une planification détaillée en amont de la réalisation pourront être gérés en cycle en V. Cette méthode convient parfaitement pour cadrer un projet aux contours bien délimités.
Dans le cas d’un projet plus complexe, il sera plus cohérent de le conduire sous un mode agile. Dans un environnement instable, complexe et évolutif, il est toujours plus approprié de garder au projet une marge d’évolutivité. En effet, si les objectifs de l’entreprise peuvent varier, les contraintes extérieures sont mouvantes également : données environnementales, concurrence, réglementation, nouveaux outils disponibles, état du marché, sans oublier les pandémies… Les pratiques agiles restent alors un excellent atout pour gérer le risque quand la visibilité se réduit. En conclusion, plutôt que de les opposer, on peut envisager de combiner les deux approches pour gagner sur tous les tableaux.
Sources : techtarget.fr, nutcache.com, planzone.fr, bpce.com, blog.lesjeudis.com, wimi-teamwork.com
Partager cet article :
Paris - FRANCE / New York - USA
©2021 FiveForty°. Tous Droits Réservés.
Conception et réalisation :
