Méthode AGILE LSD – Explication

Oui, vous avez bien lu, ici le LSD n’est pas une drogue ! La méthode agile LSD, c’est simplement une méthodologie de gestion de projet dérivée des usines automobiles en vue d’être appliquée à des processus de développement informatique.

Mais au final qu’est ce que le Lean Software Development ? C’est une méthodologie de gestion de projet qui vise principalement à réduire le gaspillage des ressources dans la gestion d’un projet IT.

Toyota en a développé les grands principes au travers de son Toyota Production System (TPS) dans les années 50. Son succès est tel qu’il sort des usines pour s’étendre à d’autres secteurs que l’automobile pour finir par atteindre le monde de l’informatique sous l’impulsion de Mary et Tom Poppendieck.

Les 7 principes fondamentaux de la méthode agile LSD

Cette méthodologie repose sur 7 principes fondamentaux :

  • Éliminer les sources de gaspillages
  • Intégrer la qualité dès la conception
  • Créer des connaissances
  • Reporter la décision
  • Livrer le plus vite possible
  • Respecter les autres
  • Optimiser le système dans son ensemble

Éliminer les sources de gaspillages

On le sait tous : « Tout ce qui n’a pas de valeur ajoutée doit être soit éliminé soit automatisé ». De ce fait, les principes de Lean défini par Toyota ont défini 7 gaspillages (surproduction, Transports inutiles, stocks, déplacement, défauts, sur-traitement, attente). Tom et Mary ont adapté ces gaspillages aux développements, et on peut identifier :

  • Code inutile: « Ne développer que le strict nécessaire »
  • Lancement d’un nombre excessif de tâches: « Trop de tâche tue les tâches. Il faut limiter le nombre de tâche a effectué, cela réduit la complexité du système et supprime quelques obstacles dans le flux »
  • Retard dans le développement: « Il faut identifier le plus tôt possible toutes difficultés de développement (manque de dev, tâche trop complexe, difficulté technique …) »
  • Changement constant de fonctionnalité ou de tâche : « Il faut éviter de retravailler sur des fonctionnalités déjà mis en place, défaire ou modifier une fonctionnalité développée et testée, est du temps de perdu. »
  • Prise de décision politique : « La bureaucratie retarde les développements. Toutes les décisions doivent être prises en amont du sprint de développement ».
  • Pas ou peu de communication : « Améliorer votre communication, vous améliorerez votre efficacité ! »
  • Travail inachevé : « Il faut terminer chaque tâche, chaque développement avant d’attaquer un autre chantier. »
  • Défauts et qualité médiocre : « Chaque tâche doit être effectuée dans une certaine qualité, cela diminuera le nombre de tâches à retravailler et augmentera la satisfaction du client »

Intégrer la qualité dès la conception

La qualité de la conception ne rime pas avec la quantité de tests unitaires ou de commentaires. Beaucoup créent des gaspillages sans forcement sans rendre compte (nombreux tests, commentaires surfait, TODO à ralonge, etc.)

Afin de se prémunir au maximum de ces défauts de conception voici quelques idées à mettre en place :

  • Automatiser les processus manuels (propices aux erreurs humaines)
  • Pair programming (programmation en binôme)
  • Développement piloté par les tests

Créer des connaissances

Afin de ne pas reproduire les erreurs des autres, et afin que les leçons servent à tout le monde, il est primordial de créer une base de connaissance en utilisant une combinaison d’outils comme :

  • Pair programming
  • Documentation
  • Base de connaissance (Wiki …)
  • Réunion de partage de connaissance
  • Formation

Reporter la décision

Cela peut paraître absurde, mais il faut prendre son temps. Il faut prendre le temps d’avoir toutes les données en main afin de prendre la meilleure décision.

Il faut donc :

  • Planifier le juste nécessaire
  • Prendre le temps de recueillir toutes les données d’un projet avant de partir
  • Ne pas partir tête baisser sans comprendre l’étendu du projet.

Livrer le plus vite possible

Le plus vite possible ne signifie pas n’importe comment au nom de la rapidité. Pour livrer vite, il ne faut pas accélérerce qui ne peut pas l’être, par contre, il faut optimiser ce qui ralentit.

Il faut donc aller vite à l’essentiel, sans essayer d’anticiper toutes les exigences futures, aller vite en résolvant en urgence tous les blocages, etc.

Respecter les autres

Il faut se respecter les uns les autres. Chaque nouvelle personne intégrée à l’équipe doit faire preuve de bienveillance dans le travail qui a été réalisé, il faut communiquer de manière proactive et se donner les moyens de travailler de façon optimale.

Optimiser le système dans son ensemble

Il faut optimiser le code à tout prix. Le développeur sous pression non-consciencieux livrera un code baclé et complexifiera le système. Ce qui engendrera des bugs et des corrections supplémentaires. Cela créera une boucle vicieuse qui peut déboucher à l’abandon du projet ou au dépassement des temps de développement.

Il faut prendre le temps de livrer un code de qualité afin que personne ne revienne dessus à la fin du projet.

Un autre cercle vicieux est le testing. Plus le testeur mettra du temps à tester le système, plus le développeur risque de continuer un développement défectueux.

Ces deux cycles sont ce qu’on appelle la « sous-optimisation » , l’optimisation de l’ensemble du système est le principe qui permettra de faire émerger la valeur du projet. Il faut identifier les flux de valeurs au sein de l’équipe et de l’entreprise et les optimiser.


Voilà, vous savez tout sur la méthode agile LSD ! Lisez aussi notre article sur la méthode agile Crystal en cliquant ici.

Laisser un commentaire

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

Retour en haut