Metodologie di sviluppo software: Lean vs Agile Principles

“Lean” e “Agile” sono termini che sono stati buttati in giro molto di recente, spesso in riferimento a metodologie di sviluppo software, gestione dei progetti o stili organizzativi.

Ma vi siete mai trovati a chiedervi:

Che cos’è Lean? Cos’è Agile? C’è differenza?

Il dizionario Merriam-Webster definisce Agile come “avere un carattere veloce, intraprendente e adattabile, o caratterizzato dalla pronta capacità di muoversi con grazia rapida e facile.”

Lean è definito semplicemente come “sottile e sano, o che contiene poco o nessun grasso.”

In base a queste definizioni, possiamo assumere che qualcuno che è lean e qualcuno che è agile potrebbero avere molte caratteristiche comuni. Lo stesso è vero nel contesto dello sviluppo del software.

Cos’è Agile? Cos’è Lean?

Agile è ormai ampiamente conosciuto nel mondo della tecnologia come un insieme di valori e principi per guidare lo sviluppo del software. Il “Manifesto Agile” stabilisce un insieme di quattro valori e 12 principi. Distillato nel suo nucleo, Agile è esattamente quello che si pensa possa essere. È Agile. La metodologia favorisce la flessibilità, la comunicazione, la collaborazione e la semplicità.

Lean è meno compreso e manca una definizione chiara supportata da un consenso professionale.Il termine “Lean” è stato originariamente coniato per descrivere un modello di organizzazione della produzione basato sul Toyota Production System, ma è comunemente considerato un sub quadro all’interno dell’ombrello Agile dello sviluppo software.

Oggi c’è molta confusione su cosa sia Lean, cosa sia Agile, se siano la stessa cosa e quale dovrebbe essere usato.

La nascita di nuove metodologie di sviluppo del software

Sia Lean che Agile sono state sviluppate in risposta alle carenze dei metodi esistenti basati su piani come Waterfall. Utilizzati fin dagli anni ’70, gli sviluppatori e i responsabili dell’ingegneria del software hanno cominciato a notare le inefficienze del Waterfall negli anni ’90. Con mercati più dinamici e consumatori esperti di tecnologia, Waterfall non era in grado di rispondere abbastanza velocemente alle richieste del mercato, ai cambiamenti tecnologici, o di consegnare software senza bug su una base costante.

Nella ricerca di un modello migliore, i creatori di Lean e Agile hanno cercato di sviluppare metodologie con un approccio più focalizzato sul cliente. Le nuove metodologie abbracciarono la capacità di adattarsi come un vantaggio competitivo, favorirono i test precoci e continui, e portarono un elemento umano nella gestione e nell’esecuzione del progetto.

Principi Lean vs Agile

Lean Software Development (LSD) fu proposto per la prima volta dal dott. Robert Charette come un modo per costruire organizzazioni tolleranti al cambiamento che stavano diventando sempre più dipendenti dal software.

Poi venne “The Agile Manifesto” che racchiuse i 12 principi dell’Agile Software Development.

L’altro lavoro autorevole sulle metodologie di sviluppo del software è accreditato a Mary e Tom Poppendieck, che hanno pubblicato Lean Software Development: An Agile Toolkit.

Ecco un confronto fianco a fianco dei valori e dei principi di ciascuno:

Confrontando i 12 principi del LSD del Dr. Charette e i 12 principi di Agile, si può vedere che sono sorprendentemente simili. I sette principi Lean proposti dai Poppendieck sono meno mirati, ma si sovrappongono comunque a “The Agile Manifesto” e al Lean Software Development di Charette.

Ecco altri elementi che hanno tutti in comune:

• Il valore di rispondere rapidamente alle esigenze dei clienti
• Test precoci
• Un approccio iterativo allo sviluppo
• Lo stile di sviluppo MVP (Minimum Viable Product) piuttosto che feature heavy
• Cooperazione sia all’interno dell’azienda che con gli stakeholder esterni

Timeline

Abbiamo studiato gli eventi e le pubblicazioni che hanno dato vita a queste terminologie per vedere come sono diventate popolari. Date un’occhiata alla nostra timeline qui sotto che descrive la progressione, e aggiungetela alla vostra lista di lettura se siete così inclini!

Origini di Lean e Agile

Come potete vedere dalla timeline, il termine Lean fu usato per la prima volta da Womack et. al. nel 1990 per descrivere il Toyota Production System nel loro libro, The Machine That Changed The World. Il Dr. Robert Charette ha poi adattato le idee Lean descritte nelle pubblicazioni precedenti per creare il suo “Lean Software Development”.

Il termine Agile non è stato ampiamente adottato fino alla pubblicazione del “The Agile Manifesto” nel 2001. I termini Agile e Lean sono stati entrambi coniati da professionisti della tecnologia occidentale o da accademici che si riferivano al sistema di produzione Toyota (più avanti).

Potremmo prenderci delle critiche per averlo detto, ma con questo in mente, i termini Lean e Agile non sono in realtà così importanti. Avere due termini che derivano dagli stessi principi in realtà contribuisce alla confusione sull’argomento. Detto questo, questa è la terminologia che l’industria ha adottato, quindi andando avanti continueremo ad usarli.

La linea temporale è anche un’altra fonte di confusione. Il Dr. Robert Charette ha introdotto le sue idee sul Lean Software Development all’inizio e alla metà degli anni ’90. Lo scopo tattico e i 12 principi del suo approccio Lean Development sono stati descritti nel 1998 in un articolo intitolato “Lean Development”, quasi tre anni prima del “The Agile Manifesto”. A testimonianza della sovrapposizione tra Lean e Agile, questo articolo fu scritto da Jim Highsmith, che in seguito divenne un fondatore fondamentale del movimento Agile. Tuttavia, l’articolo di Highsmith non è stato ampiamente diffuso, e non è stato fino al 2003 che Charette stesso ha scritto una spiegazione più approfondita dietro il suo approccio di sviluppo snello nel rapporto di ricerca, “Challenging the Fundamental Notions of Software Development.”

In uno scambio di email con il dott. Charette, ha subito sottolineato che la sua concezione del Lean Development era destinata al livello organizzativo nel campo del software:

La mia è nata da un bisogno strategico e operativo di migliorare il valore di business/missione dell’IT per l’organizzazione, e mi sono avvicinato a questo da una prospettiva di gestione del rischio.
-Dr. Robert N. Charette

Questo differisce leggermente da Agile, che è stato inizialmente proposto strettamente come un “modo migliore di sviluppare software”, ma ora è applicato a vari progetti e metodi di gestione.

2003 è stato anche l’anno in cui i Poppendieck hanno pubblicato Lean Software Development: An Agile Toolkit. Questo libro dettagliava i sette principi del Lean Development, che si correlano direttamente alle sette forme di spreco del Lean Manufacturing.

Il libro dei Poppendiecks ha simultaneamente sostenuto il Lean come metodologia di sviluppo software e offuscato la distinzione tra Lean e Agile, proponendo il Lean come un metodo complementare all’interno di Agile. Infatti, al momento della pubblicazione, il libro è stato venduto come l’ultima pubblicazione all’interno di The Agile Software Development Series.

Oggi, le molteplici opere dei Poppendieck sull’argomento sono considerate letture essenziali per i professionisti dello sviluppo software Lean e “aspiranti tali”.

Divergenza nell’applicazione

Secondo il dottor Charette, una delle differenze principali tra Lean e Agile è che Agile è dal basso verso l’alto, mentre Lean è dall’alto verso il basso. Questo è evidente nella struttura end-to-end (E2E) di Lean e nel principio del See the Whole proposto dai Poppendieck. Di seguito spieghiamo questi principi all’opera nella pratica del value stream mapping.

Value Stream Mapping

Per realizzare il principio del See the Whole, i Poppendieck descrivono in dettaglio un metodo di value stream mapping per rivelare le attività a valore aggiunto rispetto a quelle non a valore aggiunto lungo il processo di sviluppo end-to-end.

Il value stream mapping analizza il ciclo di sviluppo dal momento in cui un requisito viene ricevuto al momento in cui viene consegnato al cliente. L’obiettivo è quello di identificare gli sprechi dell’inventario fermo e dell’attesa (ritardi nella produzione), ed esplorare nuove pratiche per ridurre il Work-in-Progress (WIP) e il lead time.

Secondo i Poppendieck, mappare il proprio value stream è un esercizio semplice che richiede solo una matita e un pezzo di carta. Il processo è il seguente:

1. Mappa il tuo flusso di valore attuale (iniziando con un requisito e una linea temporale di azioni nel viaggio verso la consegna)
2. Analizza la più grande causa di spreco (Cosa sta bloccando il Work-in-Progress?)
3. Sviluppare un piano per dimezzare questi sprechi
4. Creare una futura mappa del flusso del valore

Il paradigma Agile come stabilito nel “The Agile Manifesto” favorisce cicli di iterazione brevi e consegne frequenti rispetto ad una visione olistica end-to-end. Il focus E2E è quindi unico per Lean. Infatti, è a causa del costrutto E2E che il Lean (piuttosto che Agile) è più spesso applicato come struttura organizzativa e stile di gestione.

La visione end-to-end richiede che l’intera organizzazione partecipi per eliminare gli sprechi. Questo fa eco allo scopo dichiarato dal Dr. Charette per il suo concetto originale di Lean Development:

Lean Development è una filosofia, un modo di vedere e pensare l’IT e la sua relazione con un’organizzazione, tanto quanto è un approccio allo sviluppo.

Lean Kanban Vs. Agile Kanban

Sia Lean che Agile hanno adottato il sistema TPS Kanban con leggere variazioni. Il sistema Kanban di Toyota è stato progettato per limitare il Work-in-Progress.

In contrapposizione al tradizionale “push manufacturing”, che spinge l’inventario alla fase successiva del processo, il Kanban tira in produzione nuovo materiale solo quando il pezzo corrente è stato lavorato e i componenti devono essere riforniti.

Le schede Kanban diventano ordini di rifornimento e vengono rimandati alla fase precedente della produzione. Come risultato, il Work-in-Progress è minimizzato e l’inventario inattivo è ridotto.

Nello sviluppo del software, invece di passare le carte Kanban da una fase di produzione a quella precedente, si usa una tavola Kanban. Si usano note adesive, il più delle volte per rappresentare i requisiti in corso.

Secondo il capitolo contribuito da Kai Petersen in Modern Software Engineering Concepts and Practices: Advanced Approaches, sia Agile che Lean usano una lista prioritaria di requisiti da cui estrarre i compiti.

A differenza di Agile, che usa cicli di iterazione a durata fissa per limitare il tempo di sviluppo e governare la tavola Kanban, Lean limita il numero di compiti consentiti in qualsiasi momento. Questo permette al Lean di soddisfare il suo obiettivo primario di limitare il WIP, mentre misura più accuratamente il lead-time e identifica gli sprechi nella produzione. Una volta che un compito è completato, un nuovo compito può essere estratto dalla lista delle priorità. Mentre Lean usa il concetto di flusso continuo, Agile inizia ogni nuova iterazione con una nuova scheda.

Alcuni team riconoscono i benefici di entrambi gli approcci, e stanno iniziando ad usare un metodo ibrido conosciuto come scrumban.

Queste sono solo due delle sottili differenze nell’approccio Lean e Agile per raggiungere obiettivi comuni. Un altro articolo pubblicato su Codementor esplora altri usi e applicazioni di Lean e Agile.

In pratica, se il vostro team adotta un approccio cosiddetto “Agile” o un approccio “Lean” non è importante. Ciò che è importante è trovare le pratiche giuste per ottimizzare i vostri flussi di lavoro e fornire costantemente valore ai vostri clienti, che entrambe le metodologie vedono come il fine ultimo.

La connessione TPS

Quindi cosa ha a che fare tutto questo con il Toyota Production System? Praticamente tutto. I creatori di Agile e Lean sono stati pesantemente influenzati dal TPS, come Womack et al. descrivono in The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. L’azienda non poteva sperare di seguire il modello di produzione di massa di Detroit e sopravvivere.

In queste condizioni, Taiichi Ohno e Kiichiro Toyoda hanno deciso di rimanere redditizi eliminando gli sprechi nella produzione, riducendo i tempi di consegna e producendo solo ciò di cui i clienti avevano bisogno, noto anche come produzione Just-in-Time (JIT).

Per eliminare gli sprechi, Ohno ha deciso di produrre solo ciò che era necessario, quando era necessario, e solo nella quantità necessaria.

Il processo iterativo di Lean e Agile che si concentra sulla minimizzazione dello sviluppo delle caratteristiche e la massimizzazione della consegna degli aggiornamenti rispecchia direttamente la produzione Just-in-Time di Toyota.

Jidoka

Jidoka (自働化) può essere tradotto come automazione con un tocco umano, talvolta indicato come “automazione intelligente”. Jidoka gioca un ruolo importante nell’eliminazione degli sprechi nella produzione, rendendo le macchine più indipendenti, il che libera le persone a svolgere un ruolo più attivo nella produzione e libera la creatività umana.

Jidoka si basa su macchine intelligenti che si fermano automaticamente quando c’è un’irregolarità. I lavoratori umani possono quindi andare a risolvere il problema, impedendo che i difetti vengano trasmessi lungo il processo di produzione.

Jidoka autorizza anche ogni dipendente a fermare la linea di produzione quando viene rilevato un problema. Il principio include un processo in quattro fasi per eliminare lo spreco di prodotti difettosi:

1. Rilevare l’anomalia
2. Fermare la produzione
3. Fissare o correggere la condizione immediata
4. Investigare la causa principale e rimediare alla situazione

Si può vedere il concetto Jidoka nel focus Lean e Agile sui test precoci e frequenti per eliminare i bug, e l’enfasi sulla consultazione del cliente per individuare i dolori dell’utente.

Gli sprechi del TPS in un contesto di sviluppo software

Per realizzare la produzione JIT, Taiichi Ohno ha delineato sette forme di spreco da eliminare. Il numero otto è stato aggiunto più tardi. Se si dà un’occhiata più da vicino ai valori, agli obiettivi e ai principi di Agile e Lean, si può vedere che sono progettati per difendersi dagli otto sprechi del TPS. Nel loro libro del 2003 Lean Software Development: An Agile Toolkit, i Poppendieck hanno presentato gli sprechi TPS in un contesto di sviluppo software.

1. Lo spreco della sovrapproduzione. Lo spreco della sovrapproduzione è uno dei motivi principali per cui il metodo Waterfall è stato abbandonato. La sovrapproduzione è considerata codifica extra per caratteristiche che non sono state richieste e che il cliente potrebbe non volere.

Questo si riflette nei seguenti principi:

Agile ⟶ semplicità
Lean⟶ minimalismo di Charette
Lean ⟶ eliminare gli sprechi

2. Lo spreco dell’attesa. Nella produzione JIT, aspettare una macchina o un lavoratore inattivo è uno spreco. Nello sviluppo del software, lo spreco è l’attesa di un team con capacità in eccesso. Se ci sono ritardi nella produzione che causano un team in attesa, o causano al cliente di aspettare la consegna, c’è spreco.

I principi corrispondenti sono i seguenti:

Agile ⟶ cicli frequenti
Lean diarette ⟶ ⅓ del tempo (obiettivo di LSD), 80% di soluzione oggi
Lean di Poppendieck⟶ consegna il più veloce possibile

3. Lo spreco del trasporto. Nello sviluppo del software, il trasporto è tradotto come “passaggio di compiti”. Troppi passaggi di consegne o dipendenti assegnati a più team con una richiesta di eccessivo multitasking è inefficiente e uno spreco.

Principi corrispondenti:

Agile ⟶ collaborazione degli stakeholder, team auto-organizzati, cultura di
fiducia, supporto e motivazione
Lean ⟶ sforzo di squadra diarette
Lean ⟶ di Poppendiecks danno potere al team

4. Lo spreco di sovraelaborazione. Si tratta semplicemente di processi extra che non sono realmente necessari per fornire valore al cliente. L’esempio principale è la documentazione. Una documentazione eccessiva per processi inflessibili non sarà preziosa, né lo sono manuali utente troppo dettagliati che potrebbero essere riassunti in una pagina o due. La documentazione richiede molto tempo ma offre un valore limitato all’utente finale.

Principi corrispondenti:

Agile ⟶ semplicità, software funzionante come misura
Charette’s Lean ⟶ minimalismo
Poppendiecks’ Lean ⟶ eliminare gli sprechi

5. Lo spreco dell’inventario. Lo spreco di inventario è il Work-in-Progress per il quale è stato fatto un investimento, ma non ha valore fino al completamento. In altre parole, il software incompleto non fornisce alcun valore all’utente. Lean e Agile danno valore a consegne veloci e frequenti, con un’enfasi su cicli iterativi frequenti e sulla consegna di software funzionante.

Principi corrispondenti:

Agile ⟶ soddisfazione del cliente (attraverso consegne anticipate e frequenti)
Lean di Charette ⟶ 80% di soluzioni oggi
Lean di Poppendieck ⟶ consegna il più velocemente possibile

6. Lo spreco del movimento. Lo spreco di movimento è lo sforzo in eccesso richiesto per ottenere informazioni o rispondere alle domande. Questo è comune quando i team non sono co-locati, se i compiti sono completati e i risultati non sono resi disponibili immediatamente a tutte le parti interessate, o quando le parti interessate non sono prontamente disponibili per la consultazione.

Principi corrispondenti:

Agile ⟶ collaborazione delle parti interessate, comunicazione faccia a faccia
Lean diarette ⟶ partecipazione del cliente, sforzo del team
Lean di Poppendiecks ⟶ eliminare gli sprechi

7. Lo spreco dei difetti. Come nella produzione, produrre software difettoso o buggato rappresenta un investimento sprecato dall’azienda. Più velocemente viene rilevato un difetto, più è probabile che lo spreco venga mitigato. Molti principi Agile e Lean cercano di fermare lo spreco di difetti. Per ridurre i difetti, tutte e tre le metodologie mettono in primo piano i test precoci e frequenti.

Principi corrispondenti:

Agile ⟶ eccellenza tecnica, software funzionante come misura
Charette’s Lean ⟶ soddisfazione del cliente
Poppendiecks’ Lean⟶ amplificare l’apprendimento

8. Lo spreco della creatività inutilizzata dei dipendenti. Nello sviluppo del software, la creatività inutilizzata deriva da una rigida tabella di marcia e dalla mancanza di collaborazione umana. Proprio come Jidoka (自働化), Agile e Lean cercano di massimizzare la collaborazione umana e l’innovazione per ottenere i migliori risultati dalla tecnologia.

Principi corrispondenti:

Agile ⟶ collaborazione degli stakeholder, riflessione del team
Lean ⟶ principio “non scritto” della soddisfazione attraverso il
lavoro
Poppendiecks’ Lean ⟶ amplificare l’apprendimento

Valori TPS nella metodologia di sviluppo software

Molti dei valori fondamentali che costituiscono TPS si riflettono anche nelle metodologie di sviluppo software Agile e Lean.

Kaizen (改善) si traduce come miglioramento continuo. Con modelli flessibili, iterativi e focalizzati sul cliente, il miglioramento continuo è forse il valore più importante delle metodologie di sviluppo software Agile e Lean.

Hansei (反省) significa auto-riflessione. Come mezzo per migliorare l’efficienza, il Manifesto Agile adotta direttamente l’autoriflessione del team come dodicesimo principio. Nell’introdurre il suo modello di Lean Development, il Dr. Charette sfida i lettori a riflettere su tutti i presupposti attuali che dettano i processi che usano come un primo passo per trovarne di migliori. Anche il principio di amplificazione dell’apprendimento dei Poppendieck può essere considerato Hansei.

Il rispetto per le persone (尊重) è centrale in tutti e tre i paradigmi. Il primo valore del “The Agile Manifesto” è quello di “valorizzare gli individui e le interazioni rispetto ai processi e agli strumenti.”

Il rispetto per le persone appare anche nell’affermazione del Dr. Charette dell’importanza che gli individui provino soddisfazione attraverso il lavoro, e nel principio Lean dei Poppendiecks di responsabilizzazione dei team. Questo valore riconosce che quando gli individui sono coinvolti nel processo decisionale e nel miglioramento del loro ambiente di lavoro, sono lavoratori più innovativi ed efficienti.

Seiri (整理) è il principio che rispecchia lo spreco. Seiri detta che ciò che non è necessario dovrebbe essere rimosso. Questo comprende tutti i sette sprechi originali del TPS, per i quali abbiamo già identificato lo spreco parallelo nell’ambiente di sviluppo del software.

Gengchi Genbutsu (現地現物) si traduce letteralmente in “luogo reale, cosa reale”. In pratica, questo significa “ispezionare per capire”. Quando c’è un problema nel processo di produzione, il manager dovrebbe andare alla fonte per capire il problema e determinare come risolverlo.

Nello sviluppo del software, questo valore si manifesta nell’enfasi sui cicli di iterazione brevi, sui test precoci e sulla collaborazione con i clienti, in modo che gli ingegneri del software possano costruire un software funzionante che gli utenti desiderano veramente.

Conclusione

Come abbiamo detto nei paragrafi iniziali di questo post, la metodologia Lean è meno ben compresa ed è spesso considerata come una pratica Agile. Lean è forse meno ben definito semplicemente a causa delle sue applicazioni più ampie.

Lean ha una relazione più diretta con il Toyota Production System ed è stato proposto inizialmente come un insieme di metodi e pratiche organizzative per la gestione aziendale, e solo successivamente applicato allo sviluppo del software. Agile, d’altra parte, è stato sviluppato specificamente per lo sviluppo di software da professionisti dedicati nel campo.

Dopo aver dettagliato il background condiviso e i principi generali di queste due metodologie, si può vedere che questi due paradigmi hanno più cose in comune che differenze.

Uno dei principali autori di “The Agile Manifesto”, Martin Fowler, che ha anche lavorato a stretto contatto con i Poppendieck, ha sottolineato che Lean e Agile non si escludono a vicenda:

Lean e Agile sono profondamente intrecciati nel mondo del software. Non si può davvero parlare di alternative…. non si fa Agile o Lean, si fa Agile e Lean.

1. I 12 principi del Lean Software Development di Charette sono stati descritti per la prima volta nell’articolo di Jim Highsmith “Lean Development” nel 1998. Questo è stato successivamente elaborato nell’articolo del Dr.Charette “Challenging the Fundamental Notions of Software Development” ︎