La différence entre les modèles de développement en Cascade, en Cascade itératif, Scrum et Lean (en images !)

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101, aoû 2009))J’ai traduit un billet intéressant de Tara Lee Whitaker sur Agile101 : ++[The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean (In Pictures!)|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++%%% %%% > 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|http://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/|en]++).%%% > – 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.%%% > %%% > ((/dotclear/public/./.the-difference-between-waterfall-iterative-waterfall-scrum-and-lean_t.jpg|The difference between Waterfall, Iterative waterfall, Scrum and Lean (by Agile101)||The difference between Waterfall, Iterative waterfall, Scrum and Lean)) > %%% > Pour voir le schéma dans sa taille normale, rendez-vous sur le ++[billet de l’auteur Tara Lee Whitaker|http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-waterfall-scrum-and-lean-in-pictures/|en]++

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *