Temps de lecture moyen : 4 mn

Chez Captive, nous avons décidé de partager avec vous chaque semaine les enseignements que nous tirons du Lean dans notre activité quotidienne d'agence de développement.

La semaine dernière, nous avions abordé le premier principe : Penser sur le long terme. Cette semaine, nous allons présenter le pièce à pièce ou aussi appelé le One piece flow, ou comment la méthodologie Lean peut aider les organisations à gagner en fluidité et productivité. 

Nous allons tout d'abord chercher à comprendre ce que cela signifie dans le secteur de l'industrie d'où est originaire le Lean, et essayer de faire un parallèle chez Captive dans la tech.

1. Comment le Lean améliore la production dans l'industrie, grâce au One Piece Flow

Dans l'industrie, une croyance a longtemps perduré selon laquelle il fallait des machines sans cesse plus grosses pour augmenter la production. En réalité il n'en est rien, la production par lot génère tout un tas de problème (pièces défectueuses, problèmes de stockage, problèmes de transport, etc)

L'exemple le plus frappant que l'on m'ait raconté est celui d'une entreprise qui s'était engagé dans une dynamique d'achat de four sans cesse plus gros pour augmenter sa productivité. 

Lorsqu'ils se sont rendu compte que cela augmentait le nombre de rebuts à cause des différences de température à l'intérieur du four, ils ont alors complètement changé de stratégie : acheter des petits fours en plusieurs exemplaires afin de cuire 1 pièce par four.

Bien que cela soit apparemment contre-intuitif, les gains sont importants :

  • Chaque pièce est sans défaut car produite à l'identique, dans les même conditions
  • Le fait de produire pièce par pièce permet d'adopter un rythme lisse de production  : 1 pièce toutes les X minutes, plutôt que X pièces tous les X minutes.
  • Le fait de ne pas changer de modèle de four permet de stabiliser la connaissance des équipes : sur le fonctionnement du four, sur la maintenance, etc.
  • En terme d'économie d'énergie/ressource, il suffit d'éteindre les fours dont on ne se sert pas lorsque la production est réduite
Le one piece flow dans la tech

Cet exemple résume bien selon moi la pensée en flux qui en mettant associant les deux concepts :

  • Flow : on doit toujours raisonner en terme de flux continu de valeur. Chaque personne est à la fois client et fournisseur d'une autre personne. On cherche par ailleurs à éviter autant les lots que les interruptions de production. 
  • One piece : on cherche à traiter chaque pièce à produire indépendamment. Le Lean va inciter en quelques sortes à adopter une mentalité d'artisan plutôt qu'industriel "à l'ancienne". 

2. Le Lean, un outil pour développer de meilleures applications grâce au One Piece Flow

Maintenant qu'on a mieux compris comment le principe du One Piece Flow contribue à améliorer les process et limiter les défauts dans le secteur de l'industrie, comment peut-il être utilisé dans le secteur des nouvelles technologies, et en particulier appliqué à notre métier d'agence de développement? 

La première question épineuse est "qu'est-ce qu'une pièce ?". N'essayez pas d'appeler votre papy collectionneur, il ne vous sera d'aucune aide sur le sujet...

Dans la tech, nous manipulons du code et des données, cela semble à priori plus compliqué de faire le parallèle... Et pourtant, c'est un avantage ! Chaque entreprise tech peut choisir son niveau de granularité : un commit ? une Pull Request ? Une Release ? Ces possibilités sont toutes valides du moment que cette unité :

  • est connues et comprises de tous : client, développeurs, product managers, etc
  • est suffisamment petite pour être mesurée en terme de qualité et de temps de production (Lead Time) 

Chez Captive nous appelons une pièce "User Story", elle équivaut au "plus petit découpage de valeur pour un client". Elle est le plus souvent caractérisée par une Pull Request dans le dépôt Git du projet et est "commandée" à l'équipe tech par une carte Trello.

Le one piece flow dans le développement informatique

En appliquant les principes du One Piece Flow, voici les règles que nous appliquons quotidiennement :

  • Un développeur ne peut pas travailler sur plusieurs Pull Request à la fois
  • Un développeur doit aller jusqu'à la mise en production avant de pouvoir travailler sur une autre pièce
  • Plusieurs fonctionnalités ne devraient pas être mises en production en même temps

Les bénéfices que nous avons pu observé avec cette approche :

  • En cas de régression, on comprend mieux quel changement a causé le bug
  • En ne faisant pas de lot avec d'autres fonctionnalités, en cas de défaillance, la mise en production d'une fonctionnalité ne bloque jamais celle des autres.
  • Lorsque le flux est constant, le Product Owner arrive mieux à valider fonctionnellement les pièces une à une.
  • Le client est rassuré car il voit de la valeur arriver régulièrement.

Livrer plus de valeur et moins de défauts pour les logiciels et applications que nous développons

Encore une fois, la pensée par flux semble une chose logique mais elle implique sur le terrain une agilité d'esprit et de conception produit importante.

On vient alors à se poser des questions importantes en tant qu'équipe :

  • A partir d'un besoin compliqué, comment peut-on découper le travail en sous-problèmes et ainsi livrer régulièrement des choses démontrables ?
  • Comment concevoir une solution technique certes imparfaite mais qui a de l'impact rapidement, et qui sera améliorable par la suite ?
  • Comment expliquer ces choix au client qui n'est ni Product Manager, ni Développeur ?

Certaines méthodologies comme SCRUM ont montré la voie afin de montrer de la valeur régulièrement au client. Cependant beaucoup d'équipes qui la pratique ont tendance à produire beaucoup de fonctionnalités simultanément en début de sprint, puis une grosse mise en production en fin de sprint, qui se solde souvent par des bugs à corriger au sprint suivant. Les équipes sont alors en échec perpétuel, car elles doivent à la fois corriger les problèmes accumulés et essayer de livrer le sprint courant.

C'est la raison pour laquelle le one piece flow est une réponse pertinente pour nous en tant qu'agence de développement.  En mettant en production chaque fonctionnalité dès qu'elle est prête, nous pouvons à la fois traiter plus facilement les erreurs et produire plus de valeur quotidienne à nos clients. Ce qui pousse les équipes à produire le plus de pièce possible, le plus régulièrement possible. 

Construire un produit, logiciel ou application, est une course de fond et non un sprint.  Lean au travers du principe du One Piece Flow nous aide à maintenir le bon rythme pour les clients et les équipes. 

{{cta('e409457e-2ef8-4cc6-9e72-f729c8e8036f','justifycenter')}}