L’art du Lean Software Development

Ayant eu entre les mains le livre ci-contre écrit par des personnes de Boeing Curt Hibbs, Steve Jewett, Mike Sullivan, j’avoue être un peu perplexe concernant la cible Lean de ce livre.

Ce livre est plus à voir comme un guide de bonnes pratiques de développement logiciel englobant certains sujets Lean plutôt qu’une illustration de ce que devrait être une approche 100% lean.

Par exemple un chapitre entier est dédié à la présentation des outils de gestion de la configuration du code source tel que Clearcase, SVN ou GIT, et un autre au différents types de tests unitaires, intégration, fonctionnels. Ce sont deux aspects du logiciel qui existent que l’on applique Lean ou non.

Enfin il manque parfois d’explications sur le sens et le lien entre l’activité de développement préconisée et l’objectif Lean lié à atteindre. Une personne aguerrie au Lean pourra combler les pointillés, mais c’est dommage pour un livre qui se veut un guide au développement logiciel Lean.

Le lecteur débutant pourra être perdu entre les préconisations venant spécifiquement de la philosophie Lean et celles des préconisation purement issues du génie logiciel ou d’autres méthode comme les méthodes Agile.

Organisation du Livre

Le livre est organisé avec les parties suivantes:

1. Présentation du cycle en V, puis les méthodes Agile, et enfin la philosophie Lean que les auteurs résument par:
   • Eliminer le gaspillage
   • Contruire la qualité intrinsèque
   • Favoriser le transfert de la connaissance (entre les personnes)
   • Retarder la décision (jusqu’au moment où c’est réellement nécessaire)
   • Livrer rapidement (limiter le temps entre la commande du client et son paiement)
   • Respecter les personnes (c’est à dire les aider à progresser pour optimiser la qualité)
   • Optimiser le système dans son ensemble

   (J’ai rajouté entre parenthèses la raison de chacune des demandes du Lean qui ne sont pas forcement bien explicitées dans le livre)

2. Gestion du code source en configuration et outils de création automatiques du code
   L’intérêt de la gestion du code source en configuration est de pouvoir enregistrer les itérations et de rapidement revenir en arrière si nécessaire, d’identifier les modifications apportées à une version donnée, et d’identifier aussi qui a fait les modifications parmi l’équipe.
   L’intérêt d’avoir un script de création du code source est de pouvoir reproduire à l’identique une livraison logicielle et donc de limiter la variabilité.
3. Tests automatiques
   L’intérêt d’automatiser les tests est de permettre de les rejouer rapidement et sans coût excessif après chaque modification du code. En effet il est primordial d’identifier une erreur au plus près de son introduction, le coût de la correction augmentant au fur à mesure que le temps s’écoule, du fait de:
   • L’ajout de nouvelles fonctionnalités qui vont complexifier la correction.
   • La perte de la connaissance du code par le développeur qui a fait la modification.
   • Le potentiel retro-portage de la correction dans des versions déjà livrées et re-livraisons.

   Le chapitre présente les différents types de tests possibles: unitaires, intégration, fonctionnels, avec les bases de données, etc…

4. Intégration continue
   Il s’agit là aussi d’une technique logicielle non spécifiquement Lean mais permettant d’automatiser la fabrication du logiciel. Souvent l’intégration continue se déclenche automatiquement lorsque un source est livré dans le système de gestion de configuration, puis le lancement des tests automatiques est lui aussi lancé de façon automatique une fois le logiciel fabriqué pour vérifier qu’il n’y a pas de régression.
   Il est même possible d’avertir de façon automatique les développeurs en cas de problème (par mail par exemple)
   L’avantage d’avoir une procédure d’intégration continue permet de limiter la variabilité dans le processus de fabrication et de test, ainsi que de limiter le temps entre l’introduction et la découverte d’un problème de regression dans le code.
   Le livre présente les différents outils existants permettant de faire de l’intégration continue tant propriétaires que open source à l’heure de la rédaction du livre (certains me paraissent ancien), mais aussi les différentes façon de la mettre en oeuvre avec une machine dédiée ou partagée et les avantages de chaque approche.
5. Développer moins de code
   Dans ce chapitre les auteurs tentent de convaincre de limiter le code source, en utilisant différentes méthodes plus ou moins convainquantes.
   Par exemple s’il est évident qu’il est primordial de réfactorer et factoriser le code régulièrement pour éliminer le code mort ou le code en doublon et avoir toujours l’architecture la plus simple possible (mais pas plus), je suis moins convaincu par la demande qui est faite de réutiliser forcement du code existant et de devoir justifier tout nouveau code.
   J’imagine aisement que s’il est nécessaire de justifier de façon formelle tout nouveau code, les développeurs seront tentés de réutiliser du code existant non prévu pour et de le tordre pour qu’il puisse correspondre au nouveau besoin, introduisant une complexité supplémentaire et donc une moindre robustesse du code.
   Ce chapitre introduit aussi le développement en itérations courtes permettant de limiter la portée des modifications à chaque itération (comme avec Agile Scrum) et l’utilisation de standard logiciels (design patterns, règles de codages, etc…)
6. Impliquer le client tout au long du développement
   Je pense qu’il s’agit là plus d’une demande Agile que spécifiquement Lean. En Lean on demande à toujours fournir au client la qualité maximale possible, et pour cela il faut bien le connaitre et voir comment il utilise le produit, mais je ne pense pas qu’on lui demande son implication pendant tout le développement.
   Par exemple Toyota ne demande pas à ses clients de venir superviser la fabrication de leur voiture à toutes les étapes. Seule l’utilisation de la voiture (complètement finie) par le client est étudiée.
   De même la demande de création d’un représentant du client, qui s’apparente au Product Owner en Agile n’est pas vraiment Lean
7. Et ensuite ?
   Ce dernier chapitre est une sorte de fourre-tout contenant quelques autres éléments de la philosophie Lean qui n’ont pas été traités dans les chapitre précédents comme:
   • la recherche racine des problèmes afin d’identifier la vrai cause profonde d’un dysfonctionnement et ne pas survoler le problèmes,
   • la cartographie du flux de valeur afin d’identifier toutes les phases du processus de fabrication qui n’apporte pas de valeur au produit pour le client et qui pourrait être potentiellement supprimée car gaspillage.
   • les ateliers Kaizen pour définir les moyens à mettre en oeuvre des corrections de plus grande ampleur.

   Ou encore d’autres méthodes plus ou moins éloignées de Lean comme:

   • Six Sigma (pour définir des métriques de mesure)
   • CMMI (Capabilité Maturity Model Integration) qui est une autre méthode d’amélioration des processus et des entreprises
   • Théorie des contraintes (théorie permettant d’identifer les points prioritaires à améliorer)

    

Conclusion:

Comme indiqué en introduction, si vous cherchez une approche vraiment Lean au développement logiciel ce livre n’est sans doute pas le plus approprié, il manque pas mal de points Lean non traités comme la limitation du WIP (Work In Progress), le Kanban, l’utilisation de fiche A3 pour la résolution de problèmes, etc….

Néanmoins si vous débutez dans le développement logiciel et cherchez un livre pragmatique vous donnant des exemples concrets de la mise en oeuvre d’une production logicielle s’orientant vers la philosophie Lean ce livre est une bonne introduction mais qu’il faudra compléter par exemple par Kanban pour l’IT, La Pratique du Lean management dans l’IT ou encore Lean Software Development: An Agile Toolkit  (que je n’ai pas encore lu mais dont on m’a dit le plus grand bien)