Une progression ordonnée qui reste séduisante et bénéfique sur les projets où il est possible de bien définir les exigences en amont.
The Benefits of Traditional, Waterfall Project Management
http://kellyprojectsolutions.com/benefits-traditional-waterfall-project-management par Technology Advice
L’approche « en cascade » d’analyse et de conception des systèmes a été créée dans les années 1970 et a gagné la popularité à cause de sa progression logique, linéaire. Les tâches sont décomposées en cinq parties qui suivent une progression ordonnée : définition des exigences, conception, mise en œuvre, vérification et maintenance. Dans la phase de définition des exigences, les programmeurs et le client déterminent le périmètre du projet; dans la phase de conception, les programmeurs créent des designs ou maquettes basiques et complexes; dans la phase de mise en œuvre, les programmeurs testent le code source comme le programme est écrit; dans la phase de vérification, les programmeurs évaluent la conception et corrigent les erreurs; et dans la phase de maintenance, les programmeurs apportent les changements nécessaires pour assurer que le système continue de fonctionner correctement. Chaque phase doit être soigneusement planifiée à l’avance pour assurer le succès.
Aujourd’hui, beaucoup de business optent au lieu de cela pour la gestion de projet Agile. Les personnes qui utilisent cette méthode se concentrent sur la production de petites parties du projet dans chaque cycle de livraison, plutôt que la création d’un plan pour le projet entier.
Cependant, l’approche en cascade traditionnelle du management de projet a toujours plusieurs bénéfices clefs.
D’abord, les développeurs et clients discutent ce qui sera livré tôt dans le processus, ce qui rend la planification et les phases de livraison plus évidentes.
Selon Techrepublic.com “l’accent sur les exigences et la conception avant l’écriture d’une seule ligne de code assure un gaspillage minimal de temps et d’effort et réduit le risque de dérapage de délais, ou d’attentes de client non atteintes.” Parce que les promoteurs et des clients discutent des objectifs finaux dans le détail, les deux parties ont une solide compréhension des attentes primaires et des résultats désirables. En conséquence, il est beaucoup plus facile de garantir que le projet est sur la bonne voie.
Ensuite, la méthode peut sauver du temps et de l’argent.
Les programmeurs développent seulement le code qui est en réalité nécessaire, ce qui sauve temps et effort pendant les étapes initiales. Les développeurs peuvent corriger n’importe quelles erreurs ou défauts tôt dans le processus, ce qui permet à la phase de mise en œuvre de se dérouler sans à-coup. Parce que l’objectif final est clairement défini dans les étapes de démarrage, toutes les parties comprennent les contraintes de temps et de finances du projet. Dans son livre paru en 1996 Rapid Development: Taming Wild Software Schedules Steve McConnell a évalué que “un défaut d’exigences qui reste non détecté jusqu’à la construction ou la maintenance coûte 50 à 200 fois autant pour le fixer qu’il n’aurait coûté au moment de la définition des exigences.” En conséquence, achever chaque cycle avant de passer au suivant garantie le succès au final.
Les travailleurs peuvent facilement déterminer combien de progrès ils font, car les attentes sont clairement définies avant que le projet ne commence.
Parce que le projet est clairement planifié du début à sa fin, les travailleurs peuvent rapidement mesurer leurs accomplissements et livrables. La méthode en cascade est idéale pour les équipes qui travaillent étroitement ensemble, puisqu’elle offre des tâches et des objectifs précis. Elle permet aussi aux développeurs de continuer à travailler sur le projet sans avoir besoin de la surveillance constante d’un manager.
Le logiciel peut être conçu en se basant sur une compréhension minutieuse des éléments à fournir.
Parce que la méthode traditionnelle entraîne une documentation minutieuse, les programmeurs peuvent garantir qu’ils répondent aux attentes des client avant que le projet ne soit achevé.
Enfin, les programmeurs peuvent facilement évaluer les résultats en fonction du résultat attendu.
Dans la phase de maintenance, les programmeurs et clients peuvent observer la solution pour déterminer si elle fonctionne correctement. S’il y a des problèmes, les programmeurs peuvent corriger les erreurs avant la remise du produit fini aux clients.
Bien que moins flexible que la gestion Agile, la méthode en cascade fournit un plan clair de résultats attendus tant pour les programmeurs que pour les clients. Elle peut faire gagner du temps et de l’argent en offrant une stratégie bien définie. Ce n’est pas la méthode la plus populaire actuellement, mais c’est un système valable et qui peut être mis en œuvre avec presque n’importe quel logiciel de management de projet. Les sociétés et leurs clients devraient considérer les bénéfices de la méthode de management de projet en cascade traditionnelle.
Qu’en pensez-vous? Quelles sont vos expériences en la matière? Commentez ce billet.
DantotsuPM.com 
Les méthodes Agile bénéficient aujourd’hui d’un effet de mode indéniable. Est-ce pour autant que les projets gérés avec ces méthodes réussissent mieux que ceux utilisant des méthodes classiques. Pas sûr du tout. On ne peut pas faire comme dans la pharma des études en double aveugle. Un projet est géré avec une méthode et un autre sans méthode.
Les méthodes Agile ont été développées sur deux hypothèses : les méthodes traditionnelles sont trop lourdes à déployer et elles demandent beaucoup d’administration. Ces deux postulats sont erronés. Je maîtrise parfaitement le PMBOK(r) et c’est très facile à mettre en oeuvre. Quant à l’administration, la philosophie du PMBOK est de créer des documents que l’on va reprendre et affiner au fur et à mesure que le projet va avancer. Le registre des risques est un bel exemple de cette philosophie.
Une réalité constatée sur le terrain est que dans l’IT mais aussi dans la R&D, les parties prenantes n’aiment pas écrire. Pour elles, cela correspond à une perte de temps. Elles sont aussi assez peu formées aux techniques de gestion de projet. Un projet est souvent géré avec un management de technologies et non avec une technologies de management. J’ai rencontré une partie prenante qui avait 14 ans d’expérience professionnelle dans des projets mais il n’avait jamais assisté à une formation en gestion de projet. On est bien dans ce paradoxe. Quelque part, ‘science sans conscience n’est que ruine de l’âme’.
Le point important relevé dans l’article tient à la définition des exigences. J’entends souvent dire pour des projets IT : le client ne sait pas ce qu’il veut. C’est très souvent vrai. Mais l’art de la gestion de projet réside justement dans le travail sur les exigences. Ce que les méthodes de gestion de projet n’expliquent pas du tout, c’est comment collecter les exigences ,définir les critères de validation et les méthodes de validation. Les méthodes Agile ne résolvent pas ce problème. On fait l’hypothèse qu’en travaillant sur de courtes périodes on va travailler rapidement sur les exigences, voir les résultats et montrer au client ce qui a été fait pour qu’il valide.
Travailler sur les exigences est crucial car ce sont elles qui définissent les objectifs que le projet doit atteindre. Cela permet aussi d’identifier comment le client veut que l’on communique avec lui et les risques associés aux exigences. Il faut donc passer du temps sur les exigences et discuter avec le client. Pour identifier les exigences avec le plus de précision possible, une stratégie de questionnement est indispensable. Comme coach, j’ai appris ce qu’est le questionnement socratique, la typologie des questions à poser à un client pour identifier sa demande. Je l’applique dans le monde du projet et je vais plus loin maintenant que ce que je faisais avant d’être coach.
Un point additionnel sur les méthodes Agile. Dans les projets d’ingénierie et de BTP, on fonctionne avec des plannings glissants quatre semaines (dit aussi ‘P4S’). L’ingénieur planning dispose d’un planning directeur qui court du début jusqu’à la fin du projet. Mais sur le chantier, on fonctionne à la semaine. Moralité, dans cette industrie, on est plus Agile que les méthodes Agile
J’aimeJ’aime
Merci pour ton retour d’expérience Thierry. Il mériterait un billet en lui-même ! Michel.
J’aimeJ’aime
Ping : Les articles les plus sur DantotsuPM.com au mois d’Octobre 2017 | DantotsuPM.com