Il documento esplora le metodologie lean e agile, evidenziando l'evoluzione di queste pratiche di sviluppo software dagli anni '70 ad oggi e l'importanza dell'agile manifesto del 2001. Viene presentata una differenza tra modelli predittivi e adattivi, con un focus sull'importanza del feedback e della continua adattabilità nel contesto prossimo del business. Infine, si sottolinea che l'adozione di queste metodologie richiede un cambiamento culturale e una forte motivazione da parte delle aziende.

1. METODOLOGIE LEAN E
AGILE
Una Introduzione

2. METODOLOGIE AGILI: COME
NASCONO
• I primi embrioni di project management evolutivo e di sviluppo SW adattivo
si svilupparono a partire dagli anni 70, ma fu durante gli anni 90 che una
serie di metodologie di sviluppo SW «leggere» si svilupparono in
contrapposizione a tutte quelle metodologie definite «pesanti» che
all’epoca prevalevano.
• Nel Febbraio del 2001,17 sviluppatori SW, fautori di queste metodologie, si
riunirono nello Utah e definirono l’Agile Manifesto che conteneva la filosofia
che queste metodologie condividevano.
• Si narra che la parola «Agile» fosse la seconda nella lista delle proposte per il
nome del movimento, la prima parola era «Adaptive» ma nel 1999 Jim
Highsmith, uno dei firmatari, aveva pubblicato un libro: Adaptive SW
Development e si voleva evitare di legare il movimento al libro.

3. MODELLO PREDITTIVO VS
MODELLO ADATTIVO
• Modello predittivo:
• Basato su un piano a lungo termine (plan driven)
• Scomposizione in fasi ben distinte nella realizzazione del prodotto
• Scomposizione a monte in task dettagliati
• Visione di insieme generalmente risiede in una o poche persone e non condivisa
• Assegnazione di task a «risorse» (che sono responsabili dei solo task assegnati)
• Metriche basate sul piano
• Change Management = Change Resistance (il cambiamento disturba il piano)
• Feedback del team:
• Limitato alla conoscenza del proprio task e alla propria «specializzazione»
(ottimizzazione locale)
• Feedback del cliente:
• solo al termine degli sviluppi

4. MODELLO PREDITTIVO VS
MODELLO ADATTIVO
• Modello adattivo:
• Presuppone che il contesto in cui ci si muova sia complesso e che a priori non sia
noto in dettaglio quali sia e come si svilupperà nel tempo il contesto generale in
cui il progetto si svilupperà.
• Basato sulla produzione di valore per il cliente (value driven)
• Pianificazione a breve termine volta alla produzione del maggior valore possibile nel
minor tempo possibile
• Accrescimento della conoscenza sul prodotto e miglioramento continuo mediante
ciclo di Deming (PDCA)
• Team fisso cross-funzionale auto-organizzato
• Metriche basate sulla delivery di valore
• Change Management = Il cambiamento avviene ad ogni ciclo sulla base dei
feedback.
• Feedback del team: giornaliero basato sul piano a breve termine
• Feedback del cliente: al termine di ogni ciclo

5. MODELLO PREDITTIVO VS
MODELLO ADATTIVO

6. MODELLO PREDITTIVO VS MODELLO
ADATTIVO: LA COMPLESSITÀ
(CYNEFIN)

7. MODELLO PREDITTIVO VS MODELLO
ADATTIVO: LA CHIAVE È IL FEEDBACK

8. AGILE MANIFESTO: I VALORI

9. AGILE MANIFESTO: I PRINCIPI

10. AGILE MANIFESTO: I PRINCIPI

11. LEAN: COME NASCE
• Nasce nel contesto manifatturiero (in particolare automobilstico) dal Toyota
Production System
• Si contrappone alla produzione di massa dell’inizio del 900 creata da Henry
Ford che si proponeva di produrre il maggior numero di auto possibile al
minor costo possibile. La qualità non era al centro del processo in quanto il
processo si inseriva in un contesto monopolista dove la soglia accettabile di
qualità era definita dal produttore.
• Pone al centro del processo di sviluppo:
• La qualità (il valore) percepita dal cliente
• la produttività (alto valore per il cliente a bassi costi)
• Il miglioramento continuo
• L’adattabilità ai cambiamenti

12. LEAN SW DEVELOPMENT: I PRINCIPI
• Eliminate waste (Eliminare gli sprechi). Gli sprechi sono tutto che non aggiunge
valore al prodotto, valore come percepito dal cliente.
The Seven Wastes of Manufacturing The Seven Wastes of Software Development
Inventory Partially Done Work
Extra Processing Extra Processes
Overproduction Extra Features
Transportation Task Switching
Waiting Waiting
Motion Motion
Defects Defects

13. LEAN: I PRINCIPI
• Amplify learning (Amplificare l’apprendimento).
“Lo sviluppo è come creare una nuova ricetta, mentre la produzione è come
cucinare un piatto. Le ricette sono realizzate da chef esperti che hanno
sviluppato un istinto per cosa funziona e la capacità di adattare gli ingredienti
disponibili all’occasione. Non ci si aspetta che gli chef creino la ricetta perfetta
al primo tentative, ci si aspetta che loro producano diverse variant sul tema
come frutto di un processo di apprendimento. Lo sviluppo del SW è concepito al
meglio come un processo di apprendimento simile con la sfida aggiuntiva che I
team di sviluppo sono grandi e che il risultato è molto più complesso di una
ricetta. Il miglior approccio al miglioramento del SW è l’amplificazione
dell’apprendimento”
Tom e Mary Poppendieck

14. LEAN: I PRINCIPI
• Decide as late as possible (Decidi il più tardi possibile).
In contesti di incertezza, le pratiche di sviluppo che consentono di prendere le
decisioni il più tardi possibile sono le più efficaci perchè consentono di creare
più opzioni e di prendere decisioni sulla base delle informazioni che si
acquisiscono nel tempo e non sulla base di speculazioni.
Deliver as fast as possible (Rilascia il più in fretta possibile). Rilasciare in fretta
consente di avere più feedback, di amplificare l’apprendimento e di decidere il
più tardi possibile. La velocità consente ai client di avere quello di cui hanno
bisogno adesso e non quando non ne hanno più bisogno. Comprimere il flusso
di creazione del valore consente di ridurre al Massimo gli sprechi.

15. LEAN: I PRINCIPI
• Empower the team (Dai potere al team).
Coinvolgere gli sviluppatori nei dettagli delle decisioni tecniche è fondamentale
per ottenere l’eccellenza. Le persone in prima linea combinano la conoscenza
dei più piccolo dettagli con la Potenza di molte menti. Quando questi
possiedono la necessaria esperienza se sono guidati da un leader,
prendereanno decisioni tecniche e decisioni di processo migliori di chiunque
altro possa farlo per conto loro. Poichè le decisioni sono prese tardi e la
produzione è veloce, non è possibile per un’autorità centrale orchestrare le
attività dei lavoratori.

16. LEAN: I PRINCIPI
Build Integrity In (Costruisci l’ntegrità all’interno). Un Sistema ha all’interno
integrità quando si comporta esattamente come l’utente si aspetta. Questa si
chiama integrità percepita e deriva principalmente da un’integrità concettuale
che è l’armonia e la coesione tra I vari aspetti del Sistema. Studi di ricerca
hanno mostrato che l’integrità è ottenibile per mezzo di leadership assennata,
esperienza rilevante, comunicazione efficace e disciplina; fattori che non
possono essere sostituiti da procedure, processi e misure.

17. LEAN: I PRINCIPI
See the Whole (Vedi l’insieme).
Gli esperti nelle diverse aree di sviluppo hanno la tendenza a ottimizzare la parte
del prodotto legata alla loro specializzazione e non il prodotto nel suo insieme.
Quando gli individui e le organizzazioni sono valutate per il loro contributo
specialistico, si ottengono delle ottimizzazioni locali a scapito delle prestazioni
globali. E’ necessario che tutti abbiano una visione globale dell’obiettivo che si
intende raggiungere e che contribuiscano collettivamente al suo
raggiungimento.

18. I FRAMEWORK

19. I FRAMEWORK: XP

20. XP: I VALORI
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment
made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we
are proud of and maintain it long term for reasonable costs.
Communication: Everyone is part of the team and we communicate face to face daily. We will work together on everything
from requirements to code. We will create the best solution to our problem that we can together.
Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software
early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not
the other way around.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's
simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept
responsibility and receive authority over our own work.
Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed.
We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.

21. XP: LE REGOLE

22. XP: LE PRATICHE

23. I FRAMEWORK: SCRUM

24. I FRAMEWORK: SCRUM

25. SCRUM: I PILASTRI

26. SCRUM: I VALORI
• Focus
Because we focus on only a few things at a time, we work well together and produce excellent work. We
deliver valuable items sooner.
• Courage
Because we work as a team, we feel supported and have more resources at our disposal. This gives us
the courage to undertake greater challenges.
• Openness
As we work together, we express how we're doing, what's in our way, and our concerns so they can be
addressed.
• Commitment
Because we have great control over our own destiny, we are more committed to success.
• Respect
As we work together, sharing successes and failures, we come to respect each other and to help each
other become worthy of respect.

27. KANBAN

28. KANBAN

29. KANBAN
• Start with what you do now:
Kanban non ti fornisce un nuovo processo, Kanbansi basa sul concetto di
evoluzione e miglioramento del tuo processo corrente.
• Agree to pursue incremental, evolutionary change
L’organizzazione (o il team) deve essere d’accordo su un approccio evolutivo
“gentile”, mirato al miglioramento continuo
• Respect the current process, roles, responsibilities & titles
L’approccio Kanban è “gentile”, l’attuale processo va rispettato e migliorato
sulla base dell’accord al punto precedente.

30. KANBAN: I PRINCIPI
• Visualize the workflow
La visualizzazione del workflow consente di individuare e manipolare le tappe del processo
in cui le informazioni (il valore) vengono aggiunte (ad esempio al termine dell’analisi o del
disegno) facilitando l’organizzazione, l’ottimizzazione e il tracciamento
• Limit WIP (Legge di Little)
Limitare il Work in Process consente di tenere basso il tempo di transito delle feature nella
board
• Manage flow
Tracciando e monitorando il flusso, si possono identificare i problemi e si può valutare
l’efficacia dei cambiamenti apportati.
• Make process policies explicit
E’ importante che sia chiaro a tutti come funziona il processo, in maniera tale che tutti
possano fornire un contributo al suo miglioramento in maniera oggettiva.
• Improve collaboratively
Il team è proprietario e collaborativamente migliora il processo mediante esperimenti e
misure internamente concordate.

31. KANBAN: LE PRATICHE
• Visualize
• Limit work in progress
• Manage flow
• Make policies explicit
• Implement feedback loops
• Improve collaboratively, evolve experimentally.

32. LA LEGGE DI LITTLE
WIP/Ta=TH
WIP= Work in Process
TH= Throughput del sistema (pezzi/h)
Ta= Tempo di attraversamento

33. CONCLUSIONE
• Le metodologie agili e lean hanno nel contesto attuale di alta competizione,
complessità e veloci cambiamenti degli scenari di business una enorme
importanza.
• Esse però si basano su una serie di valori e principi: i vari framework agili
cercano di applicare e facilitare la diffusione dei valori e dei principi ma la
loro adozione non è una condizione sufficiente. Questi anzi rischiano di essere
inutili (se non deleteri) quando non accompagnati dai concetti da cui hanno
preso vita.
• Risulta evidente perciò che le metodologie agili e lean non si «comprano»:
l’adozione di queste metodologie richiede un processo di cambiamento
nella mentalità e nell’approccio allo sviluppo e al business, processo spesso
lento e faticoso (e a sua volta empirico-adattivo) che porta a «essere agile»
e non a «fare agile». Questo processo necessita di forti motivazioni che
devono discendere dalla vision (valori) e dalla mission (principi) aziendali.