Ciao, e benvenuto nella terza puntata della settantatreesima stagione. Abbiamo abbattuto il muro e detto che chi costruisce possiede anche il risultato. Ma una volta caduto il muro, cosa deve fare, il lavoro? Deve scorrere. Oggi parliamo del primo grande principio di DevOps, quello del flusso: l'idea che il lavoro debba fluire in modo liscio e continuo dall'idea fino all'utente, come su una catena di montaggio ben progettata, invece di procedere a scatti dolorosi.
Partiamo dal nemico numero uno del flusso, perché è controintuitivo: i lotti grandi. Immagina una fabbrica che, invece di spedire i prodotti man mano, accumula tutto per tre mesi e poi fa una spedizione gigantesca. Sembra efficiente, e invece è un disastro. Se in quel mucchio enorme c'è un difetto, lo scopri solo alla fine, quando ormai ne hai prodotti migliaia. Nel software è identico: il rilascio gigante, quello che accumula sei mesi di modifiche e poi le riversa tutte insieme in produzione una notte da incubo, è il modo più rischioso e doloroso di lavorare che esista. E paradossalmente, più a lungo aspetti per ridurre il rischio, più grande e pericoloso diventa il rilascio.
Vediamo perché i lotti piccoli sono la risposta, perché è il cuore di tutto. Rilasciare un piccolo cambiamento alla volta, spesso, ha vantaggi enormi. Primo: se qualcosa si rompe, sai subito qual è il colpevole, perché hai cambiato solo una cosa. Con il rilascio gigante, invece, quando qualcosa esplode devi cercare l'ago in un pagliaio di mille modifiche. Secondo: un cambiamento piccolo è facile da capire, da controllare, e soprattutto da annullare se va male. Andare a piccoli lotti non è andare più lenti: è andare più sicuri, perché ogni passo è piccolo abbastanza da non farti troppo male se inciampi.
Nota adesso un altro nemico silenzioso del flusso, quello che non si vede: il lavoro fermo. In ogni processo, tra una fase e l'altra, il lavoro tende ad accumularsi in mucchi che aspettano. Il codice scritto che aspetta di essere controllato. La modifica controllata che aspetta di essere rilasciata. Questi mucchi di lavoro fermo, in attesa, sono come le scorte che marciscono in un magazzino: occupano spazio, invecchiano, e nascondono i problemi. Un principio chiave di DevOps è tenere basso il lavoro in corso, non iniziare mille cose insieme, ma portarne poche fino in fondo, perché una cosa finita vale infinitamente più di dieci cose iniziate e ferme a metà.
Colleghiamo tutto questo a una vecchia legge di cui abbiamo parlato, quella sui colli di bottiglia. In qualsiasi catena, la velocità totale non la decide la fase più veloce: la decide la più lenta. Puoi anche velocizzare tutto il resto, ma se il lavoro resta bloccato ad aspettare quell'unica fase lenta, il flusso complessivo non migliora di un secondo. Per far scorrere davvero il lavoro devi trovare il collo di bottiglia, quel punto dove tutto si accumula, e allargare quello. Ottimizzare le fasi che non sono il collo di bottiglia è fatica sprecata: le fai correre a vuoto mentre il lavoro continua a impilarsi davanti allo stesso tappo di sempre. È una legge che vale per le fabbriche come per le squadre di software.
E c'è un ultimo ingrediente che rende possibile tutto questo: rendere il lavoro visibile. In una catena di montaggio vera vedi con gli occhi dove il lavoro si accumula, dove c'è un tappo. Nel software il lavoro è invisibile, vive dentro i computer, e quindi bisogna sforzarsi di rappresentarlo: una lavagna, delle colonne, dei cartellini che mostrano cosa è in attesa, cosa è in corso, cosa è finito. Quando il lavoro diventa visibile, i colli di bottiglia saltano all'occhio, i mucchi fermi si notano, e la squadra può ragionare insieme su come far scorrere meglio le cose. Non puoi migliorare un flusso che non riesci a vedere.
Voglio lasciarti con il capovolgimento che questo principio porta con sé. Siamo abituati a pensare che essere produttivi significhi tenersi occupati, avere mille cose in ballo. Il flusso dice l'opposto: la vera produttività non è quanta roba inizi, ma quanto in fretta il valore arriva all'utente, liscio e senza intoppi. Meglio poche cose che scorrono veloci fino in fondo che mille cose ferme in attesa. E il modo per ottenerlo non è correre di più: è togliere gli ostacoli, ridurre i lotti, snellire i passaggi, così che il lavoro, invece di accumularsi dietro un muro, scivoli via come acqua in un canale ben tenuto.
Per oggi ci fermiamo qui. Abbiamo parlato del primo principio di DevOps, il flusso: il lavoro deve scorrere liscio dall'idea all'utente, come una catena ben progettata. Il nemico sono i lotti grandi, il rilascio gigante che nasconde i difetti fino alla fine; la risposta sono i lotti piccoli, che ti dicono subito chi è il colpevole e sono facili da annullare. Un altro nemico è il lavoro fermo che si accumula tra le fasi, come scorte che marciscono: meglio poche cose finite che mille iniziate. La velocità la decide il collo di bottiglia, non le fasi veloci, e per gestire tutto questo bisogna rendere il lavoro visibile. Nella prossima puntata: scrivere l'infrastruttura. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.