Il Potere dei Piccoli Lotti

Un lotto è un gruppo di elementi elaborati insieme. Nella produzione: parti realizzate in una serie. Nel software: funzionalità raggruppate in un rilascio.

Il pensiero tradizionale favorisce i grandi lotti. Se ci vogliono 30 minuti per configurare la macchina, produci 100 parti per serie invece di 10. Distribuisci il costo di configurazione su più unità.

Questa logica si applica anche al software: se il deployment richiede 2 ore, raggruppa molte funzionalità per deploy. Distribuisci il sovraccarico su più modifiche.

Ma questo ragionamento ignora i costi nascosti:

Costo di inventario: I grandi lotti creano grandi inventari. Le parti aspettano. Le funzionalità aspettano. Il capitale è immobilizzato. Il feedback è ritardato.

Costo di qualità: I difetti nei grandi lotti colpiscono più elementi. Trovare quale modifica ha causato il bug è più difficile nei grandi rilasci.

Costo di ritardo: I clienti aspettano più a lungo. Una funzionalità completata in anticipo aspetta che il lotto sia completato.

Ritardo nell'apprendimento: Non impari dalla reazione del cliente finché l'intero lotto non viene rilasciato. Mesi di lavoro potrebbero essere nella direzione sbagliata.

Il costo totale dei grandi lotti spesso supera il costo di configurazione risparmiato.

L'intuizione chiave: se riduci i costi di transazione (configurazione), i piccoli lotti diventano economici.

Lo SMED (Single-Minute Exchange of Dies) di Toyota ha ridotto il cambio macchina da ore a minuti. Una volta che il cambio era economico, i piccoli lotti avevano senso. La fabbrica poteva produrre ciò che serviva, quando serviva, in qualsiasi quantità.

Nel software, il "cambio" include:

• Tempo di build
• Durata della suite di test
• Complessità del deployment
• Sovraccarico del processo di review
• Coordinamento del rilascio

Ognuno di questi è riducibile:

• Build veloci: Compilazione incrementale, caching, codebase più piccole
• Test veloci: Testing parallelo, selezione intelligente dei test, unit test più veloci
• Deploy facili: Pipeline CI/CD, infrastructure as code, feature flag
• Review leggere: Pair programming, PR piccole, trunk-based development
• Nessun coordinamento di rilascio: Il continuous deployment elimina il concetto

Quando i costi di transazione si avvicinano a zero, la dimensione del lotto può avvicinarsi a uno. Questo è il flusso a pezzo singolo: ogni modifica va in produzione individualmente.

Quando raggiungi i piccoli lotti, tutto migliora:

Feedback più veloce: Le funzionalità raggiungono rapidamente gli utenti. Impari cosa funziona. Puoi cambiare direzione.

Debug più facile: Quando una piccola modifica causa un problema, la causa è ovvia. Il rollback è semplice.

Rischio inferiore: Ogni deployment è una piccola modifica. Il raggio d'azione di un bug è limitato.

Flusso migliore: I piccoli lotti si muovono più velocemente attraverso il sistema. Il lead time diminuisce.

Meno inventario: Nessuna grande pila di lavoro in attesa di essere rilasciata. Il capitale non è immobilizzato.

Qualità superiore: Le piccole modifiche sono più facili da revisionare. I difetti vengono individuati prima.

Maggiore flessibilità: Puoi ripriorizzare rapidamente. Non sei vincolato a un grande rilascio.

Morale del team: Rilasciare frequentemente è più gratificante che aspettare mesi per un grande rilascio.

L'espressione ultima è il continuous deployment: ogni modifica va in produzione quando è pronta. Questo è il flusso a pezzo singolo per il software. Nessun raggruppamento, nessuna attesa, nessun coordinamento dei rilasci.

Se il continuous deployment sembra impossibile, chiediti: quali costi di transazione dovrebbero ridursi? Poi lavora per ridurli.