Gestion de projet traditionnelle vs agile : principales différences et explication du triangle de fer

Gestion de projet traditionnelle

L’approche traditionnelle de gestion de projet (en cascade) est linéaire, où toutes les phases du processus s’enchaînent de manière séquentielle. Cette méthode repose sur des outils prévisibles et une expérience prévisible. Chaque projet suit le même cycle de vie, comprenant les phases de faisabilité, de planification, de conception, de réalisation, de test, de mise en production et de support, comme indiqué dans la figure ci-dessous.

Cascades vs développement logiciel agile

Tout le projet est pré-établi sans possibilité de modification des exigences — comme dans la méthode en cascade, le PMBOK de PMI ou PRINCE2, qui sont rigides et fortement contrôlés. Ils définissent des phases distinctes du début à la fin et supposent que vous disposez déjà de toutes les exigences et informations nécessaires.

Cette approche suppose que le temps et le coût sont des variables, tandis que les exigences sont fixes — c’est pourquoi la gestion de projet traditionnelle éprouve souvent des difficultés avec les problèmes budgétaires et les délais.

Gestion de projet agile

Alors que les systèmes traditionnels mettent l’accent sur la planification préalable, des facteurs comme le coût, la portée et le temps sont essentiels. L’agilité, en revanche, met l’accent sur le travail d’équipe, la collaboration avec le client et la flexibilité.

L’agilité rejette la gestion de projet traditionnelle comme fastidieuse, restrictive et inadaptée au monde moderne à rythme rapide. La gestion de projet agile est itérative, visant à intégrer continuellement les retours des utilisateurs et les livraisons continues à chaque itération de développement, comme indiqué ci-dessus. Chaque sortie de tâche est un produit que vous vendez aux parties prenantes. Les équipes et les flux de travail sont structurés autour de la création de quelque chose directement utile pour le client.

Traditionnel ou agile – Comment choisir ?

Selon le rapport CHAOS 2011 de Standish Group, les projets agiles sont trois fois plus réussis que les projets en cascade. Le graphique ci-dessous présente les résultats spécifiques des études menées entre 2002 et 2012 :

Taux de réussite des projets en cascade vs agile

Différences entre le traditionnel et l’agile

Le tableau ci-dessous résume de nombreuses différences clés entre les modèles de gestion de projet Scrum et traditionnels.

Coût des modifications

Traditionnellement, les modifications apportées aux projets logiciels sont évitées car le coût augmente considérablement plus tard dans le projet. Le développement logiciel agile reconnaît que les changements sont inévitables et qu’un investissement important dans la planification initiale est peu réaliste. Cela est clairement exprimé dans l’une des quatre valeurs du Manifeste Agile :

« Répondre aux exigences changeantes plutôt que de suivre un plan fixe. »

L’agilité remet en question cette idée et soutient que le coût des modifications peut être relativement constant, comme le montre la figure ci-dessous :

Coût des modifications dans les approches traditionnelles vs agiles

Agilité vs triangle de fer traditionnel en gestion de projet

Le succès de la gestion de projet a traditionnellement été associé à la capacité de gérer les contraintes liées au périmètre, au temps, au coût et à la qualité, comme le montre la figure ci-dessous. Il s’agit d’une métaphore populaire suggérant que les gestionnaires de projet sont censés équilibrer raisonnablement ces contraintes.

Triangle de fer dans la gestion de projet agile vs traditionnelle

Quel est le problème avec le triangle de fer traditionnel ?

Par exemple, un projet peut être terminé plus rapidement en augmentant le budget ou en réduisant la portée. De même, l’élargissement de la portée exige généralement une augmentation correspondante du budget et du délai. Réduire le budget sans ajuster le délai ou la portée entraîne une baisse de qualité. Toutefois, en pratique, les compromis entre contraintes ne sont pas toujours possibles. Par exemple, investir davantage de fonds (et de personnes) dans un projet doté de ressources abondantes peut en réalité ralentir le progrès. En outre, dans les projets mal performants, améliorer le budget, le planning ou la portée sans nuire négativement à la qualité est souvent impossible.

En conséquence, le triangle de fer traditionnel est clairement insuffisant comme modèle de réussite d’un projet, car il néglige des dimensions clés du succès, notamment l’impact sur les parties prenantes, l’apprentissage et la satisfaction des utilisateurs.

Triangle de fer Agile – Un changement de paradigme

Dans l’approche traditionnelle, le triangle a généralement l’aspect de celui de gauche illustré ci-dessous. Comme vous pouvez le voir, les exigences du produit ont une portée fixe. Par conséquent, pour garantir que le produit livre toutes les fonctionnalités requises, nous devons disposer d’une certaine flexibilité en matière de ressources (et de budget) et de délai (date limite). Si nous devons absolument que le produit inclue la liste complète des fonctionnalités décrites dans la spécification initiale des exigences, nous pourrions devoir retarder la date de mise en production de plusieurs mois ou plus.

Dans le sens Agile, il existe un délai fixe (dans Scrum, cela est obtenu grâce àsprints à durée fixe sprintset ressources fixes). Par conséquent, lorsque les choses ne se déroulent pas comme prévu, la portée doit être réduite. Mais en Agile, nous veillons à ce que, même si nous devons compromettre la portée, nous livrions tout de même les éléments de plus haute priorité duProduct Backlogafin de maximiser la valeur générée par le projet.

Triangle de fer dans un contexte Agile