La différence entre les modèles de développement en cascade, en cascade itératif, Scrum et Lean (en images !)
Auteur : Agile101 - Tara Lee Whitaker
Source : The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean (In Pictures!)
Date : 08/09/2009
Traducteur : Fabrice Aimetti
Date : 09/09/2009
Traduction :
Voici un aperçu TRÈS simple des principales différences entre le Développement en Cascade, le Développement en Cascade Itératif, le Développement Scrum/Agile et Lean.
Le Développement en Cascade
"Le Développement en Cascade" est un autre nom pour l’approche la plus traditionnelle du développement logiciel.
On l’a baptisé "cascade" car ce type de développement est souvent planifié en utilisant un diagramme de Gantt : vous terminez une phase (la planification, par exemple) avant de passer à la phase suivante (par exemple, le développement).
Dans les approches en Cascade, vous aurez rarement l’objectif de revisiter une "phase" une fois qu’elle est terminée. En tant que tel, il vaut mieux que vous produisiez correctement du premier coup !
Cette approche est très risquée, souvent plus coûteuse et généralement moins efficace que la plupart des approches Agile.
Les principaux problèmes liés à cette approche sont les suivants :
- Vous ne produisez aucune valeur tant que le projet n’est pas fini (déploiement) (Lire Self-Funding Projects – A Benefit of Agile Software Development).
- Vous réalisez les tests à la fin, ce qui signifie que vous découvrez les problèmes au dernier moment.
- Vous ne recherchez pas l’approbation des parties prenantes avant la fin du projet sachant que leurs besoins pourraient avoir changé.
- Vous êtes fortement dépendant du planning, que vous suivez souvent au détriment du résultat final.
- Vous êtes fortement dépendant d’un chef de projet traçant la voie : le pouvoir à une seule personne.
Le Développement Itératif en Cascade
Cette approche comporte moins de risque que l’approche classique en Cascade, mais reste encore beaucoup plus risquée et moins efficace que les approches plus Agile.
L’accent est mis sur la livraison d’un sprint de tâches, et s’oppose à la livraison d’un sprint de fonctionnalités à valeur ajoutée et potentiellement déployables.
Le problème le plus fréquent dans ce type de scénario (selon mon expérience) est le goulet d’étranglement (bottlenecking).
Par exemple, vous livrez des portions de code, avec un peu d’avance (?), et vous laissez tout en l’état jusqu’à la dernière minute pour tout tester. Un problème prend plus de temps que prévu à résoudre, finalement vous dépassez la date limite et vous ne livrez rien.
Un autre symptôme fréquent de ce type d’approche est le sur-engagement. C’est vraiment difficile d’estimer l’effort (total) liées à une User Story / Fonctionnalité particulière lorsqu’on adopte ce mode de production/livraison.
Vous êtes plus ou moins forcé d’estimer chaque phase séparément (par exemple estimez le développement séparément des tests dans ce cas) : cela ne fonctionne pas puisque les phases ne sont pas séparées, elles sont totalement imbriquées.
Si vous trouvez un problème lors des tests, vous devez revenir en phase de développement. Toute l’équipe doit rester concentrée sur la livraison de la cible finale, pas de phases séparées.
Il est également intéressant de noter que la vélocité et les burndowns sont loin d’être (voire pas du tout) utiles dans ce type d’environnement.
Le Développement Scrum
Cette approche comporte un risque beaucoup moins grand que les approches en Cascade.
Nous nous concentrons sur la livraison de fonctionnalités entièrement testées, indépendantes, à valeur ajoutée et suffisamment petites. En tant que tel, nous diversifions notre risque : si l’une des fonctionnalités tourne mal, elle ne devrait pas en impacter une autre.
Cela dit, nous prévoyons encore du travail sous forme d’itérations et nous devrons encore livrés à la fin de chaque itération.
Le Développement Lean
Lean est très similaire à Scrum en ce sens que nous mettons l’accent sur les fonctionnalités plutôt que sur des groupes de fonctionnalités : toutefois Lean va encore un peu plus loin.
En Développement Lean, vous choisissez, planifiez, développez, testez et déployez une fonctionnalité (sous sa forme la plus simple) avant de choisir, planifier, développer, tester et déployer la prochaine fonctionnalité. En faisant cela, vous isolez encore plus les risques au niveau de chaque fonctionnalité.
Dans ces environnements, on cherche à éliminer le "gaspillage" autant que possible : vous ne produisez donc rien jusqu’à ce que vous sachiez que c’est nécessaire ou pertinent.
