SlideShare a Scribd company logo

Agile project management 1 giornata - board game - v2

Slide aggiornate del workshop di una giornata con il gioco da tavolo Agile the Board Game che spiega in pratica, usando i lego, come funziona Scrum. Non manca durante la giornata anche l'esercitazione su A3 Reporting, il metodo Lean per apportare continui cambiamenti ai processi eliminando le cause di spreco. Potete usare le slide per divulgare Agile e Lean, anche a livello commerciale. Ricordatevi solo di rispettare i termini della licenza Creative Common :-) Commenti e miglioramenti sempre ben accetti!

1 of 140
Download to read offline
Agile Project Management 
Un giornata di workshop con il gioco Agile: The Board Game e non solo 
Giulio Roggero - Scrum Master,PMI-ACP, PMP, Prince2
E’ un processo Agile? 
Requisito 1 
Requisito 2 
Requisito 3 
Requisito 4 
Analisi Design Sviluppo Test Rilascio
E’ un processo Agile? 
Requisito 1 
Requisito 2 
Requisito 3 
Requisito 4 
Analisi Design Sviluppo Test Rilascio 
Sviluppo Test 
Sviluppo Test 
Iterazione 2 
Iterazione n
E’ un processo Agile? 
Requisito 1 
Requisito 2 
Requisito 3 
Requisito 4 
Analisi Design Sviluppo Test Rilascio 
Design Sviluppo Test 
Design Sviluppo Test 
Iterazione 2 
Iterazione n
E’ un processo Agile? 
Analisi Design Test 
Sviluppo Refactoring Rilascio 
Analisi Design Sviluppo Refactoring 
Rilascio 
Analisi Design Test 
Sviluppo Refactoring 
Rilascio 
Analisi Design Sviluppo Refactoring 
Rilascio 
Requisito 1 
Requisito 2 
Requisito 3 
Requisito 4 
Test 
Test
E’ un processo Agile? 
Test Analisi Design 
Sviluppo Refactoring Rilascio 
Test Analisi Sviluppo Refactoring 
Rilascio 
Design 
Test Analisi Sviluppo Refactoring 
Rilascio 
Test Analisi Sviluppo Refactoring 
Rilascio 
Requisito 1 
Requisito 2 
Requisito 3 
Requisito 4 
Design 
Design

Recommended

Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme ProgrammingErkan Erol
 
What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day? What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day? Stefania Marinelli
 
Overview on Agile, Scrum, Kanban, Extreme programming (XP) and Scaled Agile F...
Overview on Agile, Scrum, Kanban, Extreme programming (XP) and Scaled Agile F...Overview on Agile, Scrum, Kanban, Extreme programming (XP) and Scaled Agile F...
Overview on Agile, Scrum, Kanban, Extreme programming (XP) and Scaled Agile F...Hyder Baksh
 
Scrum 101
Scrum 101Scrum 101
Scrum 101beLithe
 
Agile transformation Explained: Agile 2017 Session
Agile transformation Explained: Agile 2017 SessionAgile transformation Explained: Agile 2017 Session
Agile transformation Explained: Agile 2017 SessionLeadingAgile
 
Agile Scrum Training Process
Agile Scrum Training ProcessAgile Scrum Training Process
Agile Scrum Training ProcessClarion Marketing
 

More Related Content

What's hot

Agile Transformation v1.27
Agile Transformation v1.27Agile Transformation v1.27
Agile Transformation v1.27LeadingAgile
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile MethodologyNiel Deckx
 
Agile Fundamentals
Agile FundamentalsAgile Fundamentals
Agile FundamentalsAtlassian
 
Enterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesEnterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesMike Cottmeyer
 
UnFIX, l’anti framework d’agilité à l’échelle ?
UnFIX, l’anti framework d’agilité à l’échelle ?UnFIX, l’anti framework d’agilité à l’échelle ?
UnFIX, l’anti framework d’agilité à l’échelle ?ThomasClavier5
 
Agile Is the New Waterfall
Agile Is the New WaterfallAgile Is the New Waterfall
Agile Is the New WaterfallNaresh Jain
 
Agile Software Estimation
Agile Software EstimationAgile Software Estimation
Agile Software EstimationSunil Jakkaraju
 
Agile and Scrum for Executives
Agile and Scrum for ExecutivesAgile and Scrum for Executives
Agile and Scrum for ExecutivesJoanna khoury
 
Why agile is failing in large enterprises
Why agile is failing in large enterprisesWhy agile is failing in large enterprises
Why agile is failing in large enterprisesLeadingAgile
 
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)Matthew Philip
 
Beyond the Scrum Master - Becoming an Agile Coach
Beyond the Scrum Master - Becoming an Agile CoachBeyond the Scrum Master - Becoming an Agile Coach
Beyond the Scrum Master - Becoming an Agile CoachCprime
 
Scrum Simulation with LEGO, Agile Game
Scrum Simulation with LEGO, Agile GameScrum Simulation with LEGO, Agile Game
Scrum Simulation with LEGO, Agile GameStanislaw Eysmont
 
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdf
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdfEstimation is dead - long live sizing, by John Coleman 24Nov22.pdf
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdfOrderly Disruption
 

What's hot (20)

Agile Transformation v1.27
Agile Transformation v1.27Agile Transformation v1.27
Agile Transformation v1.27
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile Methodology
 
Introduzione a Scrum
Introduzione a ScrumIntroduzione a Scrum
Introduzione a Scrum
 
Agile Fundamentals
Agile FundamentalsAgile Fundamentals
Agile Fundamentals
 
Enterprise Agile Transformation Strategies
Enterprise Agile Transformation StrategiesEnterprise Agile Transformation Strategies
Enterprise Agile Transformation Strategies
 
UnFIX, l’anti framework d’agilité à l’échelle ?
UnFIX, l’anti framework d’agilité à l’échelle ?UnFIX, l’anti framework d’agilité à l’échelle ?
UnFIX, l’anti framework d’agilité à l’échelle ?
 
Agile Is the New Waterfall
Agile Is the New WaterfallAgile Is the New Waterfall
Agile Is the New Waterfall
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
 
Agile 101
Agile 101Agile 101
Agile 101
 
Scrumban (r)Evolution
Scrumban (r)EvolutionScrumban (r)Evolution
Scrumban (r)Evolution
 
Scrum
ScrumScrum
Scrum
 
Agile Software Estimation
Agile Software EstimationAgile Software Estimation
Agile Software Estimation
 
Agile and Scrum for Executives
Agile and Scrum for ExecutivesAgile and Scrum for Executives
Agile and Scrum for Executives
 
Why agile is failing in large enterprises
Why agile is failing in large enterprisesWhy agile is failing in large enterprises
Why agile is failing in large enterprises
 
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)
Forecasting with Less Effort and More Accuracy (Agile Camp NY 2018)
 
Beyond the Scrum Master - Becoming an Agile Coach
Beyond the Scrum Master - Becoming an Agile CoachBeyond the Scrum Master - Becoming an Agile Coach
Beyond the Scrum Master - Becoming an Agile Coach
 
Scrum Simulation with LEGO, Agile Game
Scrum Simulation with LEGO, Agile GameScrum Simulation with LEGO, Agile Game
Scrum Simulation with LEGO, Agile Game
 
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdf
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdfEstimation is dead - long live sizing, by John Coleman 24Nov22.pdf
Estimation is dead - long live sizing, by John Coleman 24Nov22.pdf
 
Agile ceremonies
Agile ceremoniesAgile ceremonies
Agile ceremonies
 
Agile introduction
Agile introductionAgile introduction
Agile introduction
 

Viewers also liked

Agile Project Management - the Board Game workshop
Agile Project Management  - the Board Game workshopAgile Project Management  - the Board Game workshop
Agile Project Management - the Board Game workshopGiulio Roggero
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project ManagementGiulio Roggero
 
Visualizing the Product - PMI-NIC Agile Workshop 2013
Visualizing the Product - PMI-NIC Agile Workshop 2013Visualizing the Product - PMI-NIC Agile Workshop 2013
Visualizing the Product - PMI-NIC Agile Workshop 2013Giulio Roggero
 
Product Canvas Step-by-Step
Product Canvas Step-by-StepProduct Canvas Step-by-Step
Product Canvas Step-by-StepGiulio Roggero
 
Lean Visual Tools - PMI-NIC Agile Workshop 2013
Lean Visual Tools - PMI-NIC Agile Workshop 2013Lean Visual Tools - PMI-NIC Agile Workshop 2013
Lean Visual Tools - PMI-NIC Agile Workshop 2013Giulio Roggero
 
Agile Seminar at Politecnico di Milano
Agile Seminar at Politecnico di MilanoAgile Seminar at Politecnico di Milano
Agile Seminar at Politecnico di MilanoGiulio Roggero
 
Lavorare meglio e con le persone giuste
Lavorare meglio e con le persone giusteLavorare meglio e con le persone giuste
Lavorare meglio e con le persone giusteGiulio Roggero
 
Agilità interculturale
Agilità interculturaleAgilità interculturale
Agilità interculturaleGiulio Roggero
 
HowTo Design your kanban board
HowTo Design your kanban boardHowTo Design your kanban board
HowTo Design your kanban boardJo Seibert
 
From Vision to Product
From Vision to ProductFrom Vision to Product
From Vision to ProductGiulio Roggero
 
Kanban boards step by step
Kanban boards step by stepKanban boards step by step
Kanban boards step by stepGiulio Roggero
 
5s Score Card
5s Score Card5s Score Card
5s Score Cardokdennis
 
F Square : Framework * Flow : In context of Scrum & Kanban
F Square : Framework * Flow : In context of Scrum & KanbanF Square : Framework * Flow : In context of Scrum & Kanban
F Square : Framework * Flow : In context of Scrum & KanbanJaya S
 
Agile e l’arte di semplificare progetti complessi
Agile e l’arte di semplificare progetti complessiAgile e l’arte di semplificare progetti complessi
Agile e l’arte di semplificare progetti complessiGiulio Roggero
 
Resilient Contracting - Apache Http Server Case Study
Resilient Contracting - Apache Http Server Case StudyResilient Contracting - Apache Http Server Case Study
Resilient Contracting - Apache Http Server Case StudyGiulio Roggero
 
Favorire i feature teams con architetture microservices
Favorire i feature teams con architetture microservicesFavorire i feature teams con architetture microservices
Favorire i feature teams con architetture microservicesGiulio Roggero
 
Le aspettative delle trasformazioni agili
Le aspettative delle trasformazioni agiliLe aspettative delle trasformazioni agili
Le aspettative delle trasformazioni agiliGiulio Roggero
 

Viewers also liked (20)

Agile Project Management - the Board Game workshop
Agile Project Management  - the Board Game workshopAgile Project Management  - the Board Game workshop
Agile Project Management - the Board Game workshop
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Visualizing the Product - PMI-NIC Agile Workshop 2013
Visualizing the Product - PMI-NIC Agile Workshop 2013Visualizing the Product - PMI-NIC Agile Workshop 2013
Visualizing the Product - PMI-NIC Agile Workshop 2013
 
Product Canvas Step-by-Step
Product Canvas Step-by-StepProduct Canvas Step-by-Step
Product Canvas Step-by-Step
 
Lean Visual Tools - PMI-NIC Agile Workshop 2013
Lean Visual Tools - PMI-NIC Agile Workshop 2013Lean Visual Tools - PMI-NIC Agile Workshop 2013
Lean Visual Tools - PMI-NIC Agile Workshop 2013
 
Agile Seminar at Politecnico di Milano
Agile Seminar at Politecnico di MilanoAgile Seminar at Politecnico di Milano
Agile Seminar at Politecnico di Milano
 
Lavorare meglio e con le persone giuste
Lavorare meglio e con le persone giusteLavorare meglio e con le persone giuste
Lavorare meglio e con le persone giuste
 
Agilità interculturale
Agilità interculturaleAgilità interculturale
Agilità interculturale
 
HowTo Design your kanban board
HowTo Design your kanban boardHowTo Design your kanban board
HowTo Design your kanban board
 
From Vision to Product
From Vision to ProductFrom Vision to Product
From Vision to Product
 
Kanban boards step by step
Kanban boards step by stepKanban boards step by step
Kanban boards step by step
 
Agile Apps
Agile AppsAgile Apps
Agile Apps
 
5s Score Card
5s Score Card5s Score Card
5s Score Card
 
F Square : Framework * Flow : In context of Scrum & Kanban
F Square : Framework * Flow : In context of Scrum & KanbanF Square : Framework * Flow : In context of Scrum & Kanban
F Square : Framework * Flow : In context of Scrum & Kanban
 
Agile e l’arte di semplificare progetti complessi
Agile e l’arte di semplificare progetti complessiAgile e l’arte di semplificare progetti complessi
Agile e l’arte di semplificare progetti complessi
 
Resilient Contracting - Apache Http Server Case Study
Resilient Contracting - Apache Http Server Case StudyResilient Contracting - Apache Http Server Case Study
Resilient Contracting - Apache Http Server Case Study
 
Favorire i feature teams con architetture microservices
Favorire i feature teams con architetture microservicesFavorire i feature teams con architetture microservices
Favorire i feature teams con architetture microservices
 
Agile Fixed Price
Agile Fixed PriceAgile Fixed Price
Agile Fixed Price
 
The agile PMO - Agile Business Conference 10.2014 London Michael nir
The agile PMO - Agile Business Conference 10.2014 London Michael nir   The agile PMO - Agile Business Conference 10.2014 London Michael nir
The agile PMO - Agile Business Conference 10.2014 London Michael nir
 
Le aspettative delle trasformazioni agili
Le aspettative delle trasformazioni agiliLe aspettative delle trasformazioni agili
Le aspettative delle trasformazioni agili
 

Similar to Agile project management 1 giornata - board game - v2

ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service ManagementITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service ManagementSimone Onofri
 
Agile raccontato a mia nonna
Agile raccontato a mia nonnaAgile raccontato a mia nonna
Agile raccontato a mia nonnaFelice Pescatore
 
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013  Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013 Fabio Armani
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo
 
Sviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMSviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMMatteo Papadopoulos
 
Agile Project Framework
Agile Project FrameworkAgile Project Framework
Agile Project FrameworkSimone Onofri
 
Alex Di Tommaso - Dal progetto al portafoglio progetti
Alex Di Tommaso - Dal progetto al portafoglio progetti Alex Di Tommaso - Dal progetto al portafoglio progetti
Alex Di Tommaso - Dal progetto al portafoglio progetti Livia Francesca Caruso
 
Agile vs waterfall project management
Agile vs waterfall project managementAgile vs waterfall project management
Agile vs waterfall project managementAndrea Depedri
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesiStefano Muro
 
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiScrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiMarco Da Rin Zanco
 
Introduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanIntroduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanNextre Engineering
 
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Vittorio Polizzi
 
Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Felice Pescatore
 
How Agile Dev Teams work
How Agile Dev Teams workHow Agile Dev Teams work
How Agile Dev Teams workXPeppers
 
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...Mario Gentili
 
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Stefano Saladino
 
Agile Lean Conference 2015 - Agile Software Management (Colonese)
Agile Lean Conference 2015 - Agile Software Management (Colonese)Agile Lean Conference 2015 - Agile Software Management (Colonese)
Agile Lean Conference 2015 - Agile Software Management (Colonese)Agile Lean Conference
 
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference
 

Similar to Agile project management 1 giornata - board game - v2 (20)

ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service ManagementITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
ITSMF Conferenza 2014 - L'officina Agile per innovare l'IT Service Management
 
Agile raccontato a mia nonna
Agile raccontato a mia nonnaAgile raccontato a mia nonna
Agile raccontato a mia nonna
 
Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013  Back to Agile - Codemotion 2013
Back to Agile - Codemotion 2013
 
PMexpo16 - DPO - Workshop
PMexpo16 - DPO - WorkshopPMexpo16 - DPO - Workshop
PMexpo16 - DPO - Workshop
 
Sviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUMSviluppo Agile secondo l'approccio SCRUM
Sviluppo Agile secondo l'approccio SCRUM
 
Agile Project Framework
Agile Project FrameworkAgile Project Framework
Agile Project Framework
 
Alex Di Tommaso - Dal progetto al portafoglio progetti
Alex Di Tommaso - Dal progetto al portafoglio progetti Alex Di Tommaso - Dal progetto al portafoglio progetti
Alex Di Tommaso - Dal progetto al portafoglio progetti
 
Agile vs waterfall project management
Agile vs waterfall project managementAgile vs waterfall project management
Agile vs waterfall project management
 
Agile e Lean in sintesi
Agile e Lean in sintesiAgile e Lean in sintesi
Agile e Lean in sintesi
 
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clientiScrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
Scrum! Sopravvivere e gestire progetti tra polli, maiali e clienti
 
Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)Management per l'innovazione: la metodologia Agile (principi e applicazione)
Management per l'innovazione: la metodologia Agile (principi e applicazione)
 
Introduzione alla Metodologia Scrumban
Introduzione alla Metodologia ScrumbanIntroduzione alla Metodologia Scrumban
Introduzione alla Metodologia Scrumban
 
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
Open Innovation Campus - 05/04/2018 - Agile challenges: essere agili nello sv...
 
Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013Agile@scale - Agile Day 2013
Agile@scale - Agile Day 2013
 
Semplicemente Agile
Semplicemente AgileSemplicemente Agile
Semplicemente Agile
 
How Agile Dev Teams work
How Agile Dev Teams workHow Agile Dev Teams work
How Agile Dev Teams work
 
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...
PMP - Generalità, Project Life Cicle e Organizzazioni, Processi e Aree di con...
 
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
Leonardo Lillo - Progettare lo Smart Working - Rinascita Digitale | DAY #15
 
Agile Lean Conference 2015 - Agile Software Management (Colonese)
Agile Lean Conference 2015 - Agile Software Management (Colonese)Agile Lean Conference 2015 - Agile Software Management (Colonese)
Agile Lean Conference 2015 - Agile Software Management (Colonese)
 
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenzeAgile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
Agile Lean Conference 2016 - Paragano_Agile per vincere le resistenze
 

More from Giulio Roggero

Platform Engineering - a 360 degree view
Platform Engineering - a 360 degree viewPlatform Engineering - a 360 degree view
Platform Engineering - a 360 degree viewGiulio Roggero
 
Kubernetes and CNCF Landscape 101
Kubernetes and CNCF Landscape 101Kubernetes and CNCF Landscape 101
Kubernetes and CNCF Landscape 101Giulio Roggero
 
Platform governance, gestire un ecosistema di microservizi a livello enterprise
Platform governance, gestire un ecosistema di microservizi a livello enterprisePlatform governance, gestire un ecosistema di microservizi a livello enterprise
Platform governance, gestire un ecosistema di microservizi a livello enterpriseGiulio Roggero
 
Modernize Legacy Systems with Kubernetes
Modernize Legacy Systems with KubernetesModernize Legacy Systems with Kubernetes
Modernize Legacy Systems with KubernetesGiulio Roggero
 
Stili architetturali in Kubernetes
Stili architetturali in KubernetesStili architetturali in Kubernetes
Stili architetturali in KubernetesGiulio Roggero
 
Do pair programming with an artificial intelligence
Do pair programming with an artificial intelligenceDo pair programming with an artificial intelligence
Do pair programming with an artificial intelligenceGiulio Roggero
 
Come i Microservizi favoriscono il lavoro dei Feature Teams
Come i Microservizi favoriscono il lavoro dei Feature TeamsCome i Microservizi favoriscono il lavoro dei Feature Teams
Come i Microservizi favoriscono il lavoro dei Feature TeamsGiulio Roggero
 
Microservices, Microfrontends and Feature Teams
Microservices, Microfrontends and Feature TeamsMicroservices, Microfrontends and Feature Teams
Microservices, Microfrontends and Feature TeamsGiulio Roggero
 
Invisible infrastructures
Invisible infrastructuresInvisible infrastructures
Invisible infrastructuresGiulio Roggero
 
Stop Meeting, Start Coding!
Stop Meeting, Start Coding!Stop Meeting, Start Coding!
Stop Meeting, Start Coding!Giulio Roggero
 
Eliminare gli Spaghetti API
Eliminare gli Spaghetti APIEliminare gli Spaghetti API
Eliminare gli Spaghetti APIGiulio Roggero
 
Da spaghetti API a Piattaforma Digitale
Da spaghetti API a Piattaforma DigitaleDa spaghetti API a Piattaforma Digitale
Da spaghetti API a Piattaforma DigitaleGiulio Roggero
 
API Conf 2017 - Allineare il business e la tecnologia grazie alle api
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiAPI Conf 2017 - Allineare il business e la tecnologia grazie alle api
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiGiulio Roggero
 
Progettare l’intangibile - Progettando 2017
Progettare l’intangibile - Progettando 2017Progettare l’intangibile - Progettando 2017
Progettare l’intangibile - Progettando 2017Giulio Roggero
 
Trust me, I'm a developer
Trust me, I'm a developerTrust me, I'm a developer
Trust me, I'm a developerGiulio Roggero
 
Agile Fixed Price - XP Days 2015
Agile Fixed Price - XP Days 2015Agile Fixed Price - XP Days 2015
Agile Fixed Price - XP Days 2015Giulio Roggero
 

More from Giulio Roggero (20)

Platform Engineering - a 360 degree view
Platform Engineering - a 360 degree viewPlatform Engineering - a 360 degree view
Platform Engineering - a 360 degree view
 
Kubernetes and CNCF Landscape 101
Kubernetes and CNCF Landscape 101Kubernetes and CNCF Landscape 101
Kubernetes and CNCF Landscape 101
 
Platform governance, gestire un ecosistema di microservizi a livello enterprise
Platform governance, gestire un ecosistema di microservizi a livello enterprisePlatform governance, gestire un ecosistema di microservizi a livello enterprise
Platform governance, gestire un ecosistema di microservizi a livello enterprise
 
Modernize Legacy Systems with Kubernetes
Modernize Legacy Systems with KubernetesModernize Legacy Systems with Kubernetes
Modernize Legacy Systems with Kubernetes
 
Stili architetturali in Kubernetes
Stili architetturali in KubernetesStili architetturali in Kubernetes
Stili architetturali in Kubernetes
 
Do pair programming with an artificial intelligence
Do pair programming with an artificial intelligenceDo pair programming with an artificial intelligence
Do pair programming with an artificial intelligence
 
Come i Microservizi favoriscono il lavoro dei Feature Teams
Come i Microservizi favoriscono il lavoro dei Feature TeamsCome i Microservizi favoriscono il lavoro dei Feature Teams
Come i Microservizi favoriscono il lavoro dei Feature Teams
 
Scaling Legacy
Scaling LegacyScaling Legacy
Scaling Legacy
 
Agile Journey
Agile JourneyAgile Journey
Agile Journey
 
Microservices, Microfrontends and Feature Teams
Microservices, Microfrontends and Feature TeamsMicroservices, Microfrontends and Feature Teams
Microservices, Microfrontends and Feature Teams
 
Invisible infrastructures
Invisible infrastructuresInvisible infrastructures
Invisible infrastructures
 
Stop Meeting, Start Coding!
Stop Meeting, Start Coding!Stop Meeting, Start Coding!
Stop Meeting, Start Coding!
 
Eliminare gli Spaghetti API
Eliminare gli Spaghetti APIEliminare gli Spaghetti API
Eliminare gli Spaghetti API
 
Innovare nel B2C
Innovare nel B2CInnovare nel B2C
Innovare nel B2C
 
Da spaghetti API a Piattaforma Digitale
Da spaghetti API a Piattaforma DigitaleDa spaghetti API a Piattaforma Digitale
Da spaghetti API a Piattaforma Digitale
 
Kanban board!
Kanban board!Kanban board!
Kanban board!
 
API Conf 2017 - Allineare il business e la tecnologia grazie alle api
API Conf 2017 - Allineare il business e la tecnologia grazie alle apiAPI Conf 2017 - Allineare il business e la tecnologia grazie alle api
API Conf 2017 - Allineare il business e la tecnologia grazie alle api
 
Progettare l’intangibile - Progettando 2017
Progettare l’intangibile - Progettando 2017Progettare l’intangibile - Progettando 2017
Progettare l’intangibile - Progettando 2017
 
Trust me, I'm a developer
Trust me, I'm a developerTrust me, I'm a developer
Trust me, I'm a developer
 
Agile Fixed Price - XP Days 2015
Agile Fixed Price - XP Days 2015Agile Fixed Price - XP Days 2015
Agile Fixed Price - XP Days 2015
 

Agile project management 1 giornata - board game - v2

  • 1. Agile Project Management Un giornata di workshop con il gioco Agile: The Board Game e non solo Giulio Roggero - Scrum Master,PMI-ACP, PMP, Prince2
  • 2. E’ un processo Agile? Requisito 1 Requisito 2 Requisito 3 Requisito 4 Analisi Design Sviluppo Test Rilascio
  • 3. E’ un processo Agile? Requisito 1 Requisito 2 Requisito 3 Requisito 4 Analisi Design Sviluppo Test Rilascio Sviluppo Test Sviluppo Test Iterazione 2 Iterazione n
  • 4. E’ un processo Agile? Requisito 1 Requisito 2 Requisito 3 Requisito 4 Analisi Design Sviluppo Test Rilascio Design Sviluppo Test Design Sviluppo Test Iterazione 2 Iterazione n
  • 5. E’ un processo Agile? Analisi Design Test Sviluppo Refactoring Rilascio Analisi Design Sviluppo Refactoring Rilascio Analisi Design Test Sviluppo Refactoring Rilascio Analisi Design Sviluppo Refactoring Rilascio Requisito 1 Requisito 2 Requisito 3 Requisito 4 Test Test
  • 6. E’ un processo Agile? Test Analisi Design Sviluppo Refactoring Rilascio Test Analisi Sviluppo Refactoring Rilascio Design Test Analisi Sviluppo Refactoring Rilascio Test Analisi Sviluppo Refactoring Rilascio Requisito 1 Requisito 2 Requisito 3 Requisito 4 Design Design
  • 8. Temi • I Introduzione generale: framework e processi per il Project Management. • Lean e Agile: valori e principi. Gemba. Definition of Done. Time Boxing. Kaizen. Kanban. • Scrum: Lean, Agile applicati. Le tre gambe di Scrum. Overview, Ruoli e Workflow. • XP: Ruoli, Attività e Pratiche. • Stimare Costi e Tempi: User Stories, Story Point e Poker Game. • Risk Management e Communication Management • eXtreme Programming: Pair Programming, TDD, Refactoring, CI • Da PMP ad Agile: un modo pratico per introdurre Agile nel team. • Tool Software per Agile: Wiki, Issue Tracker e Continuous Integration. • Agile Scaling. Agile in micro-team. Le certificazioni Agile.
  • 9. Chi sei? Cosa fai? Cosa farai dopo il corso? Cosa ti piacerebbe fare tra cinque anni? Cosa ti aspetti dal corso?
  • 10. Approcci di PM - Predittivo Alcuni esempi •Waterfall •Spirale •Unified Process (RUP) •PMBoK
  • 11. Predittivo – Si / No Pro • Logico e sensato • Pianifica prima di fare • Mantiene una documentazione scritta • Segue un piano • Mantiene le attività organizzate Contro • Sono coinvolte le persone! – Cambiano idea – Difficile esprimere e comunicare l’intangibile e i bisogni – Empatia • Prodotto solo alla fine
  • 12. Approcci di PM - Adattivo Alcuni esempi •XP •Scrum •FDD •TDD •Lean Adattivi Predittivi
  • 13. Adattivo – Si / No Pro • Segue le persone • Apporta valore • Aiuta la collaborazione • Riduce le barriere Contro • Difficile da introdurre • Senza uno sponsor non decolla • Difficile coinvolgere il cliente
  • 14. Quale scegliere? Negli ultimi 30 anni si sono alternati approcci differenti Waterfall RUP XP Kanban Agile Tutti hanno avuto successi e insuccessi
  • 16. Problemi nei progetti • Mancanza della gestione del cambiamento dei requisiti • Cattiva comunicazione • Inadeguatezza del Team • Requisiti non ben definiti • Stime non accurate • Mancanza di un piano di gestione dei Rischi • Cattiva definizione di cosa significa “Finito” • Non dedicare il giusto tempo alla gestione del progetto • Mancanza della conoscenza di come si gestisce un progetto • Essere sempre troppo ottimisti!
  • 18. COCOMO II Fattori che influenzano la produttività nel software su prj da 100 KSLOC. Migliorare i sw tools tipicamente migliora del 50% la produttività. Migliorare il team il 353%! SOFTWARE SEPTEMBER/OCTOBER 2000 (Vol. 17, No. 5) pp. 14-17 0740-7459/00/$26.00 © 2000 IEEE Published by the IEEE Computer Society Safe and Simple Software Cost Analysis
  • 19. Principali fattori di Successo Team + Sponsorship + Cliente
  • 21. Successo Il successo in Agile e’ misurato sul valore generato dal progetto Il valore dipende dal contesto del progetto ed è definito con il Cliente
  • 22. Da PM ad Agile I requisiti non si toccano! Il valore non si tocca!
  • 23. Cercate produttività? Agile non fa per voi! Agile è per: •Apportare facilmente cambiamenti •Creare velocemente valore •Aumentare la trasparenza
  • 24. Agile non e’ • Poca o nessuna documentazione • Requisiti di massima • Nessuna pianificazione • Nessun controllo di progetto • Fare e poi pensare • Un waterfall interattivo
  • 25. Agile Manifesto www.agilemanifesto.org • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 26. Agile Manifesto www.agilemanifesto.org • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 27. Tools e Processi • Quale tool usiamo per tracciare lo stato del progetto? • Che processo adottiamo per rilasciare una versione? • Come tracciamo i bugs? • Come tracciamo le ore su un progetto? • Come misuriamo le performance delle persone sul progetto? • Come formalizziamo con il cliente la chiusura del progetto? • Tutte domande che vi siete fatti almeno una volta … • … che soluzioni avete trovato e adottato?
  • 29. Individui e Interazioni Comunicare, comunicare, comunicare! • Tanti documenti, anche ben scritti e formalizzati non servono se non sono letti e compresi • Presentazioni senza coinvolgere i partecipanti non sono efficaci se non si ha la sicurezza che il messaggio sia compreso Team building • Pensare “al proprio orticello” non aiuta il progetto • Molto spesso lavori complessi hanno bisogno di più occhi • Lavorare in un ambiente armonioso aiuta il progetto Ottimizzare il globale e non il singolo • Misurare il singolo spinge a non collaborare • Non è detto che se tutti sono ottimali il progetto è ottimale
  • 31. Agile Manifesto www.agilemanifesto.org • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 32. Documentazione? • La documentazione è importante, molto importante • E’ importante se è vera • Il progetto evolve la documentazione non sempre! • E’ un costo molto alto tenere aggiornata la documentazione In un progetto software qual’è il documento che rispecchia meglio la realtà?
  • 33. Software! Software funzionante? Si/No/Forse/A volte si/Solo in questo caso no!
  • 34. Agile Manifesto www.agilemanifesto.org • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 35. Contratto • Oggetto del contratto • Elenco Specifiche: A, B, C • Dettaglio Specifiche • Assunzioni e Limiti • Tempi: 3 mo • Costi: 100.000$ • Modalita’ di approvazione del prodotto/servizio • Pagamento • Diritti di recesso Firma e approvazione • Penali 16/06/2011
  • 36. … e dopo un mese? • Oggetto del contratto: OK • Elenco Specifiche: A, B, C, D, E • Dettaglio Specifiche: in realtà C è D+E • Assunzioni e Limiti • Tempi: 4 mo • Costi: 120.000$ • Modalita’ di approvazione del prodotto/servizio • Pagamento • Diritti di recesso • Penali e ora chi paga? Firma e approvazione 16/06/2011
  • 37. Esercizio • L’azienda My Oil S.p.A. deve aggiornare il sistema di monitoraggio delle trivellazioni petrolifere secondo la norma che entrera’ in vigore fra un mese da oggi • Il signor White è l’incaricato di My Oil per fornirvi tutte le informazioni necessarie, l’importante è che il nuovo sistema sia operativo in tutte le 100 sedi entro un mese • Non ci sono limiti di budget Come procedete? • 10’ per discussione • 5’ per gruppo di incontro con il signor White
  • 38. Esempi di contratti “Agili” • A forchetta minima e massima (PERT aiuta) • A condivisione del rischio: 50%-50% sul budget risparmiato • A bande: si concorda il budget, si fissa di volta in volta lo step a prezzo fisso • Time and material classico
  • 39. Agile Manifesto www.agilemanifesto.org • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 40. Quindi? Piano o Valore? VS Una pianificazione è fondamentale Ma la pianificazione deve poter variare senza impattare sul progetto Rispondere ai cambiamenti permette di tenere sotto controllo il vero progetto: •Quello che apporta valore •Soddisfa le aspettative Agile è pianificazione Agile è pianificazione ccoonn uunn ccoonnttrroolllloorree rreettrrooaattttiivvoo
  • 42. Storia Jeff Sutherland introdusse nel 1995 l’idea che i team si muovessero sull’orlo del caos e si auto-controllassero come succede in natura. Ken presento’ con Jeff al OOPSLA95 il primo paper su SCRUM. L’ultima edizione e’ del gennaio 2011 http://jeffsutherland.com/ScrumPapers.pdf Gli autori affermano che: “Scrum non e’ una metodologia o un processo formale ma un algoritmo di compressione delle migliori abitudini in ambito dello sviluppo del software osservate in tutto il mondo negli ultimi 50 anni” jeffsutherland.com kenschwaber.wordpress.com
  • 45. Product Owner Cosa fa  Massimizza il valore di ogni Sprint  Decide quali sono gli item piu’ importanti di ogni Sprint  Puo’ cambiare le priorita’ di volta in volta  Raffina i backlog  Prende le decisioni che impattano sul prodotto Cosa non dovrebbe fare  Il project manager  Sviluppare  Decidere tecnologie e processi
  • 46. Team (pigs) 7 persone ± 2 Cross-funzionale: non solo sviluppatori ma anche tester, interaction design, content managers e tutte le figure professionali necessarie per sviluppare un prodotto di valore Preferibilmente co-located: riduce i tempi di comunicazione e migliora i rapporti del team Full-time sul progetto: le “abitudini” di Scrum prevedono una dedizione al progetto giorno per giorno e un ritmo sostenibile difficilmente da parte di membri del team “multi-tasking” FOCUS!
  • 47. Team (pigs) Cosa fa  Sviluppa il prodotto indicato dal product owner  Da idee al Product Owner su come migliorare il prodotto  Si auto-organizza all’interno dello sprint  Tiene traccia degli item di backlog completati  Stima gg per gg il backlog rimanente Cosa non dovrebbe fare  Implementare item che non sono nell sprint backlog  Aggiungere item allo sprint backlog  Cambia spesso i suoi membri
  • 48. Stakeholders (chickens) • Sono tutti gli appartenenti all’organizzazione che possono essere impattati dal progetto. • Possono partecipare ai meetings ma senza diritto di parola
  • 49. Le persone del team belbin.com • “Plant”: creativa e brava a risolvere i problemi in modi non convenzionali. Uno per team. • Monitor Evaluator: il logico, prende decisioni imparziali e pesa in modo razionale le opzioni del team. • Co-ordinators: aiuta a mantenere il focus del team, fa emerge i membri del team e delega in modo appropriato. • Resource Investigators: migliora i processi e porta la voce del team fuori. • Implementers: il motore che pianifica strategie efficaci e le porta a compimento. • Completer Finishers: intervengo alla fine per completare il task rimuovendo errori e ottimizzando la qualita’. • Teamworkers: sono il collante del team, si identificano con il team e aiutano nel lavoro di squadra. • Shapers: il leader, fa in modo che il team non perda focus e spinta. • “Specialist”: ha una conoscenza molto specifica nella key area del progetto. emerged.
  • 50. Scrum Master • Una persona con backgroud differenti, es: Engineering, Testing, Quality Control, Product Management, Project Management • Energica e umile • Dedicata full-time su grossi progetti • In Team piccoli può essere un membro del Team • ATTENZIONE PM o Team Leaders che diventate Scrum Master: dovete cambiare molto il vostro approccio, è un lavoro completamente diverso! Favorire l’auto-organizzazione!
  • 51. Scrum Master Cosa fa  Tutor del team  Aiuta Team e PO ad avere successo nel progetto  Protegge il Team dai fattori esteri  Facilita le relazioni  Toglie gli impedimenti  E’ al servizio del Team  Aiuta a capire il flow-value dello Scrum Cosa non dovrebbe fare  Il project manager  Il team leader  Il product owner  Assegna Task  Dice alle persone cosa fare
  • 52. Scrum roles – note importanti • Scrum Master e Productr Owner NON possono essere lo stesso individuo • E il Project Manager? NON ESISTE! • I ruoli di PM sono divisi tra i tre ruoli di Scrum: • Scrum Master • Product Owner • Team • Un cambio di approccio è fondamentale! Passare da assegnare attività everificare lo stato (SAL) a Aiutare, supportare, fare coaching e mentoring, rimuovere gli impedimenti Essere al servizio del team!
  • 55. Product Backlog • Lista di features con priorita’ • Roadmap del prodotto • Responsabilita’ del Product Owner • Tutto quello che e’ nel Product backlog e’ il prodotto • Quello fuori NON ESISTE! • Il product backlog evolve nel tempo: • Priorita’ • Descrizione e dettagli (raffinamento del Product Backlog) • Stime • NE ESISTE UNO SOLO
  • 57. Cosa include • Funzionalità/requisiti cliente • Miglioramenti tecnici/tecnologici • Esplorazioni su nuovi aspetti del prodotto/del software • Bugs conosciuti
  • 58. Come viene descritto • Scrum non definisce un metodo • Le user stories sono uno dei metodi piu’ usati • Si possono usare anche Work Breakdown Structure (WBS) • A volte viene creato un Release Backlog come sottoinsieme del BP per definire l’ambito della release del prodotto
  • 59. User Story "As a <role>, I want <goal/desire> so that <benefit>"
  • 61. Una user story su excel User Story ID Front Back Busin alarm.search "As a User I want to search alarms by name, type, application, date, range of dates and free text search so that I can analyze problems on the system" filters are automatically added looking at column names and can be combined in OR and AND (like workflow in console) ess Value Priorit y Estim ated Story Point TBD VH 5
  • 62. Sprint Backlog • L’insieme di task da completare in uno sprint • Uno o piu’ task sono relativi a un item del Product Backlog • Ogni task ha una stima in ore • Ogni task e’ assegnato a una persona che lo richiede in modo volontario
  • 64. Definition of Done • Definizione di completato • Tipicamente e’ una regola di backgroud di tutto il progetto • Es: una feature si considera completata se: • Codificata • Gli unit test sono tutti passed • Il codice e’ commentato • La funzionalita’ e’ utilizzabile dall’utente e soddisfa i requisiti di usabilita’ definiti nella sua user story • E’ integrata nel setup/ambiente di deploy • E’ taggata sotto repository • Ha la documentazione utente La definition of done NON deve variare di volta in volta, e’ fissa! Una volta che e’ decisa si segue sempre quella.
  • 65. PSPI Potentially Shippable Product Increment • Ogni Sprint idealmente finisce con un prodotto potenzialmente rilasciabile • MAI lasciare le cose a meta’: meglio chiudere una cosa in meno e spostarla nel prossimo sprint che lasciare le cose aperte a fine sprint Chiudere sempre secondo la Definition of Done concordata!
  • 66. Motivazioni del PSPI • Permette di raccogliere i feedback velocemente • Riduce i rischi (bugs non alla fine) • Aiuta il cliente finale a prendere confidenza del prodotto • Migliora l’apprendimento
  • 67. Previsioni e Stime 1.Una previsione metereologica e’ valida 1-2 giorni 2.Al terzo giorno e’ gia’ molto incerta 3.Oltre il terzo e’ una speculazione
  • 69. Pianificare in Agile??? • Si pianifica di piu’ e piu’ spesso! • Me tenere sotto controllo il flusso del valore (Value Flow) la pianificazione e la stima sono fondamentali • Riflettere sulle sitme a posteriori aiuta a stimare meglio la volta dopo
  • 70. Stime • Il Product Owner e’ responsabile per assegnare il business value di ogni item del BP • Il Team e’ responsabile per stimare l’effort di sviluppo di ogni item del PB • Il Team e il Product Owner fanno un’analisi di rischio • Lo Scrum Master aiuta in questa fase • Scrum non definisce tecniche di stima • Story Points e Ideal Time • Range Estimation • PERT
  • 71. Stime – Planning Poker • Ogni membro del team si crea delle carte con la sequenza di Fibonacci: 1, 2, 3, 5, 8, 13, 21, BIG • Le user stories sono visibili a muro o sul pavimento o su un tavolo • Lo scrum master sceglie una User Story rappresentativa della quale si conoscono abbastanza dettagli e che sia piccola • Il team concorda che quella vale 1 • Lo Scrum Master scegli un’altra User Story • Ogni membro del team di nascosto sceglie una carta • Quanto tutti hanno scelto scoprono la carta • La maggioranza vince, si discute sulle differenze se ci sono disaccordi e si rivota • Si itera il processo fino a quando non sono finite le User Stories selezionate
  • 72. Esercizio www.agilemanifesto.org I…and i… over p…and t.. W… s… over d… C… c… over c… R.. To c… over p…
  • 73. Esercizio Creare il product backlog con Agile: The Board Game
  • 74. Timeboxing e non solo Lo SPRINT
  • 75. Il tempo non basta mai sett 1 sett 2 sett 3 sett 4 sett 5 DDoonnee DDoonnee DDoonnee
  • 76. Funziona? Pro  Si pensa di essere piu’ produttivi  Diversificare aiuta a non annoiarsi  Si puo’ star dietro a piu’ clienti  Si possono sfruttare i “tempi morti” Contro  Sotto stress  Ore piccole  Tempo perso nel cambio di contesto
  • 77. … e se fossimo monotasking? sett 1 sett 2 sett 3 sett 4 sett 5 DDoonnee DDoonnee DDoonnee
  • 78. Pomodoro Technique • Scegli il task da completare • Imposta il Pomodoro a 25 minuti (Il Pomodoro è il timer) • Lavora sul task senza distrazioni o interruzioni fino a che il Pomodoro non suona, dopo metti una spunta nel tuo foglio della To Do List • Prenditi un piccolo break (5 minuti vanno bene) • Ogni 4 pomodori prenditi una pausa un po' più lunga www.pomodorotechnique.com
  • 79. L’importanza del time-boxing • Aiuta a concentrarsi su una singola attivita’ • Da quell’adrenalina positiva per portare a termine un compito • Permette di semplificare i task • Riduce il lavoro inutile • Incrementa la concretezza (stare con i piedi per terra) • Permette di avere un ritmo nel lavoro (non ci sono piu’ riunioni senza fine che finiscono con un ‘?’) • Aiuta a trovare accordi con se stessi e con il team • Permette di pianificare meglio le attivita’ e stimarne il costo
  • 81. Sprint Planning – Part 1 • Durata: 2-4 ore • Partecipanti: Product Owner, Scrum Master, Team • Strumenti: Product Backlog a muro, Definition of Done • Obiettivo: estrazione degli item per lo sprint
  • 82. Sprint Planning – Part 2 • Durata: 2-4 ore • Partecipanti: Scrum Master, Team • Strumenti: Sprint Backlog a muro • Obiettivo: definizione e stima dei task per lo Sprint Backlog
  • 83. Running the Sprint • Durata: 1-4 settimane (2 consigliate) • Partecipanti: Product Owner, Scrum Master, Team • Strumenti: Product & Sprint Backlog a muro, Definition of Done • Attivita’: • Sviluppo • Rifinitura del Product Backlog (5-10%) • Ri-Stima degli item del backlog • Ri-Prioritizzazione del product backlog • Analisi di dettaglio
  • 84. Daily Meeting • Durata: 15’, ogni gg, alla stessa ora, nello stesso posto (possibilmente in piedi davanti allo Sprint Backlog) • Partecipanti: Scrum Master, Team • Strumenti: Sprint Backlog a muro • Attivita’: • Ogni team member dice: cosa ha fatto, cosa fara’, che impedimenti ha • Si fissano le riunioni
  • 85. Sprint Review • Durata: 2-4 ore • Partecipanti: Product Owner, Scrum Master, Team • Strumenti: PSPI • Obiettivo: validare con il Product Owner la chiusura dello Sprint
  • 86. Misurare in agile Agile metrics
  • 87. Quanto? Misurare solo il necessario e non di più! Vale lo stesso concetto di semplicità che si usa per scrivere il codice Tenere lo storico delle misurazioni
  • 88. Effetti collaterali di metriche errate
  • 89. Misura del progresso “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” Il working software è la principale misura del progresso
  • 90. Running Tested Features Misura diretta del risultato Se non cresce c’è un problema Se cresce è motivante per il team 1 2 3 4 5 6 7 8 9 10 11 12 13 14 12 10 8 6 4 2 0 Running Tested Features RTF Iteration Features
  • 91. Misurare il business value Revenue Cost savings Market share Customer relations Reputation …
  • 92. Financial value 180000 160000 140000 120000 100000 80000 60000 40000 20000 0 Hard Value Delivered per Release Baseline Release 1 Release 2 Release 3 Release 4 Total Revenue Total Costs Profitability Profitability Change
  • 93. Un’idea da Lean Startup Vado a fare un test sperimentale Al 50% degli utenti fornisco il prodotto vecchio All’altro 50% fornisco il prodotto con una nuova feature Misuro entrambi Se ci sono variazioni allora l’introduzione della feature ha influito sul business, altriumenti è indifferente split-test
  • 94. Report in Scrum • Product Burndown Chart • Sprint Burndown Chart • Test reports • Architecture diagram status
  • 96. Velocity = 43 points in 10 days
  • 98. Velocity (misura del team per il team) Osservazione empirica della corrente capacità del team di svolgere il lavoro Quantità di lavoro prodotta in un dato periodo Molto utile per prevedere quando verrà completato un lavoro per una derminata quantità di funzionalità Utile per stimare quanti requisiti saranno rilasciati entro una data prefissata
  • 99. Velocity attenzione a… Basata sulle metriche relative ad un particolare team La dimensione è definita dal team stesso Stories, points, ideal time Non utile al di fuori dell’ambito Solo per un dato team in un dato progetto! Prende in cosiderazione solo il lavoro completato Il team è contento se ha una velocità alta e mantenuta Non solo questo fattore è importante!
  • 100. Esercizio Rilasciare con Scrum il primo PSPI Agile: The Board Game
  • 102. Lean • Ha origini dal TPS (Toyota Production System) sviluppato tra il 1948-1975 • TPS si basa su • Continuo miglioramento - Kaizen • Rispetto per le persone • Una vision a lungo termine • Il giusto processo crea i giusti risultati • Creare valore attraverso lo sviluppo delle persone • Risolvere subito i problemi • Ha due pilastri • Just-in-time • Automation • Due scopi • Ridurre gli sprechi • Dare valore subito al cliente
  • 103. Fresare Saldare Verniciare Assemblare Value Stream Mapping
  • 104. 10 maggiori cause di spreco Qualsiasi cosa che non aggiunge valore al cliente finale e’ considerata uno spreco: 1. Produzione di cose non necessarie 2. Attesa 3. Delegare il lavoro 4. Processi non necessari 5. Lavoro non completato 6. Cambio continuo di attivita’ 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 necessita’ razionali
  • 105. Inbox La posta non letta e’ un esempio di spreco: • Aumento consistente di giorno in giorno della posta non letta (“teoria del vetro rotto”) • Mancanza di evidenza dell’importanza dei vari messaggi • Maggior tempo per discriminare la posta importante da quella meno importante • Lentezza del client di posta! Google ha proposto la priority inbox e funziona! Oppure cancellate la posta che non vi serve 
  • 106. A3
  • 107. Title: What you are talking about. Background Current Situation Goal Analysis Recommendations Plan Follow - up Why are you talking about it? Where do we stand? Where we need to be? What is the specific change you want to accomplish now? -What is the root cause(s) of the problem? - What is your proposed countermeasure(s)? What activities will be required for implementation and who will be responsible for what and when? How we will know if the actions have the impact needed? What remaining issues can be anticipated? A3 -Verble/Shook What’s the problem?
  • 109. Sprint Retrospective • Durata: 1.5-3 ore • Partecipanti: Scrum Master, Team • Strumenti: Sprint Backlog, PSPI • Obiettivo: evidenziare le cose positive dello sprint e ricercare i motivi degli errori, metabolizzare il processo
  • 110. Com’è organizzato • Impostare il meeting – 5% del tempo • Raccogliere i dati – 30-50% del tempo • Approfondire i motivi – 20-30% del tempo • Decidere cosa fare – 15-20% del tempo • Chiudere la retrospettiva – 10% del tempo
  • 111. Esempio di meeting retrospective • Impostare il meeting – ESVP (Esploratore, Shopper, Vacanziere, Prigioniero) • Raccogliere i dati – Timeline • Approfondire i motivi – 5Whys • Decidere cosa fare – SMART Goals (deve essere: Specific, Measurable, Attainable (raggiungibile), Relevant, Timely) • Chiudere la retrospettiva – ROTI (Return of Time Invested) (0-5) Maggiori dettagli su Agile Retrospectives (Derby, Larsen)
  • 112. Esercizio Fare il meeting retrospective Agile: The Board Game
  • 114. non solo SCRUM XP, LEAN E KANBAN
  • 115. Limiti di Scrum • Si tende a pianificare solo lo sprint successivo. • Si tende ad isolare il team dal management. • Si tende ad applicare prima di avere software di qualita’ e testato in modo automatico. • Scrum non dice come fare le cose • Si pensa che i team auto-organizzati, da soli, possano migliorare il processo. Non basta! Il middle-management ha un ruolo findamentale. • La colocation e il single project sono molto utopici.
  • 116. XP - eXtreme programming
  • 117. Pratiche XP • Pair Programming: sviluppare le parti piu’ critiche insieme sullo stesso pc condividendo le scelte e il codice • Test Driven Development: scrivere il test e poi sviluppare la funzionalita’ • Continuos Integration: integrare in modo continuo tutti i componenti software riducendo il rischio di integrazione posticipata • Refactoring: rivedere periodicamente il codice migliorandolo e rendendolo piu’ mantenibile • Collective Code Ownership: il codice sorgente e’ di tutti e tutti sanno metterci le mani • Simple design: tenere sempre il sistema semplice
  • 118. WIP Ridurre il Work In Progress aiuta a: •Aumetare la qualita’ del lavoro finito •Semplificare processi e procedure •Aumentare la reattivita’ a richieste spot •Migliorare la vita in azienda
  • 120. Questa e’ molto molto semplice. Tipicamente si mettono le fasi di progetto e le code di attesa. - WIP limitato - Persone assegnate solo quando server - Continua revisione priorita’ - Piu’ progetti insieme, anche di diversa natura
  • 121. Altro esempio di Kanban board
  • 123. Una ricetta per Kanban • Concentrarsi a rilasciare sempre software di Qualità: TDD, Code Inspection, Architecture and Design Patterns e Software Factories • Ridurre il Work-in-Progress (WIP) • Rilasciare spesso • Bilanciare la domanda di nuove funzionalità con il lavoro che si riesce a smaltire (Throughput) • Dare priorità alle cose • Ridurre le cause di variabilità migliorando la predicibilità da “Kanban: Successful Evolutionary Change for Your Technology Business”
  • 126. Scrum di Scrum • Ogni team lavora con un suo Scrum • Ogni settimana un membro del team si incontra con gli altri membri degli altri team per fare un Daily meeting • Puo’ essere scalato in modo indefinito • I rappresentanti possono cambiare di volta in volta
  • 127. Team Virtuali • E’ possibile applicare Scrum da remoto su team dislocati geograficamenti • E’ difficile farlo funzionare • I tools di comunicazione sono fondamentali, devono permettere un editing live degli oggetti (es: Google Docs) • Chat, Call e Video Call devono essere sempre accessibili • Il repository del codice sempre condiviso • I server di test e di continuos integration hanno un ruolo molto importante perche’ evidenziano i problemi che di solito non emergono naturalmente nei team co-located
  • 128. Cosa evitare • Fare Scrum Team per componenti • Il codice e’ di tutti, non del Team singolo, NO CODICE PRIVATO • Non esistono gruppi speciali: il gruppo degli architect, il gruppo dei designer ecc I gruppi sono Cross Funzionali Feature Teams! SI’!
  • 130. Introdurre una metodologia Agile in Azienda
  • 132. Come aiutare • Fare un A3 della situazione con Value Stream Mapping • Affrontare un problema alla volta • Non cercare di ottimizzare tutto subito • Avere una spinta molto forte dai top-manager • Cercare consenso dal basso • Introdurre un Changing Agent • Chiedere la consulenza di un Coach. Il Coach e’ una persona che riduce di molto la fase di caos e poi se ne va.
  • 134. La chiusura di un progetto Raccogliere le lesson learned Celebrare il successo e imparare degli errori Non disperdere il know-how http://www.svgopen.org/2008/papers/47- Real_time_monitor_in_SVG_a_use_case_in_Machining_Technology_HMI/
  • 135. Le certificazioni Agile • SCRUM - www.scrumalliance.org • Master • Practitioner • Coach • Trainer • PMI-ACP - www.pmi.org • Atern DSDM - www.dsdm.org
  • 136. Links e tools utili casi d'uso: www.scrumalliance.org/resources?tag=experience+report libri consigliati: www.scrumalliance.org/pages/scrum_student_resources presentazioni: www.scrumalliance.org/resources?tag=Presentations docs: www.scrumalliance.org/resources?tag=2010+Shanghai+Gathering fumetti: www.implementingscrum.com/section/blog/cartoons/ contratti: agile rfp - www.methodsandtools.com/archive/archive.php?id=84 agile manifesto: agilemanifesto.org/iso/it/principles.html pmi: pmi.org lean: www.lean.org scrum alliance: www.scrumalliance.org pecha-kucha: www.pecha-kucha.org/
  • 138. Progetti Progetti Complessi Complessi PPeerrssoonnee Mercato e Requisiti dinamici Mercato e Requisiti dinamici Controllare il Progetto Controllare il Progetto Motivare il Team Motivare il Team Prodotti/Servizi di Qualita’ e Valore Prodotti/Servizi di Qualita’ e Valore A G I L E ! Agile quando?
  • 139. Riferimenti Giulio Roggero roggero@intre.it www.intre.it http://it.linkedin.com/in/giuli oroggero
  • 140. Diritti Tutti i cartoon sono di Michael Vizdos - www.implementingscrum.com. Potete usare questo materiale come meglio ritenete opportuno secondo la licenza Creative Common Attribution-ShareAlike 3.0 http://creativecommons.org/licenses/by-sa/3.0/ Trovate altro materiale su http://www.slideshare.net/GiulioRoggero/ I giochi qui utilizzati sono di mia concezione, li trovate Open Source: •http://code.google.com/p/agile-the-board-game/ •http://code.google.com/p/a3-airplane-game/feeds