L'histoire de la méthode en cascade
L'approche en cascade est un modèle logique à suivre : plan, construction, test et lancement l'un à la suite de l'autre. L’histoire de la méthodologie en cascade provient de l’article de Winston W. Royce de 1970 paru dans le compte-rendu de la conférence IEEE WESCON, Managing the Development of Large Software Systems. L’article de Winston W. Royce était probablement la première discussion portant sur la méthodologie en cascade dans le développement de logiciel, même si le mot « cascade » (waterfall) n’apparaît pas dans l’article. Le terme formel a été présenté dans l'article de Thomas E. Bell et T.A. Thayer de 1976, dans le compte-rendu de la 2e conférence internationale sur l’ingénierie logicielle, Software requirements: Are they really a problem? Comme cela a été remarqué en de nombreux endroits, cependant, l'article de Mr Royce ne faisait pas l'éloge de la méthode. En fait, il la décrivait en termes peu flatteurs, déclarant qu'elle contenait des défauts et invitait à l’échec de nombreuses manières. Il poursuivait en proposant une approche plus itérative, peut-être la base de ce qui deviendrait l'approche Agile.
L'article de MM. Bell et Thayer traitait d’un changement d’approche, passant d'une approche ascendante à une approche descendante dans le développement des exigences logicielles, en référence à l’adoption de cette même approche dans les normes MIL STD 490/483 (MIL STD 490 traite des pratiques de spécifications et MIL STD 483 traite des pratiques de gestion de la configuration pour les systèmes). L'article s’intéresse principalement à l’examen empirique des approches afin de déterminer celle qui fonctionne le mieux. En fin de compte, l'article déclare « qu'au cours des dix dernières années, plus de structure et de discipline ont été adoptées, et les praticiens ont conclu qu’une approche descendante est supérieure à l’approche ascendante passée. » Le terme « cascade » est utilisé comme référence directe à l'article de Winston Royce.
Malgré les défauts décrits par Mr Royce, la méthodologie en cascade est devenue la méthode préférée en 1985 lorsque le ministère de la Défense a publié la norme DOD-STD-2167A, Defense Systems Software Development. Celle-ci décrit le cycle de développement de logiciel comme suit :
- Analyse des exigences logicielles
- Conception préliminaire
- Conception détaillée
- Codage et tests unitaires
- Intégration et test des composants de logiciel informatique (CSC)
- Tests CSCI
L’avant-propos indique que « cette norme est destinée à être dynamique et réactive face à l’évolution rapide du domaine de la technologie logicielle. En tant que telle, cette norme doit être appliquée de façon sélective et adaptée aux caractéristiques uniques de chaque programme d’acquisition de logiciel. » Cependant, l’exigence était définie noir sur blanc et a été suivie religieusement.
La méthode en cascade a commencé à disparaître de l’utilisation populaire lorsque les leaders de l’industrie se sont sentis frustrés par son manque de flexibilité et qu'ils ont élaboré le Manifeste Agile. Depuis, de plus en plus d’entreprises ont adopté la méthodologie Agile, mais beaucoup s’accrochent toujours à la méthode en cascade, et ce, pour une bonne raison. La méthode en cascade a ses défauts, mais elle présente également des avantages et dans le bon environnement, elle peut être la meilleure pratique.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
Avantages de la gestion de projet en cascade
Malgré toutes les critiques de la méthodologie en cascade, il existe quelques avantages réels à sa mise en œuvre :
- Il s’agit d’une approche simple et directe.
- Développer un plan pour gérer un projet en cascade est facile, car chaque phase a un début et une fin, et vous savez avant de coder ce qui est à développer, pour quand cela est dû, quand est-ce que les tests commencent, etc.
- La planification précoce fournit une bonne base pour concevoir des éléments qui s’intègrent aux systèmes externes.
- Il est facile de prévoir les ressources pour un développement en cascade, parce que, encore une fois, vous savez quand tout commence et se termine.
- Les clients qui veulent des dates fermes de début et de fin peuvent trouver la méthode en cascade rassurante. Il est possible d'informer les clients de la date à laquelle ils auront le produit entre leurs mains et, si le projet est adapté à une approche en cascade, il sera livré à cette date.
- Le coût du développement peut être déterminé à l’avance.
- Des procédures détaillées peuvent être utilisées pour régir chaque partie du processus.
- L’approche lourde de la conception en cascade oblige à appliquer une approche disciplinée au développement et indique clairement les attentes.
- Les membres de l’équipe peuvent participer à d’autres projets avant que leur phase ne commence ou après qu'elle a fini, revenant au projet selon le besoin.
- La dépendance à la documentation de conception réduit le stress lié à la rotation des développeurs.
- L’approche lourde de la conception signifie que les erreurs peuvent être repérées lors de la phase de conception. Il existe des pièges évidents et toute personne ayant travaillé avec la méthode en cascade sait que des erreurs de conception surviennent, mais prenez une équipe expérimentée, créez un plan et vous obtiendrez souvent une conception solide qui peut être exécutée selon le plan.
Inconvénients de la gestion de projet en cascade
Voici quelques-unes des principales préoccupations et critiques concernant la méthode en cascade :
- Le temps de lancement est particulièrement long pour les grands projets. L'article de Mr Royce était favorable au système en cascade pour les petits projets internes, mais le considérait comme imparfait pour des projets plus importants et plus complexes. En fait, c’est probablement la raison principale pour laquelle la méthodologie Agile est devenue si populaire. Les projets trop importants étaient annulés avant d'être terminés avec la méthode en cascade.
- La deuxième critique principale de la méthode en cascade est que le changement n'est pas souhaitable. Une fois que les tests commencent, il est extrêmement coûteux de revenir au développement ou de reconcevoir le projet. La conception doit être faite soigneusement et correctement avant d'aller trop loin.
- Le logiciel ne devient fonctionnel que tard dans le projet.
- Les anomalies écrites tôt dans le projet peuvent créer de gros problèmes pour le code ultérieur, mais aucune d'elles ne sera détectable avant que les tests ne commencent, ce qui rend la correction du code coûteuse et chronophage.
- Ce n'est pas une approche orientée objet. Les projets en cascade sont très intégrés. Il s’agit d’un autre aspect de la méthodologie en cascade qui réduit la flexibilité.
- Il ne s'agit pas d'une bonne méthode pour la maintenance et d’autres types de projets à long terme.
- Le fait que les clients ne savent souvent pas ce qu’ils veulent avant le début du projet va de pair avec les critiques précédentes.
- Si l’équipe est inexpérimentée ou avance en terrain inconnu, des obstacles apparaissent et mettent en péril le projet.
- Les tests peuvent être minimisés afin de rester dans les délais, ce qui laisse des anomalies à découvrir par le client une fois le produit livré.
- Les événements peuvent pousser à abandonner l’ensemble du projet. Par exemple, des changements survenant dans le secteur industriel pendant la phase de développement pourraient rendre l’ensemble du projet obsolète. Un autre événement peut être la découverte d’un défaut de conception si grave que l’ensemble du projet doit être reconçu, ce qui peut être si coûteux que le client refuse le projet.
Comparer les approches en cascade et Agile
La méthodologie en cascade se concentre sur la phase de conception d’un projet, tandis que la méthodologie Agile lui consacre un minimum de temps. Les deux options de gestion de projet visent à fournir des logiciels fonctionnels, mais les projets en cascade livrent généralement une ou deux versions par an (ou même moins), tandis que les projets Agile peuvent livrer des logiciels fonctionnels aussi souvent qu’une fois par semaine. Les livraisons des projets en cascade peuvent être conséquentes et nécessiter une longue période de test, de nombreuses entreprises faisant également appel aux clients pour réaliser des tests Bêta. Dans le cadre Agile, le logiciel est testé au fur et à mesure de sa construction, le développeur effectuant souvent lui-même les tests.
Une différence importante entre les cadres en cascade et Agile réside dans le fait que le cadre en cascade est une méthodologie, tandis que le cadre Agile est un « mouvement » avec diverses méthodes dérivées qui appliquent les principes et les valeurs Agile. Les méthodes Scrum, eXtreme Programming (XP), Kanban, Scrumbanet un certain nombre d’autres offrent à l’équipe de développement des options, de sorte qu’il peut y avoir un meilleur choix parmi elles.
Une méthodologie Agile est un meilleur choix lorsque le client n'est pas certain des exigences ou qu'il veut être étroitement impliqué dans le processus de développement, et si les délais sont courts et qu’il veut une livraison rapide. La méthodologie en cascade est meilleure s’il existe des interdépendances complexes, mais l'Agile est préférable lorsque les interdépendances sont minimales. La méthode Agile convient également mieux si la vitesse importe plus que la qualité.
Certains inconvénients de la méthode Agile sont :
- Nécessite l’implication du client
- Les coûts et les échéances sont incertains
- La planification est difficile
- Manque de clarté quant au résultat final
- Documentation minimale
- Les membres de l’équipe doivent être plurifonctionnels ; certains qui sont inexpérimentés tenant des rôles inconnus
- Les développeurs sont dédiés à un seul projet
- La dérive de la portée est un risque, car un projet qui accepte le changement peut se développer de manière incontrôlable et dépasser sa date d’échéance
L’idée que la méthode Agile s'écarte radicalement de la méthode en cascade n’est pas entièrement juste. En fait, l’approche Agile est plutôt un ajustement de l'approche en cascade, une tentative de remédier à certains des inconvénients de cette dernière en termes de résistance au changement et de longues durées de livraison. Le manque de flexibilité et le taux élevé de projets annulés ont poussé de nombreuses équipes à passer de l'approche en cascade à l'approche Agile. Cependant, il est important de comprendre que l’approche Agile est toujours séquentielle, c'est juste qu'elle utilise une séquence plus courte. L'approche Agile comprend toujours une analyse des exigences et une conception au début, mais le codage ne commence pas avant que les exigences et la conception soient définies, et vous ne pouvez pas tester un code qui n’a pas été écrit ni livrer un code qui n’a pas été testé et intégré. Par conséquent, la méthodologie Agile peut être considérée comme une forme plus flexible et rapide de la gestion de projet en cascade.
Conseils et bonnes pratiques pour votre prochain projet à l’aide de la méthodologie Agile.
Découvrez tout ce qu’il y a à savoir sur la gestion de projet Agile, ainsi que des conseils pour vous aider à commencer à appliquer les bonnes pratiques Agile.
Obtenir le livre électronique gratuit pour appliquer mes bonnes pratiques Agile
Quand utiliser la méthode en cascade pour la gestion de projet
Choisir entre les approches en cascade et Agile se résume à examiner les caractéristiques du projet et les besoins du client. En particulier, prêtez une attention toute particulière aux exigences, au but et à l’objectif du projet. L'approche en cascade est souvent un meilleur choix lorsque :
- Les exigences sont bien comprises et ne devraient pas changer.
- Le client n’est pas enclin à exiger des modifications.
- Le client préfère ne pas être impliqué dans le développement, mais veut être consulté au début et recevoir un ensemble fonctionnel à la fin du projet. L'approche Agile convient mieux lorsque le client est impliqué dans toutes les phases (il passe en revue le produit à chaque itération), alors que les clients d'un projet en cascade n’ont besoin que de recevoir une version et de l’installer. (Note : C’est une simplification. Les clients doivent également être formés à l’utilisation du système et cela peut être une étape longue et importante. C’est la même chose quelle que soit la méthode utilisée et il est possible que former les utilisateurs une ou deux fois par an sur les nouvelles fonctionnalités pour une version plus large soit moins gênant que de former un client chaque mois ou même chaque semaine sur un ensemble plus petit de fonctionnalités. Gardez également à l’esprit que les clients qui souhaitent être impliqués peuvent eux-mêmes faire partie d'un projet en cascade. Recevoir le client pour des revues fréquentes peut être distrayant et conduire à des demandes de modifications indésirables, mais cela peut également garder le projet orienté sur la satisfaction des besoins du client.)
- Le projet est petit.
- La vitesse de livraison n’est pas importante.
- La livraison sera appliquée à un système ancien qui n’est pas sujet au changement.
- Vous aurez des projets similaires à l’avenir, ce qui permettra de réutiliser le plan de projet et de tirer des leçons de la documentation lourde du projet précédent.
Un bref aperçu des meilleures méthodologies de gestion de projet
La méthode en cascade est l’une des nombreuses méthodologies concurrentes. Lorsque vous décidez de mettre en œuvre l'une ou l’autre, il est utile de savoir de quoi il s'agit. La suite est un bref aperçu des meilleures méthodologies de gestion de projet actuellement utilisées.
La méthodologie en cascade
La méthodologie en cascade est généralement considérée comme une approche traditionnelle de la gestion de projet. Elle était basée sur l'idée que tout se produit dans l’ordre, une phase du projet se terminant avant qu'une autre ne commence. Cela a créé de nombreuses interdépendances et également entraîné des situations assez désastreuses pour le développement de logiciels. Les projets étaient souvent en retard par rapport au calendrier et au-dessus du budget, et, dans certains cas, complètement annulés lorsque la technologie changeait trop rapidement.
Méthode du chemin critique (CPM)
La méthode CPM est une autre méthode séquentielle qui suppose que chaque étape dépend de l’achèvement de l’étape précédente. La phase de planification d’un projet CPM consiste davantage à identifier les parties du projet nécessitant le plus de ressources afin d’allouer des ressources et éviter les goulets d’étranglement. Pour appliquer la méthode, il faut :
- Identifier les tâches requises et définir la séquence pour les réaliser.
- Définir les interdépendances pour les tâches requises.
- Déterminer les relations entre les tâches qui sont et ne sont pas essentielles.
- Planifier le calendrier attendu pour chaque tâche.
- Développer un plan B pour les chemins critiques.
La gestion de projet par la chaîne critique (CCPM)
L'approche en cascade se concentre sur la conception et la CPM se concentre sur les tâches, mais la CCPM, elle, se concentre sur les ressources et leur allocation. La CCPM se concentre sur les facteurs qui peuvent affecter les échéances, les coûts, les performances et le risque de ne pas pouvoir livrer tout ce qui est attendu. L’approche de la CCPM est de définir le chemin critique, d’appliquer les ressources les plus bénéfiques, et enfin d'intégrer des marges de temps aux tâches critiques afin d’assurer une livraison en temps opportun si des problèmes surviennent.
Le Guide PMBOK® du PMI
La méthode de gestion de projet du PMI, PMBOK®, applique les cinq groupes de processus du PMI issus du texte, A Guide to Project Management Body of Knowledge (Guide du Corpus des Connaissances en Management de Projet). Voici une vue d’ensemble de haut niveau de ces groupes :
- Démarrage : définir la vision. Il s’agit également du groupe de processus dans lequel le chef de projet est sélectionné.
- Planification : définir la portée. Le PMBOK décrit 24 processus au stade de la planification.
- Exécution : mettre le plan en action.
- Pilotage et contrôle : cela se produit pendant l’ensemble du projet et ce n’est pas une phase séquentielle qui attend qu'une autre phase se termine.
- Clôture : effectuée lorsque le client est d’accord pour accepter le projet.
Les méthodologies Agile
L'approche Agile est définie comme un mouvement, et non une méthodologie, mais une famille de méthodologies Agile ont été développées en accord avec les valeurs et principes Agile.
Scrum
La méthode Scrum dispose d’une petite équipe Agile dirigée par un Scrum master. Le rôle du Scrum master est de faciliter le travail de l’équipe. La planification est minimale et une liste des tâches à réaliser est créée. Les tâches sont accomplies lors de « sprints » qui durent généralement entre deux et quatre semaines. De brèves réunions quotidiennes (appelées Scrums quotidiens) ont lieu pour passer en revue les tâches de la journée et identifier les obstacles. Les membres de l’équipe effectuent toutes les tâches traditionnelles d’un projet, concevant au fur et à mesure et effectuant des tests quand une tâche est terminée. L’objectif de la méthode Scrum est de transmettre des logiciels fonctionnels. Lorsqu’un sprint se termine, le suivant commence, avec l’équipe puisant un ensemble de tâches dans le backlog du projet. Lorsque les objectifs globaux du projet ont été atteints et qu’il ne reste plus de tâches, le projet est terminé.
Kanban
La méthode Kanban est la plus adaptée aux projets de maintenance. Le cœur de la méthode Kanban est le tableau Kanban, une liste de toutes les tâches (aussi appelées cartes Kanban) à effectuer qui est continuellement mise à jour et facilement visible par tous les membres de l’équipe. Lorsqu’une ressource (membre de l’équipe) devient disponible, le membre de l’équipe prend une tâche dans le tableau et travaille dessus. Les tâches sont ajoutées au tableau et font l'objet d'un travail en continu. Il n’y a pas de début ou de fin définis pour le projet.
Extreme Programming (XP)
Les sprints durent généralement une semaine avec de nombreuses itérations. En XP, le changement est la clé, et les programmeurs XP travaillent en étroite collaboration avec les parties prenantes. La méthode XP est idéale pour les environnements où les exigences changent constamment. Les tâches peuvent être remplacées en milieu de sprint.
Adaptive Project Framework (APF)
L'APF (gestion adaptative de projet) suppose que les projets informatiques varient si largement qu'aucune approche ne convient. Les projets informatiques diffèrent en termes de risques, de coûts, de durée et de complexité et impliquent souvent une part d'incertitude concernant le marché, la valeur commerciale, l’implication des clients et les objectifs. Un projet APF commence par une analyse des exigences pour définir des objectifs stratégiques. Le projet est exécuté de façon itérative et des réunions post-mortem sont effectuées après les itérations pour améliorer le processus. L’analyse est généralement continue, afin que l’ensemble du projet puisse être redéfini ou adapté à mesure qu’il se déroule en réponse aux problèmes d’incertitude, pour maintenir ou augmenter la valeur commerciale.
Lean
Le Lean est destiné à réduire les gaspillages et à optimiser la valeur. Les valeurs fondamentales du Lean sont une amélioration progressive continue et le respect des personnes. Le Lean se concentre sur la livraison de la plus grande valeur possible au client, le maintien du flux, l’attribution du travail de manière uniforme et, surtout, sur l’élimination des gaspillages.
Six Sigma
Le Six Sigma consiste à éliminer les défauts du développement grâce à des processus efficaces et à l’amélioration continue de ceux-ci. Une note de Six Sigma signifie que le produit est à 99,99966 % sans défauts. Lorsque vous avez un processus doté d’une note Six Sigma, cela signifie que chaque produit livré via ces produits est censé produire le même résultat.
Lean Six Sigma
Le Lean Six Sigma tente de combiner les approches Lean et Six Sigma, en éliminant les gaspillages afin de rendre les processus plus efficaces et livrer beaucoup de valeur et peu de défauts au client.
Gestion de projet basée sur les processus
Dans la gestion de projet basée sur les processus, l’accent est mis sur l’alignement de chaque projet sur la mission et les valeurs de l’entreprise. Les projets font partie intégrante de la stratégie d’entreprise. Par conséquent, des aspects traditionnels de l’analyse de projet, tels que les métriques, sont utilisés pour déterminer à quel point l'objectif est atteint.
PRINCE2
La méthode PRINCE2 est basée sur la méthode PRINCE, moins réussie. La méthode PRINCE n’a pas été largement adoptée, car elle était trop lourde ; elle a été révisée en 1996 par un comité comprenant 150 organisations européennes pour devenir PRINCE2. Bien que la méthode PRINCE ait été destinée à réduire les dépassements de coûts et de temps informatiques, elle a également été développée comme une méthodologie de gestion de projet pour tout type de projet. Une révision importante de la méthode PRINCE2 en 2009 a permis de simplifier celle-ci et a introduit sept principes de base pour la réussite d'un projet.
Projets intégrant des méthodes durables (PRiSM)
La méthode PRiSM se concentre sur la gestion de projet socialement responsable. Son intention est de gérer des projets tout en réduisant les impacts négatifs sur l’environnement et en favorisant des projets socialement bénéfiques.
Benefits Realization
La méthode Benefits Realization se concentre sur le client. Du début à la fin, la méthode vise à s’assurer que le client tire le maximum de bénéfices du livrable, bien au-delà du coût et du calendrier.
De nombreuses méthodes de gestion de projet impliquent de nombreuses opportunités
Il existe de nombreuses méthodes dans le monde de la gestion de projet. La plupart se sont développées autour des nouvelles approches et des différents besoins qui sont apparus lorsque le secteur des logiciels est devenu à la fois plus complexe (variété de méthodes et de langages) et aussi plus simple (plus de facilité à écrire du code). Toutefois, les anciennes méthodes de gestion de projet conservent toujours leur valeur dans les environnements adaptés, car le prouvent les entreprises qui développent toujours des projets avec la méthode en cascade. De nombreux clients veulent encore connaître le coût et la date de livraison avant de donner leur accord pour le développement, et veulent aussi encore savoir de quoi il sera constitué. Sans ces informations essentielles, comment pourraient-ils savoir si le livrable a une valeur commerciale ?
Pourquoi Smartsheet est un outil puissant pour la gestion de projet en cascade
De la simple gestion de tâches et de projets à la gestion complexe de ressources et de portefeuilles, Smartsheet vous aide à améliorer la collaboration et à accélérer le travail. Vous avez ainsi les moyens d'accomplir plus de travail. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports de synthèse sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.