Lean Software Developement est une nouvelle approche qui vise à éliminer les déchets. Inspirée par l'industrie automobile, et notamment Toyota qui a révolutionné les principes d'organisation pour produire des automobiles moins cher, il est aujourd'*** en voie d'être généralisé et en particulier d'être appliqué à l'industrie informatique. Le Lean Software Developpement a été initiée par Mary et Tom Poppendick qui ont publié un livre du même nom en 2003.
De ce que j'ai pu lire pour le moment, (ici, là ou là), je dois reconnaitre que notre approche s'accorde parfaitement à l'esprit de ce qui est proposé.
Les 7 piliers du LSD sont les suivants:
1/ Eliminer les déchets
A la manière d'un industriel, qui voit dans les déchets, une perte de temps et de productivité (un déchet coute à être produit, stocké, éliminé, et n'apporte pas de valeurs à la production industrielle), il est de bon sens d'éliminer les déchets du projet. C'est exactement la démarche que nous visons en éliminant plus de 95% du code habituellement nécessaire. Tout code inutile constitue un déchet potentiel, et la majorité du code technique est inutile, parce que toujours le même.
2/ Favoriser l'apprentissage
Le développement d'une Application est un apprentissage permanent. Apprentissage du métier, apprentissage du comportement des utilisateurs, apprentissage des contraintes et des risques, tout doit être fait pour favoriser les échanges et anticiper les attentes. C'est en fonction de ce que l'on a fait que l'on va pouvoir évoluer.
Avec une application qui fonctionne dès le premier jour, l'équipe est confrontée dès le début du projet à l'apprentissage du métier. C'est parce qu'il y a des allers et retours constants entre l'équipe technique et l'équipe fonctionnelle, sur la base d'un flux continu de développement et d'une application qui marche en permanence, que l'apprentissage est favorisé.
3/
Décider le plus tard possible
Prendre les décisions le plus tard possible, est la façon la plus sure de ne pas se tromper, et de minimiser le cout d'un changement par la suite. Cette philosophie nous accompagne depuis le premier jour. Dans la vision de notre produit, le découplage des pièces permet de retarder les décisions car moins il y a de dépendances pièces, plus on est libre de faire des choix indépendant pour chaque pièce. De plus, cette philosophie est omniprésente dans l'écriture de notre code. Notre approche dynamique permet de décider le plus tard possible de ce que le code doit faire.
4/ Livrer le plus rapidement possible
Plus la livraison est rapide, plus elle est testée tôt, plus le risque d'erreurs est limité. En favorisant un logiciel qui fonctionne dès le premier jour et en permanence, nous encourageons la livraison continue, donc rapide.
5/ Responsabiliser l'équipe
La qualité d'une application est directement liée à la qualité de l'équipe qui la réalise. Plus le développeur est concerné par les fonctionnalités métiers, plus il est proche de la valeur attendue et produite, plus il est motivé pour avancer, et plus il se sent responsable. En éliminant le code technique (qui est le plus souvent dépourvu d'intelligence), nous favorisons le rapprochement entre le développeur et l'utilisateur, et responsabilisons d'autant mieux le développeur.
6/
Construire l'intégrité du SystèmeEn découplant les différentes pièces, et en éliminant le code technique inutile, et parce que l'Architecture du Système est déjà en place, il est plus facile de voir et de comprendre l'intégrité du Système. Enfin, l'intégrité du Système est également mieux perçue avec le feedback utilisateur.
7/ Avoir une vue d'ensemble
Parce que le volume de code est extrêmement faible, l'équipe peut avoir une vue d'ensemble sur un périmètre beaucoup plus vaste que d'habitude. De plus, notre DSL graphique aide à visualiser le modèle de l'application, et participe à la vue d'ensemble.
Le LSD est encore en phase émergente; il se distingue des méthodes agiles traditionnelles, parce qu'il est moins contraignant, et est peut être plus pluridisciplinaire. Là où le Scrum ou le XP vous dira précisément ce que vous devez faire pour être agile (par exemple Stand-up meeting, TDD), le Lean vous donnera les bases pour vous poser les bonnes questions, adapter votre façon de faire à l'esprit, et vous invitera à apprendre. En quelque sorte, le Lean est plus une philosophie qu'une méthode. Autre différence notable, le Lean n'interdit pas les héros, et n'est pas antinomique ni avec un Management fort, ni avec des spécialistes.
Le Lean a tout pour séduire, il a fait ses preuves dans l'industrie, et nous sommes en phase avec cette philosophie. Bien sur, mettre en place une démarche Lean requiert des changements dans l'organisation et le management et même un véritable changement de culture. L'usage d'outils adaptés n'apparait comme secondaire, mais il est extrêmement intéressant de découvrir une démarche qui est très complémentaire avec notre approche. Notre architecture permet la réalisation de projets avec un esprit Lean, et nous allons suivre cela d'un peu plus près.