L’analyse comparative Waterfall/Scrum/Kanban

Waterfall, ses inconvénients

Les principaux inconvénients du cycle en V sont :

• Livraison de la version applicative qu’en fin de développement et de ce fait, on ne découvre les problèmes que longtemps après. La phase de débugage est lourde à gérer et l’analyse causal des dysfonctionnements n’est pas forcement simple.
• Opacité la plus complète pour le client sur l’avancement du projet. L’ensemble du livrable applicatif étant livré uniquement en fin de chaîne, le client doit s’en remettre à son fournisseur pour piloter les charges couts et délais de son projet.
• L’adaptation d’un projet en cycle en V a des changements de besoins client (modification de cahier des charges / ajout de fonctionnalité / …) n’est pas simple.
• Le waterfall ne laisse derrière lui aucun cadre méthodologique (ou très peu) qui puisse être réutilisé lors d’un développement futur de l’application. La TMA de l’application n’hérite que de peu de chose pour commencer la vie courante de l’application.
• Lors de la mise en œuvre d’un développement d’une release majeur d’application la cohabitation entre les équipes de la TMA et l’équipe de développement n’est pas simple. L’intégration des correctifs issue de la TMA dans le projet de développement ne se fait pas simplement.

Scrum, ses inconvénients

Le Scrum solutionne certains problèmes du waterfall, principalement les problématiques d’opacité vis-à-vis du client, d’adaptabilité du projet aux changements clients. Il simplifie le débugage et laisse derrière lui une usine de développement réutilisable. Cependant Scrum n’est pas très pertinent sur le cadre méthodologique de TMA et a quelques difficultés à faire cohabiter les projets de développement et la maintenance applicative. Scrum « impose » la présence quasi-permanente d’un représentant du client dans l’équipe projet et fonctionne difficilement sans retour/validation périodique du client.

Kanban : solutions aux inconvénient Waterfall et Scrum

Kanban, au lieu d’aborder la problématique par le processus de développement d’une application (nouveau projet/évolution), il l’aborde par la vie courante de l’application (la TMA) et vient ensuite intégrer les problématiques de développement au processus de gestion de la vie courante de l’application. De ce fait, la maintenabilité de l’application et les règles de priorité correction/nouveau développement sont nativement intégrés dans la méthodologie Kanban. Le principal atout de Kanban lors d’un développement d’une nouvelle application est de mécaniquement laisser un cadre méthodologique viable et robustepour la vie courante de l’application. Le passage entre le développement et la TMA est « sans couture ». L’intégration d’un nouveau projet de développement sur une application pilotée en Kanban est facilitée par l’existence préalable d’une équipe de TMA organisée pour délivrer des tâches hiérarchisées, cadencées, … Pourquoi mettre en place du Scrum si on a déjà du Kanban. Le coût de mise en œuvre du Kanban est inférieur au coût de mise en œuvre du Scrum dans le cas d’une application déjà en production et qui ne possède pas de cadre méthodologique.

Pourquoi et quand choisir Kanban ? Les clés de succès ?

Kanban a maintenant fait ses preuves dans pas mal d’organisations, bien mis en œuvre, il permet de gagner en efficacité. Là où il est le plus performant est sur la vitesse de livraison en production des taches. Le temps entre la demande utilisateur et sa mise en production devient très court. Bien sûr pour réaliser cela, il faut que le temps de livraison (qui ne dépend souvent pas de l’équipe de développement) soit court lui aussi. Les retours positifs sont donc meilleurs lorsqu’une livraison continue est mise en place, mieux une organisation devops est vraiment l’idéal.

Scrum reste bien adapté à un développement d’application web, mais il n’est pas très à l’aise sur de la maintenance avec du correctif. Alors que Kanban, grâce à sa grande souplesse d’application, saura s’adapter dans tous les cas.

Kanban mérite aussi un temps de mise en place assez long, il faut parfois attendre des mois pour en voir les bénéfices. Il est donc préférable de choisir une méthode très structurée comme le Scrum pour un projet court avec une équipe nouvelle.

Le ScrumBan

La méthode idéale n’existant pas, il convient de prendre le meilleur de chaque méthode. Les adeptes du Kanban ont depuis longtemps pris quelques items de la méthodologie Scrum pour améliorer leur méthode et faire du Kanban le champion incontesté des méthodes de développement (avis personnel des auteurs). Le Kanban peut intelligemment récupérer les principes Scrum suivant :

• Ritualisation du « Daily meeting » pour communiquer à l’équipe les informations de vue générale du projet.
• Méthode d’évaluation des charges de chaque activité (planning poker).

Cette méthodologie hybride permet de tirer le meilleur parti de chaque méthode.

Par Stéphane, à Paris