Agile Lean Conference 2016 - Barengo _I principi del lean software development

25
I principi del Lean Software Development Il Lean Thinking applicato al Software Carlo Barengo – [email protected]

Transcript of Agile Lean Conference 2016 - Barengo _I principi del lean software development

I principi del Lean Software DevelopmentIl Lean Thinking applicato al Software

Carlo Barengo – [email protected]

Lean

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

Cronistoria

1550-1900

Studi chepartono da Venezia (arsenale) per migliorare ilflussoproduttivo

1900-1990

Vieneapplicato alleindustriemanifatturierestandardizzatoe studiato

1990-2005

Lean viene“promosso” edentra a far parte dellemetodologieapplicate allaproduzione

2006

Lean vieneapplicato allosvilupposoftware da parte di M & T Poppendieck

2011

Lean vieneapplicatoanche allesocietàdefinite come startup da E. Ries

Principi Lean e Ambiti

• I principi Lean vengono adottati in ambiti differenti

MANIFATTURIERO Eliminare gli sprechi

Definire il valore dal puntodi vista del Cliente

Far fluire tutte le attività

Realizzare un’attivitàsolamente quando ilprocesso a valle lo richiede(just-on-time)

Perseguire la perfezionetramite miglioramenticontinui (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

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 dallarielaborazione dei principi Lean della produzioneindustriale da parte di Tom e Mary Poppendieck.

• Con le loro pubblicazioni ed i numerosi seminarihanno fatto in modo che siano stati ampiamenteaccettati dalle comunità “Agili” di sviluppatori

I principi Lean

1. Eliminare gli sprechi2. Definire il valore dal punto di vista del cliente3. Far fluire tutte le attività4. Realizzare un’attività solo quando il proceso a valle lo

richiede5. Perseguire la perfezione tramite continui

miglioramenti (Kaizen)

I principi Lean – applicati allo sviluppo SW

1. Eliminare gli sprechi2. Amplificare l’apprendimento3. Decidere il più tardi possibile4. Consegnare rapidamente5. Potenziare il team delle risorse6. Costruire l’integrità7. Ottimizzare il tutto

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

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

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

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 staimpolverando

• Spostare continuamente lo sviluppo da un gruppo di lavoroad un altro

L’ideale è fare esattamente cosa desidera il ns. Cliente, sviluppare e consegnare quando vuole (il prima possibile!)

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.

2- Amplificare l’apprendimentoLo sviluppo è ricerca e scopertaLa 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 unaserie 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

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à

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 principalistrategie Lean per l’eliminazione degli sprechi

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

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.

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.

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.

7 - Ottimizzare il tutto

Un sistema applicativo è composto da parti interdipendenti eche interagiscono fra loro con un obiettivo funzionalegenerale.

Un sistema non è solo una somma di singole funzioni, mal’integrazione fra loro.

Prese singolarmente le funzioni applicative migliori non fannoun sistema applicativo migliore, quindi:

• l’obiettivo si considera centrato per un sistema quando lesingole parti che lo compongono sono integrate e NONcome performano singolarmente.

7 – Ottimizzare il tutto

• Il Systems thinking tratta una organizzazionecome fosse un sistema, analizzando come leparti si relazionano e come sono leperformance del tutto;

• Gli analisti, in genere costruiscono un modellocomputerizzato inserendo dei dati riassuntidalle interviste al personale e ricavandone leregole organizzative.

• Ovviamente ognuno prende delle decisioni inbase ai dati disponibili

• Spesso i risultati dei modelli portano ad unimpatto sulle politiche aziendali che spessonon vengono capite.

• In ogni caso le nuove politiche sono orientatea risolvere un problema non ad eliminarlodefinitivamente

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 crescitaQuindi non continuare a spingere sulla crescita ma concentrarsi sul rimuoverne ilimiti

Conclusioni

Se i problemi odierni dipendono dalle soluzioni di ieri, i problemi di domanidipenderanno 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 documentazione2. Amplificare l’apprendimento non significa cambiare mentalità3. Decidere il più tardi possibile non significa procrastinare all’infinito4. Consegnare rapidamente non significa correre e fare un lavoro sciatto5. Potenziare il team delle risorse non significa abbandonare la leadership6. Costruire l’integrità non significa fare un disegno complesso all’inizio7. 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)

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.

Relatore - Contatti - Affiliazione