Taiichi Ohno e Lean IT

tps2

Ho trovato un articolo di Keith Swenson che fa un ottimo paragone tra i principi di lean manufacturing, come descritto da Taiichi Ohno nel suo libro Toyota Production System e sviluppo lean di software.

Riporto qui alcuni dei passaggi molto significativi tradotti in italiano:

Ohno: Fermando la macchina quando si riscontra un problema si forza il coinvolgimento e consapevolezza di tutti

Swenson: Quando un test fallisce, la squadra di sviluppo software dovrebbe lasciare tutto ciò che sta facendo e risolvere il problema riscontrato. Ciò forza il coinvolgimento e consapevolezza di tutti.

Ohno: Ripetendo perché cinque volte può aiutare a scoprire la causa all’origine del problema e aiutare la sua correzione.

Swenson: Uno dovrebbe chiedersi: “perché questa routine viene scritta in questo modo?”, “perché questa routine di supporto restituisce questo risultato?”, “a cosa serve il valore che abbiamo ottenuto?”, ecc. Affrontando il problema al livello più basso eliminiamo il bisogno di multiple copie del codice di compensazione e riduciamo il potenziale per eventuali bug.

Ohno: Solo il lavoro necessario è il vero lavoro, e definiamo il resto come spreco… dobbiamo fare solo la quantità necessaria e niente di più.

Swenson: Non implementare niente finché non ne hai bisogno in un caso specifico per un utente finale specifico. Se cerchi la perfezione da subito si tratta della pura sovrapproduzione: non solo è uno spreco del tempo del programmatore per implementarlo, ma l’eccesso delle linee di codice aumenta il tempo necessario per il riesame e manutenzione del codice in maniera assolutamente analoga al bisogno di avere immagazzinati particolari in eccesso nella produzione.

Ohno: Mi piaceva raccontare agli operai una delle mie storie preferite della squadra di canotaggio con otto uomini. Uno degli otto potrebbe sentirsi più forte degli altri e remare a velocità doppia. Questo sforzo in eccesso non fa altro che disturbare l’assetto della barca che inizia a muoversi fuori rotta.

Swenson: Lezioni di lavoro di squadra sono sempre utili. Nello sviluppo di software, consegnare un codice funzionante al cliente è l’obiettivo e misurare qualsiasi altra cosa, come il numero di linee prodotto o di bug trovati alle varie fasi di sviluppo, può disturbare il processo e portarlo nelle direzioni inaccettabili.

Ohno: Il sistema operativo della Toyota è kanban. Questo pezzo di carta porta l’informazione che può essere suddivisa in tre categorie: 1) informazione di prelievo; 2) informazione di trasferimento; 3) informazione di produzione.

Swenson: Il kanban non può essere applicato letteralmente come descritto da Ohno in quanto i pezzi di software sono uno diverso dall’altro e imprevedibili a priori. Comunque, l’idea che il livello di prestazione viene bilanciato e sincronizzato con il vero bisogno di produrre un determinato codice è molto importante.

Ohno: Se uno non comprende completamente il metodo così che il materiale viaggi in un flusso, non è possibile implementare un sistema di kanban nel momento opportuno.

Swenson: La parola chiave qui è “flusso”. Nella produzione il flusso dei particolari è essenziale. Nello software, il flusso dei feature è l’essenziale. Immagazinare un grande numero di feature da implementare in un progetto di 8 mesi è esattamente la stessa cosa come la produzione di massa di autoveicoli che mostrava segni di inefficienza negli anni 60 e 70. La produzione di massa crea lo spreco. Lo spreco viene eliminato da un flusso costante di rilasci del prodotto, ognuno velocemente generato dal precedente. Questo è il tema centrale del libro ed è anche il tema centrale dello sviluppo di software lean.

Ohno: All’inizio, ognuno tentava di resistere al kanban perché sembrava una contraddizione alla saggezza convenzionale. Per farlo funzionare e capire nell’intera produzione, dovevamo coinvolgere tutti.

Swenson: Bisogna sempre ricordarsi che la saggezza convenzionale è basata esclusivamente su ciò che uno è abituato a fare. La stessa cosa si osserva nello sviluppo di software, incluso il bisogno di coinvolgere tutti. Se viene formata solo una parte della squadra sul metodo, si è sulla strada sicura verso il fallimento (e ho la diretta esperienza personale con questo…).

Ohno: Mentre la produzione di massa pianificata in maniera tradizionale non risponde facilmente al cambiamento, il sistema Toyota è molto elastico per affrontare le difficili condizioni imposte dalle diverse domande del mercato.

Swenson: Lo scopo di sviluppo lean/agile è proprio questo: il flusso continuo di piccoli pezzi di software che permette una risposta molto più rapida ai cambiamenti del mercato.

Ohno: Era considerato senso comune produrre in lotti più grandi possibili e pressare continuamente senza fermare la pressa. Negli anni 40, il setup delle presse in Toyota era tra due e tre ore. Verso la fine degli anni 60, questo era abbassato a tre minuti.

Swenson: Se si riesce a capire il vantaggio di flusso continuo delle feature, allora si possono automatizzare i test e farli in modo tale che vengano effettuati ogni giorno.

Ohno: Per assicurarci che abbiamo 100% del prodotto senza difetti, dobbiamo stabilire un sistema che ci informa in automatico se qualche processo sta generando prodotti difettosi.

Swenson: Test automatici, debug continui con prove automatiche. Richiede da ogni programmatore di testare il codice prima di consegnarlo e di non consegnarlo finché il test non viene superato. E’ esattamente lo sviluppo lean/agile come descritto nella letteratura e Ohno lo spiega negli anni 70…

Ohno: La terza regola del kanban proibisce il prelievo o produzione del prodotto senza un kanban. Sovrapproduzione viene controllata in automatico, anche se qualcuno vuole fare più di quanto richiesto.

Swenson: Se il software viene sviluppato per soddisfare i bisogni di un caso specifico, e il caso specifico è allegato nei controlli in ingresso, si elimina a priori la sovraprogrammazione di feature non necessari per quel caso specifico.

Ohno: Siccome non possiamo prevedere il futuro con precisione, le nostre azioni dovrebbero cambiare per assecondare le situazioni mutevoli.

Swenson: Flessibilità e adattabilità sono valori fondamentali, antitesi del mettere assieme un piano perfetto e poi eseguire questo piano a lungo termine senza modificarlo. E’ molto meglio adattare il piano man mano che si avanza.

Queste sono solo alcune delle osservazioni più significative dell’articolo. Vi fornisco qui una traduzione automatica dell’articolo dall’inglese così potete leggerlo tutto.

Cosa ci insegna questo articolo? Ci insegna che i principi di gestione snella (lean thinking) sono applicabili a tutte le attività, a tutti i processi che affrontiamo giorno per giorno. Basta solo saperli interpretare nella giusta maniera e cogliere l’essenza che poi ci aiuterà a migliorare i nostri processi, anche se non direttamente collegati con la produzione e fabbrica…

Scarica articolo come PDF

Articoli simili:

Tagged as: customer satisfaction, lean IT, lean thinking, pull e kanban, valore