Select Dynamic field
octobre 28, 2020

Méthode en cascade ou agile?

Cascade ou agile? Le débat peut être passionné et les prises de position idéologiques.

More...

Voyons en toute objectivité, les avantages et les inconvénients de l’un et l’autre modèle de gestion de projet.

Le modèle en cascade (Waterfall en anglais) :

L’organisation des ressources humaines participant au projet est hiérarchique avec le chef de projet tout en haut de la pyramide.

Dans cette approche, toutes les activités du projet sont déroulées séquentiellement, chacune ayant pour intrant les livrables de la précédente.

Le projet est totalement planifié (fonctionnalités-cibles, budgets, calendrier, RH, etc.). Mais aucune flexibilité n’est possible.

Les demandes de changement en cours de projet sont mal acceptées car tout le projet doit faire machine arrière afin d’inclure les changements demandés. Les impacts peuvent être importants à tous les niveaux (budgets, délais, architecture technique du logiciel).

La documentation doit être écrite, complète, claire, et formellement validée. Dans ce contexte, la responsabilité de l’analyste est très importante.

Chaque fois qu’une DDC intervient, il faut que la doc soit mise à jour, revalidée et diffusée aux équipes.

Rigide, ce modèle est très efficace pour les petits projets, car tout est balisé à l’avance, en particulier les règles d’affaires.

Les méthodes agiles.

Les méthodes agiles suivent les 12 principes du Manifeste agile publié en 2001.

Reposant sur une approche itérative, elles sont cadencées en des cycles de 2 à 4 semaines appelés sprints.

Elles visent à déployer une version du logiciel au terme de chaque sprint.

Ces déploiements cadencés permettent aux utilisateurs de valider rapidement l’adéquation du logiciel avec leurs besoins.

On privilégie une approche collaborative avec le client plutôt que la négociation contractuelle. Et il n’existe pas de hiérarchie dans les équipes agiles.

On valorise le fait de produire un logiciel opérationnel plutôt que de la documentation.

Très flexible, on accueille le changement plutôt que de coller à un plan défini à l’avance.

Cette approche est indiquée pour les projets longs, en particulier quand les règles d’affaires sont susceptibles de changer en cours de projet.

Cependant, l’absence de périmètre et de date de fin de projet définis à l’avance exposent à une dérive potentielle.

Cette approche, vraiment novatrice par rapport aux méthodes traditionnelles, exige que tous les contributeurs soient formés pour maîtriser la philosophie, la terminologie, les différents rôles, les cérémonies…

Cascade ou agile? Alors on décide comment?

Évidemment je ne détiens pas la Vérité, mais voici quelques critères à considérer pour faire votre choix :

  • Si vous faites face à une échéance immuable;
  • Si le périmètre du projet est clair et relativement restreint;
  • Si les exigences d’affaires sont claires;
  • Si vous êtes confiant(e) de pouvoir produire une documentation fonctionnelle complète et claire;
  • Si vous êtes confiant(e) que tous les acteurs du projet saisissent tous les requis du projet
  • Et que par conséquent les risques de demandes de changement en cours de projet sont réduits;

👉 Alors je crois qu’une méthodologie traditionnelle est plus appropriée…

  • Si vous n’êtes pas confronté à une échéance immuable;
  • Si le fait de ne pas avoir une vue claire du produit final n’est pas un enjeu;
  • Si le périmètre du projet est vaste et nécessite d’être exploré pour en saisir toute la portée;
  • Mais qu’il est nécessaire d’avoir un produit minimum viable rapidement;
  • Si tous les acteurs du projet sont familiers avec les méthodes agiles;
  • Ou qu’à tout le moins, tous sont confortables avec une approche collaborative;

👉 Alors une méthodologie agile devrait être appropriée…

Abonnez-vous à notre infolettre

>