DevOps: Il Lean

Nel nostro viaggio nelle organizzazioni DevOps, ci occupiamo questa volta della terza iniziale dell’acronimo CALMS (Culture, Automation, Lean, Measurement e Sharing); ci occupiamo della Lean.

The Toyota Way

Il precursore del lean manufacturing è il Toyota Production System (TPS) sviluppato tra il 1948 ed il 1975 da Ono Taiichi e Eiji Toyoda.

Chiamato originariamente just-in-time manufacturing, si basa sull’approccio creato dal fondatore della Toyota, Sakichi Toyoda, suo figlio Kiichiro Toyoda e l’ingegnere Taiichi Ohno appunto che, alla fine della Prima guerra mondiale, raccolsero la sfida di produrre autoveicoli e camion facendo affidamento su pochissimo capitale a disposizione.

I principi alla base del TPS sono incarnati in The Toyota Way, un insieme di principi e comportamenti alla base dell’approccio manageriale e del sistema di produzione della Toyota Motor Corporation. Toyota ha riassunto per la prima volta la sua filosofia, i suoi valori e i suoi ideali di produzione nel 2001, chiamandola The Toyota Way 2001 che consiste in principi in due aree chiave: miglioramento continuo e rispetto per le persone.

Toyota non poteva contare su grossi capitali da investire e giunse alla conclusione che bisognava provare a inventare un sistema in cui era possibile iniziare la produzione di un veicolo solo una volta ordinato dal cliente.

Il flow (flusso) è “tirato” a partire dal cliente. Quando la domanda di prodotti cresce e ci si avvicina al limite inferiore di scorta, all’operatore arriva una richiesta di rifornimento che, a sua volta, tira con sé i passi precedenti della lavorazione, come l’ordine, la spedizione, lo scarico nel magazzino e così via. Le pratiche e le componenti della produzione just-in-time supportano lo sviluppo del pull e dettano il ritmo di produzione. Tali pratiche mirano inoltre a ridurre il più possibile le scorte usate ed il numero di lavorazioni contemporanee. Nel The Toyota Way non si dovrebbe iniziare a produrre qualcosa di non “tirato” nel processo da un’esigenza reale.

Il kaizen è una “filosofia totale” che mira alla perfezione attraverso i processi di sperimentazione e Continuous Improvement (miglioramento continuo). Le persone sono addestrate attraverso il coaching e le pratiche di diffusione della conoscenza a riconoscere gli sprechi, risolvere problemi e sperimentare chiedendosi ripetutamente perché i problemi si verifichino. Possono contare sul supporto di un’organizzazione cross-funzionale, dove i flussi di approvazione delle richieste sono essenziali e veloci.

Le persone inoltre dovrebbero evitare di fare operazioni ripetitive e automatizzabili, per dedicarsi piuttosto alla risoluzione dei problemi. Quando si verifica un difetto su una linea di montaggio, ad esempio, gli operatori di Toyota possono arrestare l’intero processo di produzione per concentrarsi a sistemarlo. Questo sistema è un approccio agli inconvenienti che non li considera alla stregua di eccezioni, ma come parte dell’ordinario ciclo di produzione.

Il jikoda è il pilastro per la qualità intrinseca: un difetto non viene mai lasciato passare alla fase successiva. Se, dopo la risoluzione di un problema, si introduce una correzione, il problema non si verificherà più allo

stesso modo. Questo comportamento tende nel tempo a stabilizzare l’insorgenza della stessa tipologia di inconveniente.

Principi di Lean nei metodi Agili

Il Lean software development è una traduzione dei principi e delle pratiche di lean manufacturing al dominio dello sviluppo del software che sta emergendo, con il supporto di una cultura pro-lean, all’interno della comunità Agile. Lean offre una solida struttura concettuale, valori e principi, così come buone pratiche, derivate dall’esperienza, che supportano le organizzazioni agili.

Mary e Tom Poppendieck, nel 2003, pubblicano Lean Software Development e sono tra i primi a collegare il software ai principi di produzione Lean individuando ventidue pratiche, da organizzare nei propri processi produttivi, in contemporanea ai dibattiti sui metodi Agili e la produzione incrementale.

Lo sviluppo snello può essere riassunto in sette principi, appunto molto vicini nel concetto ai principi della produzione snella:

• Eliminare gli sprechi;
• Amplificare l’apprendimento;
• Decidere il più tardi possibile;
• Consegnare il più velocemente possibile;
• Responsabilizzare la squadra;
• Costruire l’integrità percepita;
• Ottimizzare il tutto

L’Extreme Programming

Kent Beck, l’inventore di Extreme Programming (XP), sostiene che in XP i principi del Toyota Production System abbiano grande risonanza.

L’Extreme Programming è una metodologia di sviluppo del software che ha lo scopo di migliorare la qualità del software e la reattività alle mutevoli esigenze dei clienti. Come tipologia di sviluppo agile del software, sostiene frequenti rilasci in brevi cicli di sviluppo, che hanno lo scopo di migliorare la produttività e introdurre punti di controllo in cui le nuove esigenze del cliente possono essere adottate.

Altri elementi della programmazione estrema includono:

• Programmare in coppia o fare un’ampia revisione del codice
• Test di unità di tutto il codice
• Non programmare caratteristiche fino a quando non sono effettivamente necessarie
• Una struttura di gestione piatta
• Semplicità e chiarezza del codice
• Aspettarsi cambiamenti nei requisiti del cliente con il passare del tempo
• La migliore comprensione del problema
• Comunicazione frequente con il cliente e tra i programmatori.

La metodologia prende il nome dall’idea che gli elementi benefici delle pratiche tradizionali di ingegneria del software siano portati a livelli estremi. Per esempio, le revisioni del codice sono considerate una pratica benefica quindi, portato all’estremo, il codice può essere rivisto continuamente.