Agile Lean Conference 2016 - Barengo _I principi del lean software development
1 like•656 views
Il documento esplora i principi del lean software development, un approccio volto ad aumentare l'efficienza e ridurre gli sprechi, applicando metodologie lean già utilizzate nell'industria. I principi chiave comprendono l'eliminazione degli sprechi, l'apprendimento continuo, la consegna rapida e l'ottimizzazione del lavoro di squadra. L'approccio enfatizza anche l'importanza di costruire integrità nel prodotto e di considerare l'intero sistema piuttosto che singole parti.
Agile Lean Conference 2016 - Barengo _I principi del lean software development
- 1. I principi del Lean Software Development Il Lean Thinking applicato al Software Carlo Barengo – [email protected]
- 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