Scrum vs Kanban vs Agile vs Cycle en V : le comparatif

Comparatifs entre les méthodes

Scrum VS Kanban VS Agile VS Waterfall : le comparatif

Voici un résumé de certaines des méthodologies de développement de logiciels les plus populaires : Scrum, Kanban, Agile (au sens large) et le Cycle en V (ou Waterfall), pour déterminer celle qui convient le mieux à votre équipe.
Source originale : https://dzone.com/articles/scrum-vs-kanban-vs-agile-vs-waterfall-a-side-by-si
Ceci est une traduction libre de l’article de Fred Wilson, publié le 23 octobre 2018, par Martial SEGURA.

Plusieurs cadres et méthodologies de gestion de projet efficaces ont été introduits au fil des années pour assurer une gestion efficace des équipes et une collaboration optimale dans le monde du travail.

À partir du modèle Waterfall (le « Cycle en V » pour les « frenchies »), de nombreuses approches sont aujourd’hui utilisées par les équipes de développement logiciel du monde entier pour simplifier le travail en ayant un contrôle accru de la gestion de projet et des livrables du produit.

De nombreux facteurs doivent être pris en compte avant de choisir une approche se voulant optimale pour une équipe, puis pour un projet. En effet, l’expansion de ces différentes approches a également créé des confusions parmi le plus grand nombre de professionnels quant aux spécificités d’une approche, aux circonstances de son adoption et à leurs avantages et inconvénients.

Dans cet article, nous essaierons de clarifier les concepts de base derrière Scrum, Kanban, Agile et le Cycle en V. En général, les professionnels débutants dans la gestion de projet peuvent avoir du mal à clarifier leurs concepts concernant ces méthodes.

Les recherches populaires sur Internet telles que Scrum contre Kanban, Scrum contre Agile, Scrum contre Waterfall, Kanban contre Agile, Kanban contre Waterfall et Agile contre Waterfall mettent en valeur la nécessité de comparer toutes ces approches entre elles.

Chaque élément ayant son propre ensemble unique du pourquoi et du comment, voici notre tentative d’éclaircir le sens réel de ces termes et ce qui les distingue.

Allez, commençons !

 

Scrum

Scrum Framework

Scrum Framework – Crédits : scrum.org


Comparer Scrum à Agile revient à comparer une pomme à un fruit.
L’un est une sous-catégorie de l’autre. Scrum est l’un des frameworks Agile qui s’est le plus répandus dans tous les secteurs d’activités, ces dernières années.

Selon une étude réalisée par Forbes , 49% des cadres dirigeants interrogés par Forbes affirment que le succès de Scrum s’explique principalement par le fait qu’il se concentre sur les clients. Cette population apprécie, chez Scrum, une méthodologie éprouvée pour une collaboration optimisée, des livraisons de projets rapides et une réduction des erreurs. D’ailleurs, Scrum gagne de plus en plus en popularité dans le monde Agile.

Initialement supposé être utilisé par les équipes de gestion de projets logiciels, Scrum est conçu et développé de manière à prendre en charge de nombreux domaines d’activités, notamment le développement de logiciels, l’éducation, les soins de santé et bien plus encore.

Le concept à la base de Scrum est l’alignement de l’équipe et la répartition du travail de manière à maximiser l’efficacité et à réduire les goulets d’étranglement tout en progressant progressivement vers la réalisation du projet et la satisfaction du client.

Les rôles dans Scrum comprennent ceux de l’équipe Scrum, du Product Owner (propriétaire du produit) et du Scrum Master. L’équipe comprend l’ensemble des personnes travaillant sur le projet, le Product Owner est la personne chargée de la conception fonctionnelle du produit et des échéances et le Scrum Master facilite les échanges entre l’équipe et le Product Owner dans la mise en œuvre des travaux à accomplir. ▶ Plus d’info : Qui fait quoi dans une équipe Scrum ?

Cela implique que tout le monde s’assure d’être aligné sur les objectifs du produit à réaliser ainsi que les échéances à respecter.

Encourageant la participation des clients / utilisateurs à chaque étape, Scrum aide à définir le calendrier du projet sous la forme de Sprints et de Daily Scrums.

D’une part, le Sprint décrit l’intervalle ou la période de temps nécessaire à l’exécution d’un ensemble de tâches défini par le Product Owner sous la forme d’un backlog de produit. Un sprint peut durer 1 semaine à 4 semaines en fonction des exigences du client et de la faisabilité du projet.
NDLR : Au delà de l’exécution d’un ensemble de tâches c’est surtout un objectif à atteindre. Scrum c’est du management par objectif donnant du sens. Merci Benjamin FEIREISEN pour ta vigilance.

D’autre part, le Daily Scrum est une réunion quotidienne entre l’équipe, le Product Owner, le Scrum Master, les clients et la direction (recommandée) pour évaluer l’achèvement quotidien des tâches ainsi que les obstacles rencontrés et les risques potentiels, relevés à date.
NDLR : Le Scrum Guide n’indique pas que les clients et la direction doivent être présent au Daily Scrum, même si cette pratique peut s’avérer profitable pour le projet dans certains contextes.

Ce concept de définition de jalons comprenant des rôles attribués dans des périodes définies vise à obtenir un meilleur taux d’achèvement du projet grâce à un flux de travail transparent et à des méthodes de contrôle fiable. La satisfaction du client est également plus plausible en raison d’un engagement encouragé tout au long du cycle de développement du projet.

Les pièges potentiels sont plus facilement évités en atténuant les incohérences au sein de l’équipe, ce qui permet une meilleure gestion des coûts et des problèmes.

 

Kanban

Kanban Board

Kanban Board – crédits : kisspng


Inventée à l’origine par Taiichi OHNO (chez TOYOTA)
, la méthode Kanban a révolutionné l’industrie automobile. Peu de temps après, elle a été reprise par David ANDERSON pour le développement informatique. Au fil du temps, Kanban a acquis une réputation majeure dans diverses industries, notamment dans les logiciels, les opérations informatiques et même le marketing.

Kanban est un autre exemple de framework Agile conçu pour rationaliser le cycle de vie des projets et rendre la collaboration des équipes plus efficace, notamment grâce à des améliorations cohérentes et à une gestion simplifiée du changement. Comme avec Scrum, comparer Kanban à Agile n’est pas raisonnable, car Kanban est une sous-catégorie de frameworks Agile.

En tant que membre de la même famille, Scrum gagne la course en ce qui concerne Scrum vs. Kanban. Une raison à cela pourrait être que Scrum vise une planification efficace dès le début du projet et une évaluation cohérente et constante garantissant que le projet reste sur la bonne voie, tandis que Kanban se concentre davantage sur l’amélioration continue via des modifications incrémentielles dans un environnement de travail défini.

Selon un article de recherche d’Ahmed, Markkula et Oivo réunissant des répondants de 27 organisations différentes, les praticiens ont perçu le kanban comme facile à apprendre et utile pour le travail individuel et en équipe.

Le système Kanban s’articule autour d’un tableau central Kanban ( management visuel ) utilisé pour l’organisation et la hiérarchisation des tâches. Composé de colonnes, le tableau Kanban présente chaque élément du flux de travail dans des étapes de progression, de test, de disponibilité et de publication. Une autre manière possible de définir des colonnes peut être Tâches à faire, En cours, En révision, Bloquées et Terminé. Ce fonctionnement permet aux équipes de rester ouvertes aux changements et d’implémenter facilement l’écart selon les besoins.

Kanban intègre le « travail en cours » (WIP = Work In Progress) pour le cycle de tâches. Cela implique de définir une limite pour chaque colonne ou état mentionné sur le tableau Kanban. Cette limite WIP détermine le nombre d’éléments de travail ou la quantité de travail à conserver dans un certain état à tout moment.

Atteindre une limite WIP prédéfinie signifie qu’aucun nouveau travail ne peut être autorisé à être catégorisé dans cet état. Cela oblige l’équipe à terminer les éléments en attente avant d’adresser de nouveaux éléments.

S’agissant des rôles d’équipe dans Scrum vs. Kanban, contrairement à Scrum avec un ensemble de rôles défini pour chaque objectif, Kanban ne spécifie aucun rôle d’équipe. Au lieu de cela, il se concentre sur l’amélioration du flux de projet et de la qualité du produit au niveau collectif ou de l’équipe.

Le tableau Kanban peut être utilisé et modifié par n’importe qui dans l’équipe, dans la mesure où il décrit le statut des forces de travail et les modifications concernées. Cela signifie qu’il n’y a pas de personne dédiée pour s’assurer que l’équipe est alignée ou adhère aux politiques de travail établies.

Kanban contribue à l’optimisation globale du cycle de développement d’un projet en aidant les équipes à améliorer le projet de manière continue. Cela conduit finalement à de meilleurs taux de rendement et de temps tout en maintenant la qualité du produit résultant.

 

Agile

Agile valeurs et principes

Agile umbrella – Crédits : Henrik KNIBERG

Selon une étude du Project Management Institute (PMI), environ les trois quarts (71%) des organisations utilisent des approches Agiles. Agile est une approche de développement logiciel qui aide les équipes à collaborer entre elles pour répondre aux exigences et aux solutions correspondantes tout au long de leur évolution.

Agile intègre des règles permettant aux équipes de mieux planifier, développer, livrer tôt et rapidement un projet tout en restant prêt à faire face aux changements soudains et en réagissant de manière appropriée à ces changements.

Parmi les nombreux frameworks Agiles utilisés, certains incluent :

  1. Scrum,
  2. Kanban,
  3. Scrumban (mélange de Scrum et de Kanban),
  4. Programmation extrême (XP),
  5. Développement de logiciels adaptatifs (ASD),
  6. Modélisation agile,
  7. Processus unifié agile (AUP),
  8. Livraison agile disciplinée,
  9. Méthode de développement de systèmes dynamiques (DSDM),
  10. Développement piloté par les fonctionnalités (FDD),
  11. Développement de logiciels Lean, et
  12. Développement rapide d’applications (RAD)

En ce qui concerne Agile contre Waterfall , ou en d’autres termes, Agile contre méthodes traditionnelles, Agile a acquis une popularité extrêmement forte par rapport à son homologue, la méthode Waterfall (ou Cycle en V).

La méthodologie de base adoptée par ces cadres est la suivante : les projets sont divisés en éléments appelées user stories, qui sont ensuite organisées et hiérarchisées avant la livraison successive en cycles appelés itérations.

Pour mieux comprendre le concept derrière Agile, vous pouvez consulter le Manifeste Agile qui comprend un ensemble de 12 principes fondamentaux conçus pour rendre le développement logiciel efficace et davantage axé sur les résultats. Ces principes sont :

  • Satisfaction du client par la livraison rapide et continue de logiciels de valeur
  • Bienvenue aux nouvelles exigences, même en fin de développement
  • Le logiciel opérationnel est livré fréquemment (semaines plutôt que mois)
  • Coopération étroite et quotidienne entre utilisateurs (métiers) et développeurs
  • Les projets grandissent autour d’individus motivés, à qui il faut faire confiance
  • La conversation en face à face est la meilleure forme de communication (co-localisation)
  • Un logiciel fonctionnel est la principale mesure de progrès
  • Développement durable, capable de maintenir un rythme constant
  • Attention constante à l’excellence technique et au bon design
  • La simplicité – l’art de maximiser la quantité de travail non effectué – est primordiale
  • Les meilleures architectures, exigences et conceptions émergent d’équipes auto-organisées
  • L’équipe réfléchit régulièrement sur la manière de devenir plus efficace et s’ajuste en conséquence

Comme le montrent clairement les principes énoncés, Agile est conçu pour mettre l’accent sur les individus et les interactions (sur les processus et outils), les logiciels opérationnels (sur la documentation complète), la collaboration client (sur la négociation du contrat) et sur l’adaptation aux changements (sur le suivi d’un plan).

En bref, Agile se concentre sur la réalisation progressive de projets de qualité au lieu de réaliser toutes les activités pertinentes en une seule fois. Cela permet de garder une trace de l’avancement du projet en laissant assez de place pour se concentrer sur chaque élément distinct de la gestion de projet logiciel du début à la fin.

Découvrez comment fonctionne la gestion de projet agile pour des projets non logiciels (en anglais).

 

Cycle en V (ou Waterfall)

Modèle Waterfall

Modèle Waterfall (représenté comme un Cycle en V en francophonie)

NDLR : J’assimile le cycle en V et le Waterfall (Cascade en anglais) car, hormis la représentation, je crois que le fonctionnement est sensiblement le même. Il se trouve que le terme « Cycle en V » est aussi mieux connu en France que le « Waterfall », d’où ce changement de terminologie par rapport à la version anglaise.

Au lieu de comparer Scrum vs Waterfall ou Kanban vs Waterfall, nous pouvons simplifier la comparaison en évaluant le scénario de la méthode Agile vs Waterfall. Cela peut être fait en comprenant la méthode traditionnelle ce qui revient à la nommer Waterfall.

Le modèle en cascade (Waterfall) est également appelé modèle de cycle de vie linéaire-séquentiel. C’était le premier modèle de processus à avoir été introduit. Originaire de la construction et de la fabrication, ce modèle a été utilisé dans des environnements physiques très structurés et difficiles à adapter aux changements.

Le modèle Waterfall était le modèle de cycle de vie de développement de logiciel adopté car il ne n’existait pas d’alternatives spécifiques à ce domaine d’activités. Dans cette approche, chaque étape ou ensemble de tâches doit être terminée(s) avant que l’étape suivante puisse être commencée.

Cela évite le chevauchement des étapes du projet. Le flux de travail est conçu pour se dérouler dans une seule direction, descendante, semblable à une cascade incorporant les étapes d’idéation, d’initialisation, d’analyse, de conception, de réalisation, de test, de déploiement et de maintenance du projet.

Comme avec toutes les approches, la cascade présente également de nombreux avantages.Pour commencer, les étapes de planification et de conception de projet sont mieux établies et plus simples, ce qui permet une plus grande synchronisation entre l’équipe de développement et les clients sur les produits livrables du projet.

Il est également plus facile de mesurer les progrès car l’ensemble du périmètre projet est annoncé à l’avance. Au lieu que l’ensemble de l’équipe travaille sur une seule étape, les développeurs, les testeurs, les analystes fonctionnels et les experts des autres domaines liés au projet peuvent se concentrer à d’autres projets, au moment où le projet en cours est à un stade donné et traité par une équipe différente.

Une fois les exigences établies par les demandeurs (ou les clients), il n’est plus nécessaire de les impliquer tant que les travaux ne sont pas terminés.

Malgré tout, cela génère également une approche plus rigide, moins itérative et non susceptible d’être modifiée. Cela appelle un ensemble d’inconvénients par rapport à son homologue Agile. En ce qui concerne Agile vs Waterfall, le modèle Waterfall ne laisse pas beaucoup de place à des modifications ou des révisions.

Cela rend considérablement difficile la reprise des étapes précédentes au cas où un problème surviendrait ou si un risque s’avèrerait. Une fois planifié, le flux de projet doit suivre le cycle de développement complet avant toute modification, ce qui rend très difficile sa mise en œuvre et sa pérennité au moment où les exigences des clients et les tendances du marché subissent des modifications rapides et imprévues.

Pour cette raison, l’approche Agile constitue une alternative fiable, en particulier pour les projets et les équipes nécessitant davantage de flexibilité et de gestion du changement. En fait, les résultats de l’étude 2018 du Standish Group Chaos montrent que, dans les projets Agile vs Waterfall, Agile a tendance à être deux fois plus performant et un tiers moins susceptible d’échouer que les projets Waterfall.

Quelle approche ou méthodologie votre équipe (ou organisation) utilise-t-elle et pourquoi ? Partagez vos expériences dans les commentaires ci-dessous.

 

Source originale : https://dzone.com/articles/scrum-vs-kanban-vs-agile-vs-waterfall-a-side-by-si
Ceci est une traduction libre de l’article de Fred Wilson, publié le 23 octobre 2018, par Martial SEGURA.
NDLR = Note De La Rédaction (en clair, les notes complémentaires de Martial SEGURA)
Source images : scrum.org

……… ✂……………………………… ✂………………………………… ✂…………………………………

Envie d’aller plus loin ?

……… ✂……………………………… ✂………………………………… ✂…………………………………

En quoi puis-je vous aider ?

Je suis Martial SEGURA, coach agile SAFe freelance chez Oeil de Coach.

« Ma mission est d’aider les personnes, les équipes et les organisations à atteindre leurs buts beaucoup plus vite qu’ils ne le feraient sans ma contribution. »

Contactez-moi pour en parler :

🚀 Linkedin : https://www.linkedin.com/in/martialsegura
📱 Mobile : (+33) 6 82 15 70 32
🌐 Blog : www.oeildecoach.com

3 Commentaires

  1. Matthias 5 août 2021 Répondre
  2. Matthias 5 août 2021 Répondre

Laisser un commentaire :

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.