Du Lean Software Development au Lean IT

le 21/10/2008 par Ismael Hery
Tags: Product & Design

Un effort Lean généralisé à l'ensemble de la DSI permettra d'étendre les succès récents de certaines équipes de développement à toutes les activités IT de la société.
Plus fort qu'une simple dose de LSD (Lean Software Development, le Lean appliqué au développement logiciel), je fais l'hypothèse que nos DSI préféreront bientôt les cures de LIT (Lean IT, le Lean appliqué à toute la DSI).

Des équipes de développement performantes

Nous constatons chez nos clients que les équipes de développement voient leur productivité et la qualité de leurs livrables augmenter considérablement en suivant les pratiques du Lean Software Development (et les pratiques cousines des méthodes agiles).
Le Lean appliqué à ces équipes de développement conduit notamment à une réduction importante de leur temps de cycle (c'est-à-dire le temps entre l'expression d'un besoin par la MOA et la livraison d'un logiciel fonctionnel et déployable par cette équipe de développement).

De nouveaux goulots d'étranglement

Les optimisations menées dans ces équipes de développement font apparaître de nouveaux goulots d'étranglement dans la chaîne de livraison logicielle, au niveau non plus de l'équipe de développement, mais d'autres activités de la DSI :

  • Les équipes de MOA peinent à "nourrir" les équipes de développement au rythme des itérations, maintenant que leur tâches s'intègrent au " flux " de création de logiciel, sans passer par la construction d'un " stock " préalable de spécifications.

  • Du logiciel testé, recetté, packagé, grossit régulièrement un "stock" de versions déployables mais non déployées. Ce stock immatériel s'accumule en amont des équipes d'intégration/exploitation qui ne peuvent tenir la cadence des livraisons des développeurs, habituées qu'elles sont à déployer tous les 6 mois.

Ces difficultés sont des manifestations de goulots d'étranglements qui apparaissent en amont et en aval des équipes de développement. Le diagnostique de la théorie des contraintes est implacable : la vitesse de production de la " chaîne globale " DSI est asservie à la vitesse de son goulot d'étranglement. Rien ne sert de développer plus vite si la DSI ne livre pas plus vite à ses utilisateurs !

Etendre la traduction du Lean en IT

Les principes supérieurs du Lean (zéro défaut, réduction du temps de cycle...) ont été traduits depuis quelques années en pratiques de développement, il s'agit maintenant des les traduire dans la chaîne globale qu'est la DSI, en amont et en aval du développement.
Prenons deux exemples de pratiques issues du principe Lean de polyvalence des opérateurs pour lisser le flux. Ces exemples concernent encore les développeurs, mais avec un objectif de réduction du temps de cycle "DSI" (par le soulagement des goulots) :

  • L'équipe de développement libère de la charge pour se rapprocher des MOA et s'immiscer plus intimement dans le cycle d'expression (écriture à 4 mains de tests de recette...).
  • L'équipe de développement se rapproche des équipes d'intégration pour standardiser les livrables, les procédures de déploiement.

Conclusion

Les exemples de transition du LSD au LIT évoqués concernent encore l'univers " projet " au sein de la DSI. Comme lorsque Toyota étend le Lean de la chaîne de production vers ses autres activités (R&D, marketing...), la DSI aura tout à gagner à suivre un mouvement comparable vers l'ensemble de ses activités (supervision, exploitation, architecture...) afin d'augmenter son ratio global valeur/effort.

De nouvelles traductions des principes Lean sont ainsi à mener pour améliorer l'ensemble de la chaîne de valeur de la DSI. Dans cette démarche, la connaissance des différents terrains de la DSI (les " gemba " du Lean) est indispensable.
Au coeur de cette évolution, le processus d'amélioration continue, mis en place par les développeurs via la répétabilité des itérations, les retrospectives etc, devra trouver des instanciations possibles suivants les autres métiers de la DSI. Par exemple, comment tire-t-on des leçons de schémas d'architecture passés ? Comment décider des voies d'améliorations ? Comment suivre ces améliorations lors des schémas suivants ?