Le pouvoir des petits lots

Un lot est un groupe d'éléments traités ensemble. En fabrication : des pièces produites lors d'une série. En logiciel : des fonctionnalités regroupées dans une version.

La pensée traditionnelle favorise les gros lots. Si la préparation de la machine prend 30 minutes, fabriquez 100 pièces par série au lieu de 10. Répartissez le coût de préparation sur plus d'unités.

Cette logique s'applique aussi au logiciel : si le déploiement prend 2 heures, regroupez plusieurs fonctionnalités par déploiement. Répartissez les frais généraux sur plus de changements.

Mais ce raisonnement omet des coûts cachés :

Coût d'inventaire : Les gros lots créent un gros inventaire. Les pièces attendent. Les fonctionnalités attendent. Le capital est immobilisé. La rétroaction est retardée.

Coût de qualité : Les défauts dans les gros lots affectent plus d'éléments. Trouver quel changement a causé le bogue est plus difficile dans les grandes versions.

Coût de délai : Les clients attendent plus longtemps. Une fonctionnalité terminée tôt attend que le lot soit complet.

Délai d'apprentissage : Vous n'apprenez pas de la réaction des clients avant que tout le lot soit livré. Des mois de travail pourraient être dans la mauvaise direction.

Le coût total des gros lots dépasse souvent le coût de préparation économisé.

L'idée clé : si vous réduisez les coûts de transaction (préparation), les petits lots deviennent économiques.

Le SMED (Single-Minute Exchange of Dies) de Toyota a réduit le changement de machine de plusieurs heures à quelques minutes. Une fois le changement peu coûteux, les petits lots avaient du sens. L'usine pouvait fabriquer ce qui était nécessaire, quand c'était nécessaire, en n'importe quelle quantité.

En logiciel, le « changement » inclut :

• Le temps de compilation
• La durée de la suite de tests
• La complexité du déploiement
• Les frais généraux du processus de révision
• La coordination des versions

Chacun de ces éléments est réductible :

• Compilations rapides : Compilation incrémentale, mise en cache, bases de code plus petites
• Tests rapides : Tests parallèles, sélection intelligente des tests, tests unitaires plus rapides
• Déploiements faciles : Pipelines CI/CD, infrastructure en tant que code, indicateurs de fonctionnalités
• Révisions légères : Programmation en binôme, petites PR, développement basé sur le tronc
• Aucune coordination de version : Le déploiement continu élimine le concept

Lorsque les coûts de transaction approchent zéro, la taille du lot peut approcher un. C'est le flux pièce par pièce : chaque changement va en production individuellement.

Lorsque vous atteignez de petits lots, tout s'améliore :

Rétroaction plus rapide : Les fonctionnalités atteignent les utilisateurs rapidement. Vous apprenez ce qui fonctionne. Vous pouvez pivoter.

Débogage plus facile : Lorsqu'un petit changement cause un problème, la cause est évidente. Le retour en arrière est simple.

Risque réduit : Chaque déploiement est un petit changement. Le rayon d'impact d'un bogue est limité.

Meilleur flux : Les petits lots traversent le système plus rapidement. Le délai de livraison diminue.

Moins d'inventaire : Pas de grandes piles de travail en attente d'être publiées. Le capital n'est pas immobilisé.

Qualité supérieure : Les petits changements sont plus faciles à réviser. Les défauts sont détectés plus tôt.

Plus de flexibilité : Vous pouvez reprioriser rapidement. Vous n'êtes pas enfermé dans une grande version.

Moral de l'équipe : Livrer fréquemment est plus gratifiant que d'attendre des mois pour une grande version.

L'expression ultime est le déploiement continu : chaque changement va en production quand il est prêt. C'est le flux pièce par pièce pour le logiciel. Pas de regroupement, pas d'attente, pas de coordination de versions.

Si le déploiement continu semble impossible, demandez-vous : quels coûts de transaction devraient diminuer ? Ensuite, travaillez à les réduire.