Méthodologies de développement de logiciels : Principes Lean vs Agile

« Lean » et « Agile » sont des termes qui ont été beaucoup lancés ces derniers temps, souvent en référence à des méthodologies de développement logiciel, à la gestion de projet ou à des styles organisationnels.

Mais vous arrive-t-il de vous demander :

Qu’est-ce que le Lean ? Qu’est-ce qu’Agile ? Y a-t-il une différence ?

Le dictionnaire Merriam-Webster définit l’agile comme  » ayant un caractère prompt à la débrouillardise et à l’adaptation, ou marqué par une capacité à se déplacer avec une grâce rapide et facile. « 

Lean est défini simplement comme  » mince et sain, ou contenant peu ou pas de graisse. « 

Sur la base de ces définitions, nous pouvons supposer qu’une personne qui est maigre et une personne qui est agile pourraient avoir de nombreuses caractéristiques communes. Il en va de même dans le contexte du développement logiciel.

Qu’est-ce que l’agile ? Qu’est-ce que le lean ?

L’agile est maintenant largement connu dans le monde de la technologie comme un ensemble de valeurs et de principes pour guider le développement de logiciels. « Le manifeste Agile » énonce un ensemble de quatre valeurs et de 12 principes. Distillé en son cœur, Agile est exactement ce que vous pensez qu’il pourrait être. C’est Agile. Cette méthodologie privilégie la flexibilité, la communication, la collaboration et la simplicité.

La méthode Lean est moins bien comprise et ne dispose pas d’une définition claire et nette soutenue par un consensus professionnel.Le terme « Lean » a été inventé à l’origine pour décrire un modèle d’organisation manufacturière basé sur le système de production Toyota, mais il est communément considéré comme un sous-cadre dans le parapluie Agile du développement logiciel.

Aujourd’hui, il y a beaucoup de confusion sur ce qu’est le Lean, ce qu’est l’Agile, s’il s’agit d’une seule et même chose, et laquelle doit être utilisée.

La naissance de nouvelles méthodologies de développement logiciel

Le Lean et l’Agile ont tous deux été développés en réponse aux lacunes des méthodes existantes axées sur le plan, comme Waterfall. Utilisées depuis les années 1970, les développeurs et les responsables du génie logiciel ont commencé à remarquer les inefficacités de Waterfall dans les années 1990. Avec des marchés plus dynamiques et des consommateurs avertis en matière de technologie, Waterfall n’était pas en mesure de répondre assez rapidement aux demandes du marché, à l’évolution de la technologie ou de fournir des logiciels sans bogues de manière constante.

En quête d’un meilleur modèle, les créateurs de Lean et Agile ont cherché à développer des méthodologies avec une approche plus axée sur le client. Les nouvelles méthodologies ont adopté la capacité d’adaptation comme un avantage concurrentiel, ont favorisé les tests précoces et continus, et ont apporté un élément humain dans la gestion et l’exécution des projets.

Principes Lean vs Agile

Lean Software Development (LSD) a été proposé pour la première fois par le Dr. Robert Charette comme un moyen de construire des organisations tolérantes au changement qui devenaient de plus en plus dépendantes des logiciels.

Vient ensuite « The Agile Manifesto » qui consacre les 12 principes du développement logiciel agile.

L’autre ouvrage faisant autorité sur les méthodologies de développement logiciel est attribué à Mary et Tom Poppendieck, qui ont publié Lean Software Development : An Agile Toolkit.

Voici une comparaison côte à côte des valeurs et des principes de chacun d’entre eux :

En comparant les 12 principes du LSD du Dr Charette et les 12 principes d’Agile, vous pouvez constater qu’ils sont étonnamment similaires. Les sept principes Lean proposés par les Poppendieck sont moins ciblés, mais se recoupent néanmoins avec « The Agile Manifesto » et le Lean Software Development de Charette.

Voici d’autres éléments qu’ils ont en commun :

• L’intérêt de répondre rapidement aux besoins des clients
• Des tests précoces
• Une approche itérative du développement
• Un style de développement MVP (Minimum Viable Product) plutôt qu’un développement lourd en fonctionnalités
• Coopération à la fois au sein de l’entreprise et avec les parties prenantes externes

La chronologie

Nous avons enquêté sur les événements marquants et les publications qui ont donné naissance à ces terminologies pour voir comment elles sont devenues populaires. Consultez notre chronologie ci-dessous détaillant la progression, et ajoutez-les à votre liste de lecture si vous en avez envie !

Origines du Lean et de l’Agile

Comme vous pouvez le voir sur la chronologie, le terme Lean a été utilisé pour la première fois par Womack et. al. en 1990 pour décrire le système de production Toyota dans leur livre, The Machine That Changed The World. Le Dr Robert Charette a ensuite adapté les idées Lean décrites dans des publications antérieures pour créer son « Lean Software Development ».

Le terme Agile n’a pas été largement adopté avant la publication de « The Agile Manifesto » en 2001. Les termes Agile et Lean ont tous deux été inventés par des professionnels de la technologie ou des universitaires occidentaux qui se référaient au système de production Toyota (nous y reviendrons plus tard).

Nous pourrions nous attirer des critiques en disant cela, mais en gardant cela à l’esprit, les termes Lean et Agile ne sont en fait pas si importants. Avoir deux termes issus des mêmes principes contribue en fait à la confusion sur le sujet. Cela étant dit, c’est la terminologie que l’industrie a adoptée, donc en allant de l’avant, nous continuerons à les utiliser.

La chronologie est également une autre source de confusion. Le Dr Robert Charette a introduit ses idées sur le développement logiciel allégé au début et au milieu des années 90. L’objectif tactique et les 12 principes de son approche du développement allégé ont été décrits en 1998 dans un article intitulé « Lean Development », près de trois ans avant le « Manifeste Agile. » Témoignant du chevauchement entre Lean et Agile, cet article a été écrit par Jim Highsmith, qui est devenu plus tard l’un des principaux fondateurs du mouvement Agile. Cependant, l’article de Highsmith n’a pas été largement diffusé, et ce n’est qu’en 2003 que Charette lui-même a écrit une explication plus approfondie derrière son approche de développement lean dans le rapport de recherche « Challenging the Fundamental Notions of Software Development. »

Dans un échange de courriels avec le Dr. Charette, il s’est empressé de souligner que sa conception du développement allégé était destinée au niveau organisationnel dans le domaine du logiciel :

La mienne est née d’un besoin stratégique ainsi qu’opérationnel d’améliorer la valeur métier/mission de l’informatique pour l’organisation, et je l’ai abordée dans une perspective de gestion des risques.
-Dr Robert N. Charette

Ceci diffère légèrement d’Agile, qui a d’abord été proposé strictement comme une  » meilleure façon de développer des logiciels « , mais qui est maintenant appliqué à divers projets et méthodes de gestion.

2003 a également été l’année où les Poppendieck ont publié Lean Software Development : An Agile Toolkit. Ce livre détaillait sept principes du développement Lean, ce qui correspond directement aux sept formes de gaspillage dans la fabrication Lean.

Le livre des Poppendieck a simultanément soutenu le Lean en tant que méthodologie de développement logiciel et a brouillé la distinction entre le Lean et l’Agile, en proposant le Lean comme une méthode complémentaire au sein de l’Agile. En fait, au moment de la publication, le livre était vendu comme la dernière publication de la série The Agile Software Development.

Aujourd’hui, les multiples ouvrages des Poppendieck sur le sujet sont considérés comme des lectures essentielles pour les praticiens du développement logiciel Lean, et  » aspirant au Lean « .

Divergence dans l’application

Selon le Dr Charette, l’une des principales différences entre le Lean et l’Agile est que l’Agile est ascendant, tandis que le Lean est descendant. Cela est évident dans la structure de bout en bout (E2E) de Lean et le principe de See the Whole proposé par les Poppendieck. Nous expliquons ci-dessous ces principes à l’œuvre dans la pratique de la cartographie du flux de valeur.

Cartographie du flux de valeur

Pour réaliser le principe de See the Whole, les Poppendiecks détaillent une méthode de cartographie du flux de valeur pour révéler les activités à valeur ajoutée par rapport aux activités sans valeur ajoutée tout au long du processus de développement de bout en bout.

La cartographie du flux de valeur analyse le cycle de développement depuis la réception d’une exigence jusqu’à la livraison au client. L’objectif est d’identifier les gaspillages liés à la présence de stocks et à l’attente (retards dans la production), et d’explorer de nouvelles pratiques pour réduire les travaux en cours (TEC) et les délais.

Selon les Poppendieck, la cartographie de votre chaîne de valeur est un exercice simple qui ne nécessite qu’un crayon et une feuille de papier. Le processus est le suivant :

1. Cartographier votre chaîne de valeur actuelle (en commençant par un besoin et une chronologie des actions sur le chemin de la livraison)
2. Analyser la plus grande cause de gaspillage (Qu’est-ce qui retient les travaux en cours ?)
3. Développer un plan pour réduire ce gaspillage de moitié
4. Créer une future carte de flux de valeur

Le paradigme Agile tel que défini dans « The Agile Manifesto » favorise les cycles d’itération courts et les livraisons fréquentes par rapport à une vue holistique de bout en bout. La focalisation E2E est donc unique au Lean. En fait, c’est en raison de la construction E2E que le Lean (plutôt que l’Agile) est plus souvent appliqué en tant que structure organisationnelle et style de gestion.

La vision de bout en bout nécessite que toute l’organisation y participe afin d’éliminer le gaspillage. Cela fait écho à l’objectif déclaré par le Dr Charette pour son concept original de Lean Development :

Le Lean Development est une philosophie, une façon de voir et de penser l’informatique et sa relation avec une organisation, autant qu’une approche de développement.

Kanban Lean vs. Kanban Agile

Lean et Agile ont tous deux adopté le système Kanban de TPS avec de légères variations. Le système Kanban de Toyota a été conçu pour limiter le Work-in-Progress.

Par opposition à la « fabrication poussée » traditionnelle, qui pousse les stocks à l’étape suivante du processus, Kanban ne tire de nouveaux matériaux dans la production qu’une fois que la pièce actuelle a été traitée et que les composants doivent être réapprovisionnés.

Les cartes Kanban deviennent des ordres de réapprovisionnement et sont renvoyées à l’étape précédente de la production. Par conséquent, les travaux en cours sont minimisés et les stocks inactifs sont réduits.

Dans le développement de logiciels, au lieu de faire passer les cartes Kanban d’une étape de fabrication à la précédente, on utilise un tableau Kanban. Des notes autocollantes sont utilisées, le plus souvent pour représenter les exigences en cours.

Selon le chapitre apporté par Kai Petersen dans Modern Software Engineering Concepts and Practices : Advanced Approaches, Agile et Lean utilisent tous deux une liste d’exigences classées par ordre de priorité pour en tirer des tâches.

Contrairement à Agile, qui utilise des cycles d’itération à durée fixe pour limiter le temps de développement et régir le tableau Kanban, Lean limite le nombre de tâches autorisées à un moment donné. Cela permet au Lean de remplir son objectif principal de limiter le WIP, tout en mesurant plus précisément le délai d’exécution, et en identifiant le gaspillage dans la production. Une fois qu’une tâche est terminée, une nouvelle tâche peut être extraite de la liste des priorités. Alors que Lean utilise le concept de flux continu, Agile commence chaque nouvelle itération avec un nouveau tableau.

Certaines équipes reconnaissent les avantages des deux approches, et commencent à utiliser une méthode hybride connue sous le nom de scrumban.

Ce ne sont là que deux des subtiles différences d’approche entre Lean et Agile pour atteindre des objectifs communs. Un autre article publié sur Codementor explore davantage les utilisations et les applications du Lean et de l’Agile.

En pratique, que votre équipe adopte une approche dite « Agile » ou une approche « Lean » est sans importance. Ce qui importe, c’est de trouver les bonnes pratiques pour optimiser vos flux de travail et fournir constamment de la valeur à vos clients, ce que les deux méthodologies considèrent comme le but ultime.

La connexion TPS

Alors, qu’est-ce que tout cela a à voir avec le système de production Toyota ? À peu près tout. Les créateurs d’Agile et de Lean ont été fortement influencés par le TPS, comme Womack et al. le décrivent dans The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. L’entreprise ne pouvait espérer suivre un modèle de production de masse de Détroit et survivre.

Dans ces conditions, Taiichi Ohno et Kiichiro Toyoda ont entrepris de rester rentables en éliminant les gaspillages dans la production, en réduisant les délais et en ne produisant que ce dont les clients avaient besoin, également connu sous le nom de fabrication juste-à-temps (JAT).

Pour éliminer les gaspillages, Ohno a résolu de ne fabriquer que ce dont on avait besoin, quand on en avait besoin et seulement dans la quantité nécessaire.

Le processus itératif de Lean et Agile qui se concentre sur la minimisation du développement des fonctionnalités, et la maximisation de la livraison des mises à jour reflète directement la fabrication juste-à-temps de Toyota.

Jidoka

Jidoka (自働化) peut être traduit par l’automatisation avec une touche humaine, parfois appelée « automatisation intelligente. » Jidoka joue un rôle majeur dans l’élimination des déchets dans la production en rendant les machines plus indépendantes, ce qui libère les gens pour qu’ils jouent un rôle plus actif dans la production et libère la créativité humaine.

Jidoka s’appuie sur des machines intelligentes qui s’arrêtent automatiquement en cas d’irrégularité. Les travailleurs humains peuvent alors aller régler le problème, empêchant les défauts de se transmettre le long du processus de production.

Jidoka donne également à chaque employé le pouvoir d’arrêter la ligne de production lorsqu’un problème est détecté. Le principe comprend un processus en quatre étapes pour éliminer le gaspillage de produits défectueux :

1. Détecter l’anomalie
2. Arrêter la production
3. Fixer ou corriger la condition immédiate
4. Enquêter sur la cause profonde et remédier à la situation

On peut voir le concept Jidoka dans l’accent Lean et Agile sur les tests précoces et fréquents pour déraciner les bugs, et l’accent mis sur la consultation des clients pour cerner les douleurs des utilisateurs.

Les déchets du TPS dans un contexte de développement logiciel

Pour réaliser la fabrication JAT, Taiichi Ohno a décrit sept formes de déchets à éliminer. Le numéro huit a été ajouté plus tard. Si vous regardez de plus près les valeurs, les objectifs et les principes d’Agile et de Lean, vous pouvez voir qu’ils sont conçus pour se prémunir contre les huit gaspillages du TPS. Dans leur ouvrage de 2003 intitulé Lean Software Development : An Agile Toolkit, les Poppendieck ont présenté les gaspillages du TPS dans un contexte de développement logiciel.

1. Le gaspillage de la surproduction. Le gaspillage de la surproduction est l’une des plus grandes raisons pour lesquelles la méthode Waterfall a été abandonnée. La surproduction est considérée comme du codage supplémentaire pour des fonctionnalités qui n’ont pas été demandées et dont le client ne veut peut-être pas.

Cela se reflète dans les principes suivants :

Agile ⟶ simplicité
Lean⟶ minimalisme
Lean ⟶ des Poppendiecks ⟶ éliminer le gaspillage

2. Le gaspillage de l’attente. Dans la fabrication JAT, attendre une machine ou un travailleur inactif est un gaspillage. Dans le développement de logiciels, le gaspillage consiste à attendre une équipe dont la capacité est excédentaire. S’il y a des retards dans la production qui font qu’une équipe est en attente, ou que le client attend la livraison, il y a du gaspillage.

Les principes correspondants sont les suivants :

Agile ⟶ cycles fréquents
Lean de Charette ⟶ ⅓ du temps (objectif du LSD), 80% de solution aujourd’hui
Lean de Poppendieck⟶ livrer aussi vite que possible

3. Le gaspillage du transport. Dans le développement de logiciels, le transport se traduit par le  » changement de tâche « . Un trop grand nombre de transferts ou d’employés affectés à plusieurs équipes avec une demande de multitâche excessive est inefficace et constitue un gaspillage.

Principes correspondants :

Agile ⟶ collaboration des parties prenantes, équipes auto-organisées, culture de
confiance, de soutien et de motivation
Lean ⟶ de Charette, effort d’équipe
Lean ⟶ de Poppendiecks, responsabilisation de l’équipe

4. Le gaspillage du surtraitement. Il s’agit simplement de processus supplémentaires qui ne sont pas vraiment nécessaires pour apporter de la valeur au client. L’exemple principal est la documentation. Une documentation excessive pour des processus inflexibles n’aura aucune valeur, pas plus que des manuels d’utilisation trop détaillés qui pourraient être résumés en une page ou deux. La documentation prend du temps tout en offrant une valeur limitée à l’utilisateur final.

Principes correspondants :

Agile ⟶ simplicité, logiciel de travail comme mesure
Lean de Charette ⟶ minimalisme
Lean de Poppendiecks ⟶ éliminer le gaspillage

5. Le gaspillage des stocks. Le gaspillage de l’inventaire est un travail en cours pour lequel un investissement a été fait, mais qui ne détient aucune valeur jusqu’à son achèvement. En d’autres termes, un logiciel incomplet n’apporte aucune valeur à l’utilisateur. Lean et Agile valorisent les livraisons rapides et fréquentes, en mettant l’accent sur les cycles itératifs fréquents et la livraison de logiciels fonctionnels.

Principes correspondants :

Agile ⟶ satisfaction du client (par une livraison précoce et fréquente au client
)
Lean ⟶ 80% de solution aujourd’hui
Lean ⟶ livrer aussi vite que possible

6. Le gaspillage de mouvement. Le gaspillage du mouvement est l’excès d’effort nécessaire pour obtenir des informations ou répondre à des questions. Cela est courant lorsque les équipes ne sont pas colocalisées, si les tâches sont achevées et que les résultats ne sont pas immédiatement mis à la disposition de toutes les parties concernées, ou lorsque les parties prenantes ne sont pas facilement disponibles pour être consultées.

Principes correspondants :

Agile ⟶ collaboration des parties prenantes, communication en face à face
Lean de Charette ⟶ participation du client, effort d’équipe
Lean de Poppendiecks ⟶ éliminer le gaspillage

7. Le gaspillage des défauts. Comme dans la fabrication, la production de logiciels défectueux ou bogués représente un investissement gaspillé par l’entreprise. Plus un défaut est détecté rapidement, plus le gaspillage est susceptible d’être atténué. De nombreux principes Agile et Lean cherchent à mettre un terme au gaspillage des défauts. Pour réduire les défauts, les trois méthodologies accordent une grande importance aux tests précoces et fréquents.

Principes correspondants :

Agile ⟶ excellence technique, logiciel de travail comme mesure
Lean de Charette ⟶ satisfaction du client
Lean de Poppendiecks⟶ amplifier l’apprentissage

8. Le gaspillage de la créativité inutilisée des employés. Dans le développement de logiciels, la créativité inutilisée résulte d’une feuille de route rigide et du manque de collaboration humaine. Tout comme Jidoka (自働化), Agile et Lean cherchent à maximiser la coopération humaine et l’innovation pour obtenir les meilleurs résultats de la technologie.

Principes correspondants :

Agile ⟶ collaboration des parties prenantes, réflexion de l’équipe
Lean de Charette ⟶ 13e principe  » non écrit  » de satisfaction par
le travail
Lean de Poppendiecks ⟶ amplifier l’apprentissage

Valeurs TPS dans la méthodologie de développement logiciel

Plusieurs des valeurs fondamentales qui composent TPS se retrouvent également dans les méthodologies de développement logiciel Agile et Lean.

Kaizen (改善) se traduit par l’amélioration continue. Avec des modèles flexibles, itératifs et axés sur le client, l’amélioration continue est peut-être la valeur la plus importante des méthodologies de développement logiciel Agile et Lean.

Hansei (反省) signifie autoréflexion. Comme moyen d’améliorer l’efficacité, le Manifeste Agile adopte directement l’autoréflexion de l’équipe comme son 12e principe. En présentant son modèle de développement allégé, le Dr Charette met les lecteurs au défi de réfléchir à toutes les hypothèses actuelles qui dictent les processus qu’ils utilisent, comme étape initiale pour en trouver de meilleures. Le principe d’apprentissage amplifié des Poppendieck peut également être considéré comme un Hansei.

Le respect des personnes (尊重) est au cœur des trois paradigmes. La première valeur du  » Manifeste Agile  » est de  » valoriser les individus et les interactions plutôt que les processus et les outils. « 

Le respect des personnes apparaît également dans l’affirmation du Dr Charette de l’importance pour les individus d’éprouver de la satisfaction à travers le travail, et dans le principe Lean des Poppendieck de l’autonomisation des équipes. Cette valeur reconnaît que lorsque les individus sont impliqués dans la prise de décision et l’amélioration de leur environnement de travail, ils sont des travailleurs plus innovants et plus efficaces.

Seiri (整理) est le principe qui reflète le gaspillage. Seiri dicte que ce qui est inutile doit être supprimé. Cela englobe les sept gaspillages originaux du TPS, pour lesquels nous avons déjà identifié le gaspillage parallèle dans l’environnement de développement de logiciels.

Gengchi Genbutsu (現地現物) se traduit littéralement par « lieu réel, chose réelle. » En pratique, cela signifie « inspecter pour comprendre ». Lorsqu’il y a un problème dans le processus de production, le gestionnaire doit aller à la source pour comprendre le problème et déterminer comment le résoudre.

Dans le développement de logiciels, cette valeur se manifeste par l’accent mis sur les cycles d’itération courts, les tests précoces et la collaboration avec les clients afin que les ingénieurs logiciels puissent construire des logiciels fonctionnels que les utilisateurs veulent réellement.

Conclusion

Comme nous l’avons mentionné dans les premiers paragraphes de ce billet, la méthodologie Lean est moins bien comprise et est souvent considérée comme une pratique Agile. Le Lean est peut-être moins bien défini simplement en raison de ses applications plus larges.

Le Lean a une relation plus directe avec le système de production Toyota et a d’abord été proposé comme un ensemble organisationnel de méthodes et de pratiques pour la gestion d’entreprise, et seulement plus tard appliqué au développement de logiciels. Agile, en revanche, a été développé spécifiquement pour le développement de logiciels par des professionnels dévoués dans ce domaine.

Après avoir détaillé le contexte commun et les principes généraux de ces deux méthodologies, vous pouvez constater que ces deux paradigmes ont plus de points communs que de différences.

L’un des principaux auteurs du « Manifeste Agile », Martin Fowler, qui a également travaillé en étroite collaboration avec les Poppendieck, a souligné que Lean et Agile ne s’excluent pas mutuellement :

Lean et Agile sont profondément imbriqués dans le monde du logiciel. On ne peut pas vraiment parler d’alternatives…. on ne fait pas de l’Agile ou du Lean, on fait de l’Agile et du Lean.

1. Les 12 principes du Lean Software Development de Charette ont en fait été décrits pour la première fois dans l’article de Jim Highsmith « Lean Development » en 1998. Ils ont ensuite été développés dans le propre article du Dr.Charette « Challenging the Fundamental Notions of Software Development » ︎

.