Lean

1
2
3
 Fordismo vs Toyotismo
• Sfruttamento delle macchine
• Sfruttamento delle persone
• Alti volumi
• Nessuna variabilità
• Razionalizzazione del
processo
• Sistema «spinto» (push)
• Nascondimento dei problemi
• Riduzione degli sprechi
• Crescita delle persone
• Bassi volumi
• Alta variabilità
• Ottimizzazione
del processo
• Sistema «tirato» (pull)
• Evidenziazione dei problemi
 TPS
Shortest lead time
Higest quality Lowest cost

Just in time Jidoka

One-piece flow Automatic stop

Respect Separate machine
Pull system for and operator
people
Takt time Error proofing
Heijunka Visual control

Kaizen Standardization Value chain

5
Che relazione c’è tra
il TPS
e il nostro lavoro
 1948 - 1975
TPS

Lean

1990 - .... Agile

2001 - ...
 Agile Manifesto - 2001

Stiamo scoprendo modi migliori di creare software, sviluppandolo e

aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni

più che i processi e gli strumenti
Il software funzionante
più che la documentazione esaustiva
La collaborazione col cliente
più che la negoziazione dei contratti
Rispondere al cambiamento
più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,

consideriamo più importanti le voci a sinistra.
 Push vs Pull

https://www.youtube.com/watch?v=WmAwcMNxGqM
11
Non creare funzionalità
di cui nessuno ha bisogno

Non scrivere più requisiti

di quelli che puoi codificare

Non scrivere più codice

di quello che puoi testare

Non testare più codice

di quelllo che puoi rilasciare
 Plan

Act Kaizen Do

Check
Ciclo di Deming – Miglioramento continuo
 E’ Muda qualsiasi cosa
che non aggiunge valore al cliente finale

1) Produzione di cose non necessarie

2) Attesa
3) Delegare il lavoro senza dare valore aggiunto
4) Processi non necessari
5) Lavoro non completato
6) Cambio continuo di attività
7) Evidenziare i difetti alla fine del progetto
8) Team che non lavora al suo potenziale
9) Perdita di conoscenza
10) Assecondare i desideri piu’ che le necessità razionali
 Value Stream Mapping – Panini alla nutella

Richiesta Cliente
700 pezzi al giorno

(tempo ciclo – takt time: 38.6 secondi)

Fornitore Cliente

Lead time: 3.4 gg

Value-add time: 99 sec
Spedizione panini vuoti Efficacia: 0.11%

Spedizione panino nutella

700 pz

Applicazione
Preparazione Packaging del Preparazione
nutella al
panino x nutella panino spedizione
panino
359 pz 486 pz 128 pz
tc: 25 sec tc: 30 sec tc: 42 sec tc: 2 sec
1 persona 1 persona 1 persona
1 persona

START 1 gg 0.5 gg 0.7 gg 0.2 gg 1 gg END

25 sec 30 sec 42 sec 2 sec

 Kanban - 看板

Letteralmente significa cartellone

Taiichi Ohno creò questo metodo come uno degli
strumenti per implementare il Just-in-time
Attenzione! Kanban è uno spreco, il numero di
cartellini in circolazione è un obiettivo di
continuo miglioramento!
Kanban usa la Richiesta Cliente per determinare
il Ritmo di Produzione
Giardini del Palazzo Imperiale di Tokyo
Implementare
il flusso pull
Kanban boards step by step
 Perchè Kanban?

• Limitare il Work In Progress del Team

• Bilanciare la domanda e la capacità di produzione del
Team
• Creare un ritmo sostenibile e un clima di collaborazione
• Aumentare la trasparenza
• Allinearsi alle esigenze di business in modo costante
• Evidenziare i colli di bottiglia e le attese
• Aumentare la qualità del lavoro
• Aumentare la predicibilità delle tempistiche
• Ridurre il lead-time
• Gestire più progetti, manutenzioni ed emergenze in un
sol modo
 Regole di Kanban

1. Implementare un flusso pull

2. Definire WIP Limit
3. Aggiornare frequentemente la Kanban Board
 La card

Elementi che vanno su una (ricca) card:

 Requisito
 Funzionalità
ID: MYPRJ-34 Start: 25-11-2012
 User Story
End: ...
 Use Case Type: New Feature
Business Value: 5
Requested: 23-11-2012
 Richiesta di modifica Story Points: 13
Difetto
Deadline: 23-12-2012
 Accepted: ...
 Bug
As a System Administrator I want to manage all
 Manutenzione accounts for MYPRJ from Active Directory so that
 Refactoring I can apply company security policies to MYPRJ
 Miglioramento
Reporter: Bianchi
 Problema bloccante Volunteers: Rossi, Verdi
 Come inserisco la Kanban board nel day-by-day?

Durante lo standup meeting:

La Kanban è aggiornata dal team
Il facilitatore ripercorre la board da destra verso sinistra e identifica:
 Colli di bottiglia
 Attese
 Card bloccate

Dopo lo standup meeting:

 Riunioni in gruppi più piccoli per discutere su funzionalità, problemi
e processi
 In Scrum prima si fa un meeting del team e poi lo Scrum di Scrum
 In Kanban prima il meeting globale e poi il meeting dei team
 Come inserisco la Kanban board nel day-by-day?

Meeting di inserimento elementi in coda:

 Definire priorità e aggiungere elementi alla coda
 Comunemente ogni settimana

Meeting per la pianificazione dei rilasci:

 Tipicamente ogni due settimane
 Cosa sarà rilasciato e quando? Che rischi ci sono e come li
affrontiamo? Chi è coinvolto? Quanto impegherà il rilascio e cosa è
necessario fare dopo il rilascio?
 Come inserisco la Kanban board nel day-by-day?

Triage:
 Viene fatto ad intervalli meno regolari e non frequentemente
 Decidere cosa conservare e cosa eliminare
 Vado cioè a togliere gli elementi dal backlog che non hanno più
senso
 Riduco il magazzino per essere più efficiente! Una regola emprica
è tenere un magazzino massimo di circa 2 mesi (ma dipende!)

Escalation:
 Fatta di frequente o a richiesta
 Rimuovere gli impedimenti al flusso continuo
 Come miglioro l’efficienza di delivery?

• Aumentando la cadenza di delivery!

• Riducendo i tempi di meeting e di review
• Riducendo il magazzino di funzionalità da analizzare e
discutere ad ogni meeting
• Automatizzando il più possibile la gestione di tutte le
operazioni ripetitive che non danno valore al prodotto

27
 Come stabilire il limite del Work-In-Progress

• Non è per forza legato al numero di persone.

• Potrebbe variare molto a seconda della dimensione
media degli elementi della Kanban board
• Empiricamente si è notato che si lavora bene con due
elementi per persona: non è multi-tasking spinto ma
permette di avere un buffer di lavoro quando si è
bloccati su una delle due attività

28
 Caso: Microsoft IT India 2004*
* dal libro Kanban di David Anderson
Punto di partenza:
 3 Devel, 3 Tester, 1 Manager
 Manutenzione di un Prodotto
 CMMI Level 5
 155 giorni da quando arriva la richiesta a quando questa viene rilasciata
I problemi:
 Calcolo della stima in 48h per capire il ROI della modifica
 Ogni mese vengono riprioritizzate circa 80 richieste e il backlog continua ad
aumentare
 Il 90% del lead time è dovuto ad attese
 Le richieste di stima interrompono il flusso e impiegano dal 30 al 40% del
tempo
 I processi sono imposti e il team non ha possibilità di modifica e adattamento

Rimedi?
 Caso: Microsoft IT India 2004 - Rimedi
Eliminazione della fase di stima
 ROI? Costo fisso! In media ci vogliono 11 giorni di lavoro. Le persone sono
comunque pagate a prescindere da quello che fanno.
 Governace (richieste > 15gg un passaggio formale)

Limitare il Work-in-Progress e dimensione coda d’ingresso

Una volta la settimana, e solo una volta la settimana, aggiunta
di nuove richieste e quali vanno scelte

Garanzia di rilascio entro 25 giorni

Miglioramenti dopo un periodo di utilizzo:

 Qualsiasi elemento nel Product Backlog più vecchio di 6 mesi è rimosso. Se è
importante verrà reinserito
 Se durante lo sviluppo ci si accorge che l’attività dura più di 15 giorni si avvisa il
management
Caso: Microsoft IT India 2004 - Risultati

Il backlog da 80 elementi è stato azzerato in 8 mesi.

Il lead time è sceso a 14 giorni. Migliorato > 90%!
Non ci sono stati cambiamenti nel processo di devel e test.
Solo nella gestione delle richieste.
Resistenza minima alla introduzione di questa rivoluzione.
Il completamento del cambiamento è avvenuto in 15 mesi.
 Tools

(The best tool is the wall!)

Stay with a physical board… and remain
 JUST visualize the status without barriers

Selezione e analisi idee di Teams Chiusura

business

Emergenze
Leankit.com
Trello.com
Jira – Atlassian.com
Kanbanize.com
Kanban by David J Anderson – 2007 – ISBN 9780984521401