« Développer l’humain avant de développer des logiciels »
Cela pourrait être le nouveau slogan du « Lean IT ». Comme un écho au slogan bien connu du Lean manufacturing : « produire des individus avant de produire des pièces ».
Chez Theodo, une start-up à mi-chemin entre le développement web et le conseil en stratégie, créée par deux Polytechniciens, Benoît Charles-Lavauzelle et Fabrice Bernhard en 2009, on pense Lean, on travaille Lean, on vit Lean.
Basés sur des méthodes Agiles (le scrum en particulier), les projets sont découpés en sprint d’une semaine, les sprints sont découpés en tâches de fonctionnalités à développer en moins d’un jour. Les équipes sont composées de développeurs web, qui réalisent la partie technique, et d’un « scrum master », garant de la bonne application de la méthode, et tous travaillent en constante collaboration avec le client. Chez Theodo, un problème est un écart à un standard, et constitue donc une opportunité pour progresser.
Leur objectif : Diviser par 6 le temps de déploiement classique en repensant le modèle du traditionnel cycle en V, et répondre au mieux aux exigences du client. Et c’est un succès.
Comment cette start-up a-t-elle réussi une telle prouesse ?
Theodo nous a ouvert ses portes, et nous livre tous ses secrets pour une intégration réussie des principes du Lean dans le monde de l’informatique.
Comment ça marche un projet chez Theodo ?
Leurs convictions : supprimer les gaspillages (MUDA en japonais), c’est-à-dire tout ce qui n’apporte pas de valeur au produit.
Benjamin Grandfond, CTO de Theodo, nous livre son point de vue sur les grands MUDA du Lean IT et comment Theodo s’attache à les supprimer :
Le stock
Le stock est le MUDA le plus répandu dans l’informatique. Il faut s’affranchir du côté matériel qu’on entend en manufacturing. Les surstocks en IT sont par exemple un trop grand nombre de fonctionnalités dont le développement est entamé sans être finalisé. Les méthodes Agiles permettent d’éviter les surstocks, en utilisant un scrum board (Tableau divisé en 3 grandes colonnes : les tâches à faire, celles en cours et celles finalisées) en limitant le nombre de fonctionnalités en cours de développement. Cela se traduit par la nécessité de finaliser une fonctionnalité avant de passer à une nouvelle (principe du flux tiré)
La surproduction et l’over-processing
En développement informatique, la surproduction consiste à démarrer le développement de fonctionnalités qui ne sont pas nécessaires immédiatement.
Surprocesser consiste à développer des fonctionnalités qui correspondent à des besoins qui n’ont pas été exprimés par le client. Le cycle en V génère nécessairement du sur-processing. Les méthodes Agiles partent des besoins du moment, et les développements sont réalisés avec l’aide du client qui à tout moment peut être amené à préciser son besoin pour orienter le code. Pour éviter cela, il faut toujours essayer de partir du MVP (minimum viable product) et d’itérer depuis cette base.
Les défauts
Dès qu’une tâche ne suit pas le processus défini par le scrum board (à développer, en cours, test, finalisé), par exemple le test de la fonctionnalité qui échoue, elle est considérée comme un défaut. À Theodo démarre alors une résolution de problème, pour comprendre l’origine de l’erreur et mettre en place un nouveau standard pour que celle-ci ne se reproduise plus. Elle sera bénéfique à d’autres équipes qui pourraient rencontrer à l’avenir ce même problème.
L’attente
Les retards de livraison des fonctionnalités aux clients sont autant de gaspillages de temps d’attente qui génèrent de la non-valeur ajoutée pour le client. En travaillant sous forme de « sprints » de développement d’une semaine, qui donnent naissance à de nouvelles versions toujours plus proches du besoin client final, on limite considérablement ce MUDA.
Les mouvements inutiles
Un développeur web effectue de nombreux allers-retours entre les applications qu’il utilise. Par exemple chez Theodo, on switch entre l’outil pour écrire le code et le navigateur pour vérifier que ce que l’on code fonctionne correctement. Pour supprimer ce gaspillage, il faut effectuer les actions dans le sens inverse : écrire des tests automatisés en premier permet de développer un code bon tout de suite !
Auteur :
Ambre Fischer, Consultante