Théorie des goulots d'étranglement

Dans les années 1980, Eli Goldratt a développé la théorie des contraintes (TOC). L'idée centrale est simple mais profonde :

Chaque système a une contrainte—une étape qui limite le débit de l'ensemble.

Pensez à une autoroute : si un tronçon est congestionné, toute l'autoroute ralentit. Élargir les tronçons dégagés n'aide pas. Il faut régler le tronçon congestionné.

Le même principe s'applique aux chaînes de valeur. Si la révision de code est le goulot d'étranglement, accélérer le développement ne fait que créer une pile plus grosse à la révision de code. Si les tests sont la contrainte, embaucher plus de développeurs signifie simplement plus de travail en attente pour l'AQ.

Le système ne peut avancer qu'à la vitesse de sa contrainte la plus lente.

Cela a des implications puissantes pour l'amélioration : améliorer ce qui n'est pas la contrainte est du théâtre. Ça peut sembler productif mais n'a aucun effet sur le débit global.

Comment trouver la contrainte ? Cherchez où l'inventaire (le travail) s'accumule.

La contrainte a une pile de travail en attente devant elle. Si la révision de code a toujours un arriéré, la révision de code est probablement la contrainte. Si les tests ont des semaines de travail en file d'attente, les tests sont probablement la contrainte.

Autres signes de contraintes :

• Utilisation élevée : La contrainte est saturée
• Pression constante : Les personnes à l'étape de la contrainte sont toujours pressées
• Famine en aval : Les étapes après la contrainte attendent du travail
• Frustration en amont : « On a fini, pourquoi ça n'avance pas ? »

Contraintes logicielles courantes :

• Révision de code (trop peu de réviseurs, grandes PR)
• Tests (AQ manuelle, couverture de tests limitée)
• Déploiement (versions complexes, fenêtres de déploiement limitées)
• Décisions d'architecture (attente de l'architecte)
• Décisions produit (attente du propriétaire de produit)

Remarque : la contrainte n'est souvent pas une étape « productive ». Ce peut être un décideur. Ce peut être un processus d'approbation. Ce peut être une ressource partagée.

La TOC prescrit un processus en cinq étapes :

1. Identifier la contrainte : Trouvez où le travail s'accumule.

2. Exploiter la contrainte : Maximisez le débit à travers la contrainte sans ajouter de ressources. Si la révision de code est la contrainte, priorisez les révisions plutôt que le nouveau développement. Assurez-vous que les réviseurs ne sont pas distraits. Réduisez la taille des PR pour que les révisions aillent plus vite.

3. Subordonner tout le reste : Les non-contraintes doivent servir la contrainte. Si l'AQ est la contrainte, ne poussez pas plus de travail vers l'AQ—ajustez le rythme du développement à la capacité de l'AQ.

4. Élever la contrainte : Si l'exploitation et la subordination ne suffisent pas, ajoutez de la capacité à la contrainte. Formez plus de réviseurs. Automatisez les tests. Embauchez plus de personnes ayant la compétence contrainte.

5. Répéter : Une fois que vous brisez une contrainte, une autre émerge. La contrainte se déplace. Trouvez-la et répétez.

C'est une amélioration itérative et continue. Vous êtes toujours concentré sur la contrainte actuelle, pas dispersé sur toutes les étapes.

La métaphore tambour-tampon-corde : La contrainte est le « tambour » qui donne le rythme. Le travail avant la contrainte est le « tampon ». La « corde » tire le travail dans le système au rythme que la contrainte peut gérer—pas plus vite.