Agile project management 1 giornata - board game - v2

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

Requisito 1
Requisito 2
Requisito 3
Requisito 4
Sviluppo Test
Sviluppo Test
Iterazione 2
Iterazione n

Requisito 1
Requisito 2
Requisito 3
Requisito 4
Design Sviluppo Test
Design Sviluppo Test
Iterazione 2
Iterazione n

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

Test Analisi Design
Sviluppo Refactoring Rilascio
Test Analisi Sviluppo Refactoring
Rilascio
Design
Rilascio
Rilascio
Requisito 1
Requisito 2
Requisito 3
Requisito 4
Design
Design

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.

Chi sei?
Cosa fai?
Cosa farai dopo il corso?
Cosa ti piacerebbe fare tra cinque anni?
Cosa ti aspetti dal corso?

Approcci di PM - Predittivo
Alcuni esempi
•Waterfall
•Spirale
•Unified Process (RUP)
•PMBoK

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

Approcci di PM - Adattivo
Alcuni esempi
•XP
•Scrum
•FDD
•TDD
•Lean
Adattivi
Predittivi

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

Quale scegliere?
Negli ultimi 30
anni si sono
alternati approcci
differenti
Waterfall
RUP
XP
Kanban
Agile
Tutti hanno avuto successi e insuccessi

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!

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

Principali fattori di Successo
Team + Sponsorship + Cliente

Successo
Il successo in
Agile e’
misurato sul
valore generato
dal progetto
Il valore dipende dal contesto del progetto ed è definito con il Cliente

Da PM ad Agile
I requisiti non si toccano! Il valore non si tocca!

Cercate produttività?
Agile non fa per voi!
Agile è per:
•Apportare facilmente cambiamenti
•Creare velocemente valore
•Aumentare la trasparenza

Agile non e’
• Poca o nessuna
documentazione
• Requisiti di massima
• Nessuna pianificazione
• Nessun controllo di progetto
• Fare e poi pensare
• Un waterfall interattivo

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

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?

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

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à?

Software!
Software funzionante?
Si/No/Forse/A volte si/Solo in questo caso no!

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

… 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

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

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

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

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

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

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!

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
 Implementare item che
non sono nell sprint
backlog
 Aggiungere item allo sprint
backlog
 Cambia spesso i suoi
membri

Stakeholders (chickens)
• Sono tutti gli appartenenti all’organizzazione che possono
essere impattati dal progetto.
• Possono partecipare ai meetings ma senza diritto di parola

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.

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!

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
 Il project manager
 Il team leader
 Il product owner
 Assegna Task
 Dice alle persone cosa fare

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!

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

Cosa include
• Funzionalità/requisiti cliente
• Miglioramenti tecnici/tecnologici
• Esplorazioni su nuovi aspetti del
prodotto/del software
• Bugs conosciuti

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

User Story
"As a <role>, I want <goal/desire> so that <benefit>"

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

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

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.

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!

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

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

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

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

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

Esercizio
www.agilemanifesto.org
I…and i… over p…and t..
W… s… over d…
C… c… over c…
R.. To c… over p…

Esercizio
Creare il product backlog con
Agile: The Board Game

Timeboxing e non solo
Lo SPRINT

Il tempo non basta mai
sett 1 sett 2 sett 3 sett 4 sett 5
DDoonnee
DDoonnee
DDoonnee

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

… e se fossimo monotasking?
sett 1 sett 2 sett 3 sett 4 sett 5
DDoonnee
DDoonnee
DDoonnee

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

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

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

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

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

Daily Meeting
• Durata: 15’, ogni gg, alla stessa ora, nello stesso
posto (possibilmente in piedi davanti allo Sprint
Backlog)
• Strumenti: Sprint Backlog a muro
• Attivita’:
• Ogni team member dice: cosa ha fatto, cosa fara’,
che impedimenti ha
• Si fissano le riunioni

Sprint Review
• Durata: 2-4 ore
• Partecipanti: Product Owner, Scrum Master, Team
• Strumenti: PSPI
• Obiettivo: validare con il Product Owner la chiusura
dello Sprint

Misurare in agile
Agile metrics

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

Effetti collaterali di metriche errate

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

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

Misurare il business value
Revenue
Cost savings
Market share
Customer relations
Reputation
…

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

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

Report in Scrum
• Product Burndown Chart
• Sprint Burndown Chart
• Test reports
• Architecture diagram status

Velocity = 43 points in 10 days

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

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!

Esercizio
Rilasciare con Scrum il primo PSPI

Miglioramento continuo
KAIZEN

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

Fresare Saldare Verniciare Assemblare
Value Stream Mapping

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

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 

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?

Sprint Retrospective
• Durata: 1.5-3 ore
• Strumenti: Sprint Backlog, PSPI
• Obiettivo: evidenziare le cose positive dello sprint e
ricercare i motivi degli errori, metabolizzare il processo

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

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)

Esercizio
Fare il meeting retrospective

non solo SCRUM
XP, LEAN E KANBAN

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.

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

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

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

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”

http://www.slideshare.net/marcusoftnet/kanbanboards

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

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

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’!

Introdurre una metodologia Agile in Azienda

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.

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/

Le certificazioni Agile
• SCRUM - www.scrumalliance.org
• Master
• Practitioner
• Coach
• Trainer
• PMI-ACP - www.pmi.org
• Atern DSDM - www.dsdm.org

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/

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?

Riferimenti
Giulio Roggero
roggero@intre.it
www.intre.it
http://it.linkedin.com/in/giuli oroggero

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

Agile project management 1 giornata - board game - v2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Agile project management 1 giornata - board game - v2

Ähnlich wie Agile project management 1 giornata - board game - v2 (20)

Mehr von Giulio Roggero

Mehr von Giulio Roggero (20)

Agile project management 1 giornata - board game - v2