1.
I principi del Lean Software Development
Il Lean Thinking applicato al Software
Carlo Barengo – carlo.barengo@gmail.com

2.
Lean
È un termine che riassume un modo di pensare per
aumentare l’efficienza ed eliminare gli sprechi, viene
utilizzato in diversi contesti…..

3.
Cronistoria
1550-1900
Studi che
partono da
Venezia
(arsenale) per
migliorare il
flusso
produttivo
1900-1990
Viene
applicato alle
industrie
manifatturiere
standardizzato
e studiato
1990-2005
Lean viene
“promosso” ed
entra a far
parte delle
metodologie
applicate alla
produzione
2006
Lean viene
applicato allo
sviluppo
software da
parte di M & T
Poppendieck
2011
Lean viene
applicato
anche alle
società
definite come
startup da E.
Ries

4.
Principi Lean e Ambiti
• I principi Lean vengono adottati in ambiti differenti
MANIFATTURIERO
 Eliminare gli sprechi
 Definire il valore dal punto
di vista del Cliente
 Far fluire tutte le attività
 Realizzare un’attività
solamente quando il
processo a valle lo richiede
(just-on-time)
 Perseguire la perfezione
tramite miglioramenti
continui (Kaizen)
STARTUP
 Gli imprenditori sono
ovunque
 Imprenditorialità è
gestione
 Apprendimento “validato”
 Costruisci-Misura-Impara
 Innovazione “responsabile”
SOFTWARE
 Eliminare gli sprechi
 Creare la conoscenza
 Rinviare l’impegno
 Rilasciare velocemente
 Potenziare il Team
 Ottimizzare

5.
I principi Lean
• Adottato inizialmente da Toyota nel processo “just-in-
time”, ha trasformato radicalmente il processo di
produzione dei veicoli.
• Per quanto riguarda lo sviluppo software nasce dalla
rielaborazione dei principi Lean della produzione
industriale da parte di Tom e Mary Poppendieck.
• Con le loro pubblicazioni ed i numerosi seminari
hanno fatto in modo che siano stati ampiamente
accettati dalle comunità “Agili” di sviluppatori

6.
I principi Lean
1. Eliminare gli sprechi
2. Definire il valore dal punto di vista del cliente
3. Far fluire tutte le attività
4. Realizzare un’attività solo quando il proceso a valle lo
richiede
5. Perseguire la perfezione tramite continui
miglioramenti (Kaizen)

7.
I principi Lean – applicati allo sviluppo SW
1. Eliminare gli sprechi
2. Amplificare l’apprendimento
3. Decidere il più tardi possibile
4. Consegnare rapidamente
5. Potenziare il team delle risorse
6. Costruire l’integrità
7. Ottimizzare il tutto

8.
Sette semplici regole
1. Eliminare gli sprechi:
• impiegare il tempo solo su cose che aggiungono valore al cliente.
2. Amplificare l’apprendimento:
• quando ci sono problemi di difficile soluzione aumentate il feedback.
3. Decidere il più tardi possibile:
• tenere aperte varie opzioni, ma non troppo a lungo.
4. Consegnare rapidamente:
• consegnare valore al cliente prima che lo richieda..
5. Potenziare il team delle risorse:
• Esortare le persone a dare valore aggiunto.
6. Costruire l’integrità:
• non pensare all’integrità di un prodotto dopo la consegna, costruiscila costantemente.
7. Ottimizzare il tutto:
• evitare la tentazione di ottimizzare singole parti a discapito di tutto

9.
1 - Eliminare gli sprechi
Può sembrare ovvio!
• Alcuni sprechi spesso sono evidenti, altri sono difficili da identificare o da
affrontare
• In alcuni casi processi e modi operativi possono sembrare uno spreco ma in realtà
sono utili ad altri settori aziendali

10.
Lo spreco nelle attività industriali
Le metodologie Lean applicate in Toyota (produzione industriale) identificavano 3 forme di spreco:
• ‘Muda‘ - attività inutili, che assorbono risorse e non creano valore al cliente
• sprechi di trasporto, sprechi per attese, sprechi di movimento, sprechi per scorte, sprechi di
processo, sprechi di sovrapproduzione e sprechi per prodotti difettosi
• ‘Mura‘ - intesa come “incompatibilità”
• evidente nella gestione delle scorte, queste forniscono una riserva anche quando la
produzione non ne ha bisogno (non avere scorte in più rispetto alla reale richiesta).
Fluidificare la produzione per rispondere facilmente ai cambiamenti.
• ‘Muri‘ - sovraccarico di persone o risorse
• provoca a lungo termine la possibilità di infortuni o malattie, assenza dal lavoro per periodi
più o meno lunghi e insoddisfazione generale delle persone che si sentono sfruttate.
Osserviamo il lavoro, analizziamo le attività svolte, aumentiamo l’efficienza togliendo sovraccarico.
Il lean thinking insegna proprio questo: osservare ed analizzare

11.
Lo spreco nello sviluppo software
Lo spreco è qualunque cosa che non aggiunge valore ad un
prodotto, (percezione del cliente), spesso viene generato da:
• Pezzi che stanno sullo scaffale a prendere polvere
• Specifiche software raccolte in un raccoglitore che si sta
impolverando
• Spostare continuamente lo sviluppo da un gruppo di lavoro
ad un altro
L’ideale è fare esattamente cosa desidera il ns. Cliente,
sviluppare e consegnare quando vuole (il prima possibile!)

12.
1.2 - Eliminare gli sprechi
Il processo iterativo di analisi e miglioramento continuo è importante per
identificare/eliminare sprechi (Sviluppo Agile)
Nei metodi tradizionali, di sviluppo e project management, si c’è il
“lessons learned” ma è presente solo alla fine nel processo di chiusura, e
può avere le seguenti criticità:
• dimenticare alcuni particolari accaduti;
• persone non più presenti;
• contesti cambiati;
• team smembrati o attivati su altri progetti.
Difficilmente quanto accaduto viene realmente identificato ed applicato
successivamente.

13.
2- Amplificare l’apprendimento
Lo sviluppo è ricerca e scoperta
La produzione è ridurre al massimo le variazioni.
Un approccio Lean per lo sviluppo applicativo risulta essere abbastanza
differente dalle pratiche Lean di produzione industriale.
Es. Lo sviluppo è come creare una ricetta di un piatto di pasta, la produzione è
fare il piatto di pasta
Lo Chef non ha una ricetta perfetta al primo tentativo, la ottiene solo dopo una
serie di varianti applicando l’esperienza acquisita (processo iterativo)
Nello sviluppo software l’ambiente è ancora più complesso in quanto:
• non si lavora singolarmente ma in gruppo;
• la conoscenza deve essere il più possibile distribuita
• l’apprendimento deve essere amplificato

14.
3 – Decidere il più tardi possibile
Nello sviluppo software, decidere il più tardi possibile
permette di avere un approccio basato su più opzioni.
• Ritardare le decisioni può avere i seguenti effetti:
• Decidere nel momento in cui ci sia qualcosa di
concreto e non teorico
• All’interno di un sistema complesso, le decisioni
vengono rimandate fino a che questo non prenda
forma nella sua totalità

15.
3 – Consegnare rapidamente
Lo sviluppo rapido ha molti vantaggi:
• Non si possono ritardare le decisioni;
• Non si dispone di un feedback affidabile
• Assicura che il cliente abbia ciò di cui ha bisogno adesso e non ieri
Comprimendo il più possibile il flusso del valore applichiamo una delle principali
strategie Lean per l’eliminazione degli sprechi

16.
3 – Potenziare il Team delle risorse
• Coinvolgere gli sviluppatori nelle decisioni tecniche è fondamentale per raggiungere
obiettivi di eccellenza
• Infatti chi è in prima linea possiede:
• la conoscenza del dettaglio;
• la disponibilità di più persone e pareri.
• Le decisioni vengono prese il più tardi possibile e l’esecuzione è veloce quindi non è
possibile da un’autorità centrale orchestrare la singola risorsa.
• Nelle pratiche Lean (industriali) vengono utilizzate tecniche per la schedulazione del
lavoro e meccanismi di segnalazione tra un gruppo ed un’altro.
• Nello sviluppo Lean ci si accorda sul meccanismo di schedulazione che è scandito dal
rilascio di versioni incrementali dell’applicativo (generalmente ad intervalli regolari).
• La segnalazione tra i team è costituita da:
• Grafici, incontri giornalieri, integrazioni frequenti e test generali
•

17.
6 - Costruire l’Integrità (di un prodotto)
Un prodotto si può affermare che sia costituito da due
tipologie di Integrità:
• Integrità percepita;
• Integrità concettuale.
La prima è che un prodotto finale raggiunga un
bilanciamento di funzioni, disponibilità, usabilità ed
economia che gratifichi il cliente;
La seconda è che il prodotto sia ben integrato in un
sistema più grande con coerenza.

18.
6.1 – Integrità percepita
Questa è influenzata dall’esperienza
che il cliente ha di un sistema, nello
specifico:
•Come è pubblicizzato;
•Come è installato;
•Le modalità di accesso;
•Se il suo utilizzo è intuitivo;
•Quanto costa;
•Quali sono i tempi di risposta;
•Come risolve il problema che gli
sottoponiamo.

19.
6.2 - Integrità Concettuale
Un sistema è integrato in una architettura generale affinchè:
Flessibilità, manutenzione, efficienza e tempi di risposta siano in
equilibrio
Integrità concettuale è pre-requisito di Integrità percepita
Se un applicativo non ha un buon disegno concettuale l’utente ha
difficoltà di navigazione tra le funzioni e di conseguenza problemi di
usabilità
Con il giusto impegno si può far emergere l’Integrità concettuale con
l’evoluzione e la maturità del prodotto applicativo stesso.

20.
7 - Ottimizzare il tutto
Un sistema applicativo è composto da parti interdipendenti e
che interagiscono fra loro con un obiettivo funzionale
generale.
Un sistema non è solo una somma di singole funzioni, ma
l’integrazione fra loro.
Prese singolarmente le funzioni applicative migliori non fanno
un sistema applicativo migliore, quindi:
• l’obiettivo si considera centrato per un sistema quando le
singole parti che lo compongono sono integrate e NON
come performano singolarmente.

21.
7 – Ottimizzare il tutto
• Il Systems thinking tratta una organizzazione
come fosse un sistema, analizzando come le
parti si relazionano e come sono le
performance del tutto;
• Gli analisti, in genere costruiscono un modello
computerizzato inserendo dei dati riassunti
dalle interviste al personale e ricavandone le
regole organizzative.
• Ovviamente ognuno prende delle decisioni in
base ai dati disponibili
• Spesso i risultati dei modelli portano ad un
impatto sulle politiche aziendali che spesso
non vengono capite.
• In ogni caso le nuove politiche sono orientate
a risolvere un problema non ad eliminarlo
definitivamente

22.
7.1 – Ottimizzare il tutto
Spesso notiamo questa dinamica nello sviluppo applicativo
• Quando un’organizzazione ha esperienze negative nello sviluppo tende a
imporre nuovi processi organizzativi (spesso sequenziali)
• Es. specifiche di progetto molto accurate, con approvazione continua del
cliente e tracciamento di ogni modifica di dettaglio nel codice.
• Inizialmente si può avere anche un beneficio ma non detto che sia la cura
giusta
• L’effetto ritardo in un processo sequenziale, in un ambiente dinamico, aumenta
la difficoltà a tenere l’applicativo allineato alle richieste del cliente
• Spingere sui processi di tipo sequenziale può portare ad una spirale di aumento
dei costi e limitare la crescita aziendale
• Sebbene un processo possa produrre i risultati desiderati può creare l’effetto
secondario di rallentare tutta l’organizzazione.
• Continuare a spingere sullo stesso processo per raggiungere un buon risultato
amplifica l’effetto contrario di limitarne la crescita
Quindi non continuare a spingere sulla crescita ma concentrarsi sul rimuoverne i
limiti

23.
Conclusioni
Se i problemi odierni dipendono dalle soluzioni di ieri, i problemi di domani
dipenderanno dalle soluzioni adottate oggi
Evitiamo eccessi e cerchiamo di trovare un punto bilanciato tra i principi Lean
1. Eliminare gli sprechi non significa gettar via tutta la documentazione
2. Amplificare l’apprendimento non significa cambiare mentalità
3. Decidere il più tardi possibile non significa procrastinare all’infinito
4. Consegnare rapidamente non significa correre e fare un lavoro sciatto
5. Potenziare il team delle risorse non significa abbandonare la leadership
6. Costruire l’integrità non significa fare un disegno complesso all’inizio
7. Ottimizzare il tutto non significa ignorare i dettagli
Una medicina efficace per un team può essere veleno per un’altro team
(non adottiamo arbitrariamente modalità che sono utilizzate in altre organizzazioni)

24.
Conclusioni
L’analisi delle funzionalità e la loro tracciabilità dipendono dalla funzione
cui è dedicato l’applicativo e la probabilità che questo cambi nel tempo,
quindi attenzione:
• Mettere in orbita un missile non è come l’approvazione un prestito
• Modificare il codice di un mainframe non è come creare una pagina
web statica.
La giusta quantità di interazione richiesta da un applicativo è
direttamente proporzionale agli utilizzatori del sistema, alla loro capacità
tecnica ed alla propensione all’utilizzo di un sistema informatico, quindi
attenzione:
• L’integrità percepita del sistema applicativo deriva dall’interfaccia
utente.
• È molto più difficile «re-ingegnerizzare» gli utenti che riscrivere il
codice.

25.
Relatore - Contatti - Affiliazione