Avant de répondre directement à la question posée dans le titre, il est toujours bon de préciser quel est l’objectif ultime du projet que vous souhaitez atteindre.
À quoi ressemblera le produit dans un mois, six mois et un an. Mais décrivez-le maintenant. Cela vous donnera une certaine perspective et définira les attentes de base concernant votre niveau de prévisibilité, de flexibilité, d’agilité, de rapidité de mise sur le marché et de fixation des coûts dans le temps.
Oui, aujourd’hui, mettre en place des projets en cascade semble être une idée ridicule. Surtout s’il a déjà été prouvé à maintes reprises que si l’on veut réagir rapidement aux évolutions des marchés, il n’y a pas d’autre choix que de faire preuve d’agilité. Mais si votre objectif est de livrer un produit dans un an avec des fonctionnalités déjà assez claires et restreintes dès le début, et que vous avez des équipes de personnes sans expérience préalable en méthodologie agile, alors bien sûr, restez conservateur et allez en cascade.
Tous les cas ne sont pas aussi simples à conclure. Voyons comment mieux évaluer quelle méthodologie est la meilleure pour votre projet.
Table des matières
À quoi ressemble une cascade ?
Au lieu d’entrer dans certaines définitions que tout le monde connaît déjà depuis une vingtaine d’années maintenant, le résultat pratique d’un projet en cascade ressemble généralement à ceci :
L’ensemble de ce processus peut prendre de quelques mois à quelques années. Comme vous pouvez le prédire, les utilisateurs ne verront les résultats qu’à la fin de ce processus. Ainsi, après une longue attente vient le moment de vérité (ou d’échec).
Si quelque chose change pendant cette longue période et que le produit final devrait être un peu différent, c’est une situation que vous appelez une demande de changement. La conception doit être rouverte, retravaillée et réapprouvée. Cela prolonge l’ensemble du programme horaire d’une autre partie. Chaque changement nécessite un redémarrage de tout le processus auparavant.
De l’autre côté, vous disposez d’une définition de phase solide, d’un budget fixe pour chaque phase et d’une durée fixe. Même si vous devez attendre longtemps pour obtenir le premier résultat, si les chances de changements en cours de route sont minimes, cela peut toujours être une option préférable.
À quoi ressemble un Agile ?
Maintenant, voici comment le projet peut fonctionner dans une configuration Agile :
Ceci n’est qu’un bref résumé, mais la différence avec la cascade est déjà claire. Retour rapide, adaptation, reflet des besoins actuels évoluant dans le temps, premier produit de valeur livré dans les plus brefs délais. Ce sont toutes des propriétés que vous n’avez aucune chance d’obtenir dans un projet en cascade.
Agile contre cascade
Un projet ne peut réussir sans la mise en place d’une méthodologie de gestion de projet adaptée. Cela signifie définir des processus, des mesures, des évaluations et des méthodes générales de travail pour les équipes formant le projet.
Les équipes doivent savoir quelles règles suivre, ce qui définira les jalons, quand les atteindre et comment mesurer et évaluer le succès. Dans le même temps, les parties prenantes doivent comprendre à quoi s’attendre du projet et quand elles pourront voir les premiers résultats du travail.
Avec un peu de généralisation, nous pouvons dire que les projets fonctionnant dans des environnements cloud sont nettement plus susceptibles de s’orienter vers des méthodologies agiles (ou du moins ils devraient le faire). Les projets travaillant avec des infrastructures sur site privilégient encore très souvent les processus en cascade. Cela vient comme une conclusion naturelle.
L’environnement cloud est construit dès le départ pour s’adapter à un environnement en constante évolution. Il s’adapte le plus rapidement possible (avec divers services « élastiques ») à la nouvelle réalité. L’environnement sur site est souvent prédéfini au départ. Il est difficile de le modifier dans le temps, les équipes travaillent donc avec des variables déterministes pendant toute la durée du projet.
Résumé de l’approche Agile vs Waterfall.
Approche FeatureWaterfallApproche AgileGestion des exigences des utilisateursLe changement est traité comme un processus formel (demande de changement). Le travail devra peut-être être refait, ce qui aura un impact sur les coûts et les délais. Accepte les changements dans le cadre du processus standard, sans impact significatif sur les coûts ou les délais. Planification et portée du projet Définit la portée au début et s’y tient. Les phases sont rigides et respectent le plan original. A une vision claire du produit final mais permet des changements. Le travail est organisé en sprints avec une flexibilité dans la façon dont les tâches sont accomplies. Suivi de la progression du projet Suit la progression au sein de chaque phase. Les retards dans une phase peuvent affecter l’ensemble du calendrier du projet. Suit la progression grâce aux sessions de démonstration à la fin de chaque sprint. Se concentre sur le produit réalisable. Collaboration en équipe Différentes personnes dans différentes phases du projet, interaction limitée. Équipe interfonctionnelle avec une communication constante entre les membres de l’équipe et les parties prenantes. Gestion des risques Suivi de l’état basé sur l’avancement de la phase. Répond aux risques de manière rétrospective tout en adhérant au plan. Se concentre sur la résolution proactive des dépendances entre les équipes et les activités. Adapte le plan pour éliminer les risques projetés.Cadre de mise en œuvreMéthodologie traditionnelle.Nécessite des pratiques de transformation pour s’adapter à l’approche agile. Implique un changement d’habitudes et de mentalités.
Ce choix définira cependant plusieurs aspects des propriétés d’exécution du projet.
#1. Exigences du projet et gestion du changement
L’un des aspects les plus importants déterminant le choix est la manière dont les exigences de l’utilisateur seront traitées. Et également, quelle est la procédure à suivre si une modification des exigences déjà convenues s’avère nécessaire ultérieurement ?
Avec un projet en cascade, toutes les exigences sont définies et signées par les parties prenantes dès le début ; si un changement dans cet état survient, le projet le traite comme une demande de changement. Il doit être à nouveau validé, convenu et confirmé.
Tout travail déjà réalisé jusqu’à ce moment doit être revisité et repris. Les coûts doivent être réajustés (car il s’agit de travaux supplémentaires non couverts par le contrat initial). Dans le pire des cas, même l’ensemble du calendrier du projet doit être prolongé.
Avec une configuration agile, les changements sont les bienvenus. Vous traitez les changements comme une activité quotidienne standard. Vous êtes d’accord avec les parties prenantes (probablement à la suite de la dernière démo de sprint) sur le fait que les changements sont cruciaux afin de maintenir la vision du projet. Ensuite, vous planifiez ces modifications immédiatement pour les prochains sprints.
Le contenu précédent changera en conséquence et les équipes continueront à travailler avec de nouvelles exigences à partir de ce jour. Il n’y a aucune perte de temps ni de coûts. Vous vous adaptez simplement immédiatement à la nouvelle réalité et remplacez le plan original par le nouveau. Il n’est pas du tout nécessaire de gérer spécifiquement les demandes de changement. Tout cela fait partie des initiatives de planification de sprint.
#2. Planification et portée du projet
Comme vous vous en doutez, le projet Waterfall définit et corrige toute la portée au début. Vous générez le plan de projet autour de cette portée. Ensuite, vous divisez la durée du projet en phases spécifiques (généralement analyse, conception, développement, test, déploiement, support et maintenance) et fixez les équipes et les ressources autour de ces phases. Pendant la majeure partie du calendrier du projet, votre objectif principal est de vous en tenir autant que possible à ce plan initial en termes de coûts et de calendrier.
Un projet agile a une vision du produit final au lieu d’un plan concret. L’état final est clair, mais le chemin pour y parvenir est libre de changer. De plus, le calendrier du projet est toujours défini et convenu sur la base d’une estimation préliminaire de la demande et de l’expérience en matière de charge de capacité pour les équipes travaillant sur le projet. Le plan ne comporte pas de phases distinctes. Au lieu de cela, chaque sprint est une petite phase en soi qui contient toutes les activités dont l’équipe a besoin pour lancer avec succès le produit incrémentiel.
En résumé, le projet Waterfall considère les changements comme une complication à résoudre (et une opportunité pour les vendeurs d’acquérir de l’argent supplémentaire). En revanche, le projet agile traite le changement comme si de rien n’était, sans conséquences supplémentaires (autres qu’un produit final mieux adapté).
#3. Suivi de l’avancement du projet
Le projet en cascade suit l’avancement du plan au cours des phases du projet. La phase de conception ne peut pas démarrer avant la fin de la phase d’analyse, les tests ne peuvent pas démarrer avant que l’ensemble de la construction ne soit terminé, etc.
Si certaines phases accusent un retard, cela affectera l’avancement des phases restantes du projet. C’est pourquoi il est important de vérifier les activités au sein de chaque phase et de s’assurer qu’elles progressent de manière linéaire au fil du temps. Sinon, vous augmentez le risque de retarder cette phase particulière et, par conséquent, l’ensemble du projet.
Le projet agile suit la progression, principalement avec des sessions de démonstration à la fin de chaque sprint. Le produit réalisable est la principale mesure du progrès. Naturellement, vous voulez vous assurer que chaque sprint se termine avec un contenu de sprint complet. Aucune ou seulement un minimum d’histoires sont reportées sur les prochains sprints.
En fin de compte, il est beaucoup plus facile de voir l’avancement global du projet si vous pouvez essayer directement l’incrément de produit actuel et revenir immédiatement à l’équipe avec des retours très concrets.
#4. La collaboration d’équipe
Il s’agit d’activités strictement distinctes en cascade par rapport à une collaboration continue avec toutes les parties d’une équipe agile.
Un projet en cascade fait généralement travailler différentes personnes dans différentes phases du projet. Ils peuvent se déborder dans une certaine mesure, mais ils restent des groupes de personnes différents. Presque les silos, pourrait-on dire.
La définition de l’équipe agile réside dans la communication et la valeur. Il s’agira également d’une équipe interfonctionnelle capable d’exécuter toutes les activités du cycle de vie des produits. Les silos des équipes sont quelque chose que vous ne voulez pas exister. Une communication constante entre l’équipe et les parties prenantes externes est une définition de base d’un projet agile réussi.
#5. Gestion des risques
De toute évidence, vous souhaitez disposer d’un processus permettant de suivre les risques, les problèmes ou tout type d’obstacles que le projet pourrait entraîner au cours de son calendrier.
Dans le cas d’un projet en cascade, cela se traduit par un suivi de l’état de la phase en cours du projet. Le rapport d’état standard de type sémaphore sera vert (tout est OK et conforme au plan), jaune (certains problèmes importants sont en place, mais on comprend toujours clairement comment les résoudre) ou rouge (ce qui signifie que le projet présente de sérieux problèmes qui peuvent avoir un impact sur les délais ou le budget initial).
Le projet agile est également différent ici. Vous ne suivez pas vraiment les progrès vers l’objectif. Au lieu de cela, vous résolvez les dépendances entre différentes équipes et types d’activités. L’objectif est de s’assurer qu’aucune équipe n’attend une autre équipe avec les activités de progression.
Naturellement, des risques peuvent apparaître, mais la solution doit alors modifier le plan pour que le risque disparaisse plutôt que de trouver la solution au risque tout en préservant le plan initial.
En d’autres termes, une configuration agile du projet utilise tous les moyens possibles pour modifier le plan afin de ne pas faire face aux risques projetés, ce qui signifie que la gestion des risques est proactive. Dans le cas d’un projet en cascade, vous réagissez aux risques de manière rétrospective et essayez de les résoudre dans les plus brefs délais tout en respectant le plan initial.
#6. Cadre de mise en œuvre
La tactique de mise en œuvre pour les projets en cascade est évidemment moins problématique que pour les projets agiles. Habituellement, la méthodologie en cascade correspond au statu quo que les gens pratiquent déjà depuis de nombreuses années.
D’un autre côté, les projets nécessitent des pratiques de transformation agiles pour changer leurs habitudes, leur état d’esprit et leurs méthodes de travail. Il s’agit d’un processus difficile et souvent assez long. Les entreprises investissent beaucoup de temps et de ressources pour apprendre aux gens à s’adapter aux processus agiles.
Les avantages sous la forme d’une adaptation rapide aux besoins changeants du client sont importants, mais changer l’état d’esprit des gens et l’environnement de travail global est la partie la plus difficile.
La plupart du temps, c’est aussi le seul moyen de rester compétent sur le marché, de sorte que les compromis sont récompensés par un grand succès pour ceux qui réussissent.
Derniers mots
Disons-le clairement. À moins que vous n’ayez un client très conservateur et peu motivé pour fournir rapidement des résultats à la production (pour quelque raison que ce soit), le mieux est de commencer à modéliser les équipes agiles dès le début. C’est littéralement une évidence dans le monde d’aujourd’hui. Cela est vrai même dans le cas de la configuration de systèmes traditionnels sur site. Surtout si l’équipe est nouvelle ou si elle part de zéro avec des personnes originales, il est toujours logique de transformer les processus pour les aligner sur les méthodologies agiles.
Cela dit, je vois encore des projets où les gens refusent tout simplement de suivre ce type de processus agile ou tout autre dispositif mais une organisation du travail strictement spécifique à certaines phases. Ils suivent le chemin habituel consistant à sous-traiter les travaux pour une durée et un budget spécifiques. Ensuite, ils s’attendent à ce que le projet suive cette configuration sans écarts par rapport au plan et à l’argent (avec des résultats variés, généralement pas bons).
C’est une décision qu’ils ont le droit de prendre, mais en fin de compte, avec une telle décision, ils décident aussi de rester dans le passé. Cela pourrait fonctionner pour eux pendant un certain temps encore, mais ce n’est qu’une question de temps avant que cela ne fonctionne plus.
Ensuite, consultez l’article détaillé sur le cycle de vie des tests Agile.