Teoria del Collo di Bottiglia

Negli anni '80, Eli Goldratt sviluppò la Teoria dei Vincoli (TOC). L'intuizione centrale è semplice ma profonda:

Ogni sistema ha un vincolo—un passaggio che limita il throughput dell'intero sistema.

Pensa a un'autostrada: se un tratto è congestionato, l'intera autostrada rallenta. Allargare i tratti liberi non aiuta. Devi risolvere il tratto congestionato.

Lo stesso vale per i flussi di valore. Se la revisione del codice è il collo di bottiglia, rendere lo sviluppo più veloce crea solo un accumulo maggiore alla revisione del codice. Se il testing è il vincolo, assumere più sviluppatori significa solo più lavoro in attesa del QA.

Il sistema può muoversi solo alla velocità del suo vincolo più lento.

Questo ha implicazioni potenti per il miglioramento: migliorare qualsiasi cosa che non sia il vincolo è teatro. Può sembrare produttivo ma non ha alcun effetto sul throughput complessivo.

Come trovi il vincolo? Cerca dove si accumula l'inventario (lavoro).

Il vincolo ha un accumulo di lavoro in attesa davanti a sé. Se la revisione del codice ha sempre un backlog, la revisione del codice è probabilmente il vincolo. Se il testing ha settimane di lavoro in coda, il testing è probabilmente il vincolo.

Altri segnali di vincoli:

• Utilizzo elevato: Il vincolo è al massimo
• Pressione costante: Le persone nella fase del vincolo sono sempre di fretta
• Carenza a valle: Le fasi dopo il vincolo sono in attesa di lavoro
• Frustrazione a monte: "Abbiamo finito, perché non si muove?"

Vincoli comuni nel software:

• Revisione del codice (troppo pochi revisori, PR grandi)
• Testing (QA manuale, copertura di test limitata)
• Deployment (rilasci complessi, finestre di deploy limitate)
• Decisioni architetturali (in attesa dell'architetto)
• Decisioni di prodotto (in attesa del product owner)

Nota: il vincolo spesso non è una fase "produttiva". Potrebbe essere un decisore. Potrebbe essere un processo di approvazione. Potrebbe essere una risorsa condivisa.

La TOC prescrive un processo in cinque fasi:

1. Identificare il vincolo: Trova dove si accumula il lavoro.

2. Sfruttare il vincolo: Massimizza il throughput attraverso il vincolo senza aggiungere risorse. Se la revisione del codice è il vincolo, dai priorità alle revisioni rispetto al nuovo sviluppo. Assicurati che i revisori non siano distratti. Riduci la dimensione delle PR così le revisioni vanno più veloci.

3. Subordinare tutto il resto: I non-vincoli dovrebbero servire il vincolo. Se il QA è il vincolo, non spingere più lavoro nel QA—regola lo sviluppo per corrispondere alla capacità del QA.

4. Elevare il vincolo: Se sfruttamento e subordinazione non bastano, aggiungi capacità al vincolo. Forma più revisori. Automatizza il testing. Assumi più persone con la competenza vincolata.

5. Ripeti: Una volta eliminato un vincolo, ne emerge un altro. Il vincolo si sposta. Trovalo e ripeti.

Questo è un miglioramento iterativo e continuo. Sei sempre concentrato sul vincolo attuale, non disperso su tutte le fasi.

La metafora tamburo-buffer-corda: Il vincolo è il "tamburo" che imposta il ritmo. Il lavoro prima del vincolo è il "buffer". La "corda" tira il lavoro nel sistema al ritmo che il vincolo può gestire—non più veloce.