agile e lean management
TRANSCRIPT
Agile e Lean Management Da dove veniamo e dove stiamo andando…
Simone Onofri - [email protected] Spagnuolo - [email protected]
Cosa intendiamo per Lean?
“Lean” è un termine che descrive un modo di pensare per aumentare l’efficienza ed
eliminare gli sprechi.1500-1900
Studi che partono da Venezia per migliorare il
flusso produttivo.
1900-1990Applicato al mondo manifatturiero dove viene standardizzato
e studiato.
1990-2005Diventa a far parte dei
«Must» della produzione.
2006Viene codificato nello sviluppo software
«Implementing Lean Software
Development» di Mary e Tom Poppendieck.
2011Viene codificato nello sviluppo software
«Lean Startup» di Mary e Eric Ries
Quali sono i principi Lean?Manifatturiero
• Eliminare gli sprechi
• Definire il Valore dal punto di vista del cliente
• Far fluire tutte le attività
• Realizzare un'attività solo quando il processo a valle lo richiede
• Perseguire la perfezione tramite continui miglioramenti (Kaizen)
Software
• Eliminare gli sprechi
• Integrare la qualità
• Creare conoscenza
• Rinviare l’impegno
• Rilasciare velocemente
• Rispettare le persone
• Ottimizzare
Cosa intendiamo per Agile?
“Agile” è un termine “ombrello” che descrivesolo un modo di lavorare collaborativo…
la filosofia Agile è stata declinata in molti modi.
DSDM AgilePF™
AgilePM™ Scrum
SAFe™ XP
Crystal
AUPRAD
DAD
Livelli di gestione:framework e metodologie a confronto
CC-BY-NC-ND Simone Onofri e Claudia Spagnuolo
Gestione del Team e del Prodotto
Gestione e Direzione del
Progetto
Gestione del Programma
Gestione del Portafoglio
ScrumGuide
TecnicheSpecialistiche
e DeliveryXP Lean*
DSDM®AgilePF®
DSDM®AgilePgM®
DAD
DSDM®AgilePM®
SAFe™
PRINCE2®
MSP®
M_o_P®
Sfatiamo un falso mito: Agile = Scrum?
Agile != Scrum
Il (famoso?) manifesto Agile
Gli individui e le interazioni più che i processi e gli strumentiIl software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contrattiRispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,consideriamo più importanti le voci a sinistra.
— Agile Manifesto, 2001
“Agile nasce della necessità di un’alternativa ai processi ‘pesanti’
di sviluppo software,
basati su documentazionee pianificazione massiva,
con lo scopo di scopriremodi migliori di creare software”
— Agile Manifesto, 2001
Sfatiamo un falso mito: con Agile non si fa documentazione? 1/2
“Abbracciamo la documentazione,
ma non centinaia di pagine che nessuno gestisce
e in ‘tomi’ difficilmente utilizzabili”
Sfatiamo un falso mito: con Agile non si fa documentazione? 2/2
— Agile Manifesto, 2001
Sfatiamo un falso mito: con Agile non serve la pianificazione?
“Facciamo la pianificazione, ma ne riconosciamo i limitiin un ambiente turbolento.”
— Agile Manifesto, 2001
Sfatiamo un falso mito: con Agile non servono i Project Manager?
“Il project manager è morto, viva il project manager!”
— Agile Lean Conference, 2016
Agile Team & PM: un esempio
- DSDM © - Reproduced under permission -
Negli organigrammi degli approcci agili di tipo “full” il Project Manager trova posto nella head del progetto, come per esempio nell’AgilePF®.
Il Business Analyst funge da ufficiale di collegamento tra il business e il team di sviluppo.
Ci sono approcci in cui il PM è superfluo?
In molti framework non è previsto il ruolo/figura del PM…
ma ne sono previste le responsabilità… quindi?
Spesso le sue responsabilità sono semplicemente state redistribuite in modo
diverso tra due o più figure.
Conviene sempre essere Agili?
E se in alcuni casi fosse meglio un approccio tradizionale?
Sfatiamo un falso mito: conviene essere Agile? 1/2
Dipende!Bisogna valutare caso per caso. Ma come capirlo?
Sfatiamo un falso mito: conviene sempre essere Agile? 2/2
- Il management è d’accordo ad utilizzare un approccio agile? (Chaosreport)
- Sarà possibile per chi sviluppa la soluzione comunicare velocemente con il Business e/o con gli utenti finali per tutta la durata del progetto? (Chaos report)
- Ci sono vincoli tecnici, contrattuali o altro che impedisca di suddividere la soluzione in sotto-prodotti?
- I requisiti di alto livello sono stati definiti all’inizio del progetto ma è noto a tutti che probabilmente saranno modificati successivamente durante lo sviluppo dei dettagli?
- Le strategie per una continua comunicazione e il metodo di lavoro collaborativo prescelto sono sufficienti a supportare in modo chiaro lo sviluppo iterativo della soluzione?
Che domande porsi?
Il PAQ, Project Approach Questionnaire del DSDM® , è una lista di affermazioni, per
ciascuna delle quali andrebbe definito un livello “intesa” (da 1 a 5), che aiuta ad
individuare i rischi legati alla selezione di un modello Agile.
Una check list già pronta: PAQ
Grazie
The trademarks LEGO® SERIOUS PLAY® and SERIOUS PLAY® by LEGO Group.DSDM® is a trademark registered by DSDM® Consortium
For photo/images credits please refer to the specific slide.
Other material on this presentation is distributed under Creative Common license v3 BY-ND-NC by Simone Onofri. Please contact the author for specific needs.