Open Agile

J’ai évoqué plusieurs fois la méthode Lean Software Development, j’avais envie de vous la présenter cette technique pour mieux expliquer son but. Mais avant d’aller plus loin, commençons par les origines de la lean Thinging, cela nous permettra de comprendre la cible attendue par cette technique.

Dans les années 40, une petite société nommée Toyota avait l’intention de fabriquer des voitures au Japon. Mais il avait un problème. Puisque les gens n’avaient pas d’argent, les voitures devaient être bon marché. La production de masse était le moyen le moins cher de faire des voitures, mais la production de masse destinée à fabriquer des milliers de voitures du même type, et le marché japonais n’était tout simplement pas compatible, le marché était trop petit pour toutes ses voitures. Donc la question a été, comment Toyota pourrait faire des voitures en petites quantités tout en restant bon marché ?

De ce dilemme, le Toyota Production System a émergé pour former la base d’une toute nouvelle façon de penser la fabrication, la logistique, et finalement le développement produit. Le cerveau derrière cette nouvelle façon de penser était Taiichi Ohno, connu comme le père du Toyota Production System. Au cœur de la réflexion d’Ohno, il y a le principe fondamental de la lean thinging: éliminer les déchets.

Voir les déchets :

Apprendre à voir des déchets est la première étape dans le développement de la Lean Thinking. Si quelque chose n’apporte pas directement une valeur ajoutée telle qu’elle est perçue par le client, il constitue un déchet.

Shigeo Shingo, l’un des cerveaux de la Toyota Production System, a identifié sept types de déchets de fabrication. Sa liste a permis à de nombreux chef de fabrication de trouver les déchets où ils n’auraient jamais pensé à regarder. Pour faciliter le travail des responsables de projet de développement logiciels dans leur quête de trouver les déchets, la Lean Software Development à traduit les sept déchets de l’industrie manufacturière dans sept des déchets du développement qui sont :

* Travail partiellement terminé
* Processus complémentaire sans valeur ajoutée
* Caractéristiques supplémentaires sans valeur pour le produit
* Permutation de tâches
* Attente (entre deux tâches par exemple)
* Le mouvement (Aller quelque part pour rencontrer quelqu’un ou aller chercher quelque chose pour obtenir des informations)
* Les défauts, imperfection.

En complément de l’étude des déchets, il existe 6 autres grands domaines :

* Amplification de l’apprentissage par rétroaction. La meilleure approche pour améliorer un environnement de développement logiciel est d’amplifier l’apprentissage. L’accumulation de défauts doit être empêchée en réalisant des tests aussitôt que le code est écrit. Le processus d’étude est accéléré par l’utilisation de cycles itératifs courts.

* Décider le plus tard possible : L’idée est d’attendre ce que les auteurs de ce terme définissent comme « le dernier moment responsable » pour prendre une décision. C’est le moment où, si l’équipe ne prend pas de décision, la décision sera prise pour eux (ne rien faire est un choix). Les avantages en sont d’éviter ou de retarder les coûts du changement.

* Livrer le plus vite possible : C’est la base du développement itératif. Le pourcentage des exigences change des exigences originales de manières non linéairement et ceci plus le temps avance. Typiquement dans les projets de 9-12 mois il y a un changement de 25% (grossièrement) des exigences initiales. Cependant, le cout des exigences augmente par mois de seulement 1 à 2 %.

* Responsabiliser l’équipe : la qualité de l’équipe de développement est le facteur le plus important dans la réussite des projets. Afin d’amener les gens à assumer leur responsabilité, qu’ils soient motivés, et se voient comme une équipe, ils doivent être responsables des résultats et autorisés à en faire une réalité.

* Construire à l’intégrité – à la fois l’intégrité conceptuelle, et la perception de l’intégrité. Les auteurs font la distinction entre perceptions de l’intégrité et l’intégrité conceptuelle. La perception de l’intégrité est l’expérience du client avec votre logiciel. L’intégrité conceptuelle est de savoir comment bien construire de concert l’architecture et les composants du système pour aboutir à la perception d’intégrité. De toute évidence, les tests unitaires et d’intégration sont une partie importante de l’intégrité.

* Avoir une vision d’ensemble : il faut regarder les processus d’abord dans une vue d’ensemble ou de manière holistique, car si vous ne le faites pas, vous pouvez vous retrouver avec des sous-systèmes optimisés ou fragmentés et des solutions qui ne tiennent pas compte de l’ensemble du processus. La résolution habituelle à la résolution des problèmes est de les subdiviser en éléments constitutifs et d’optimiser chaque pièce. C’est suboptimisation, conduite à la «tragédie des biens communs. »

Le secret derrière Lean cela réside dans l’élimination des goulets d’étranglement dans les processus de développement sous-jacents et le renforcement de la rétroaction du cycle.

Un rapport menée par McKinsey baptisé «  »Applying Lean To Application Development And Maintenance,», explique que cette technique peut conduire à des gains de productivité de 20% et 40%, et que la qualité et la rapidité d’exécution peuvent s »améliorer sensiblement en l’espace de quelques mois. (Boost productivity with lean software development)

Évidemment cette article donne une vu très générale de cette méthode, si vous souhaitez approfondir votre connaissance de ce sujet, je vous recommande fortement l’ouvrage : Lean Software Development: An Agile Toolkit qui est l’ouvrage de référence.