Agile Project Management

Agile Project Management
Metodologie nuove per gestire progetti complessi
Sunday, February 5, 12

Wallenstein VS Giants

Wallenstein
Ci troviamo nel 1618, alla vigilia
della Guerra dei Trent’Anni, i
cinque più potenti mercenari
dell’epoca si sfidano nella conquista
dell’europa centrale.
Vince chi totalizza piu’ punti
•1 punto viene assegnato per ogni territorio
in proprio possesso.
•1 punto viene assegnato per ogni edificio
costruito sui territori posseduti.
•1 punto viene assegnato al giocatore con più
Mercati in ognuna delle cinque regioni.
•2 punti vengono assegnati al giocatore con più
Cattedrali in ognuna delle cinque regioni.
•3 punti vengono assegnati al giocatore con più
Castelli in ognuna delle cinque regioni

Wallenstein – durante il gioco

Wallenstein - meccanica
Tutti i giocatori hanno, nel turno (tranne in inverno), queste dieci azioni da compiere, una
sola per ogni territorio posseduto:
1. Costruire un Mercato
2. Costruire una Cattedrale
3. Costruire un Castello
4. Primo Movimento (spostamento o attacco)
5. Secondo Movimento (spostamento o attacco)
6. Raccogliere le tasse*
7. Raccogliere il grano *
8. Assoldare cinque armate
9. Assoldare tre armate
10. Assoldare un armata e fare uno spostamento
*Il raccogliere tasse e grano causa lo scontento della popolazione che potrebbe rivoltarsi
Tutti i giocatori sceglieranno, contemporaneamente dove e quali azioni esercitare.
Successivamente verrà stabilito l’ordine di gioco, verrà deciso mischiando e posando sul
tavolo di gioco le carte giocato.

Giants
Ci troviamo sull’Isola di Pasqua tra ul
V e il XVII secolo. La civita’
RapaNui costruisce degli incredibili
monumenti funerari, gli Ahus (ahoo).
Questi monoliti sono scolpiti da una
sola pietra
vulcanica ed eretti sulle sponde
dell’isola.
Il gioco consiste nel costruire i
monumenti funerari in modo
collaborativo. Chi mette a
disposizione piu’ risorse e/o
manodopera e/o erige piu’ Ahus vince.

Giants - meccanica
Ogni giocatore puo’ compiere piu’
azioni per turno:
• Piazzare un lavoratore, uno stregone o
un capo
• Fare una stregoneria
• Erigere un Ahus
I giocatori possono usare i lavoratori
e i pali di legno piazzati dali altri
giocatori per trasportare gli Ahus
vicino alla sponda dell’Isola. Ogni
volta che viene usato il lavoratore di
un altro giocatore questo guadagna
dei punti

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

Benvenuti al CORSO SU AGILE!

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

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, Attivita’ e Pratiche.
Stimare Costi e Tempi: User Stories, Story Point e
Poker Game.
Risk Management e Communication Management
Da PMP ad Agile: un modo pratico per introdurre
Agile nel team.

Approfondimenti
Agile and Scrum Anti-Patterns: cosa si pensa
comunemente di Agile e Scrum che in realta’ non e’
vero
Self organizing teams: esempi reali di aziende auto
organizzate
Pomodoro: tecnica di gestione del tempo e dei task
day by day
Gemba, Kaizen e Kanban: alcuni metodi introdotto in
Toyota e riadattato a diverse realta’ industriali e di
servizi
Forme contrattuali agili: se vogliamo essere agili
dobbiamo esserlo anche nei contratti
Mindmaps

Una sorpresa...

Obiettivi
1. Diventare Agile Project Manager
2. Conoscere i 4 Valori e i 12 Principi di Agile
3. Definire e riconoscere le 10 ragioni di spreco
secondo Lean
4. Conoscere e fare coaching di
Uno Scrum Workflow
Degli Scrum Roles
Delle fasi di stima e pianificazione Agile
5. Creare e mantenere un Product Backlog
6. Spiegare le ragioni di perche’ adottare Agile
7. Analizzare e spiegare perche’ un’azienda non
riesce ad applicare Agile

Altri temi? Vostre proposte
....
....
....
....
....

Introduzione

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

Wallenstein VS Giants
Predittivo Adattivo

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

Osservare
Assimilare
Riealaborare
Migliorare Continuamente

3 lavori predittivi
3 lavori adattivi

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!

Ottimismo!

COCOMO II
Fattori che influenzano
la produttivita’ nel
software su prj da 100
KSLOC.
Migliorare i sw tools
tipicamente migliora del
50% la produttivita’.
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

Definizione di Successo

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

Cercate produttuvita’?
Agile non fa per voi!
Agile e’ per:
•Apportare facilmente
cambiamenti
•Creare velocemente valore
•Aumentare la transparenza

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

Agile e’
• Uno specchio della realta’
• Un processo guidato dal valore
• Un continuo adattamento agli
input esterni (requisiti,
aspettative, ambito) con lo scopo
di massimizzare il valore globale
dell’output (prodotto/servizio/
qualita’/soddisfazione)

Lean e Agile

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?

Teoria della comunicazione
CC Einar Faanes
funzione referenziale (contesto)
funzione emotiva (mittente)
funzione conativa (destinatario)
funzione fàtica (contatto)
funzione poetica (messaggio)
funzione metalinguistica (codice)
Feedback

Teoria dell’ottimizzazione
Ottimizzazione molti-obiettivi
conflittuali
Diverse alternative, diversi decisori,
diversi criteri
Non esiste l’ottimo assoluto ma un
compromesso
L’ottimizzazione locale dei singoli
criteri non porta

Esempio di analisi multi-criteri
alternatives criteria

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 piu’ occhi
Lavorare in un ambiente armonioso aiuta il progetto
Ottimizzare il globale e non il singolo
Misurare il singolo spinge a non collaborare
Non e’ detto che se tutti sono ottimali il progetto e’ ottimale

Interazioni VS Tools?
VS
NO!
I tool sono importanti se rispecchiano il modo di
lavorare del team
Devono ridurre quasi a zero il tempo e il costo
delle operazioni ripetitive
Agevolare la comunicazione remota
Rendere trasparente il progetto
CONSIGLIO:
prima capire le persone e come lavorano poi scegliere i tools di supporto.

esercizio
camminiamo

Documentazione?
La documentazione e’ importante, molto
importante
E’ importante se e’ vera
Il progetto evolve la documentazione non sempre!
E’ un costo molto alto tenere aggiornata la
documentazione
In un progetto software qual’e’ il documento che
rispecchia meglio la realta’?

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

Metodi di Testing
Unit Testing
Integration Testing
User Testing
Interaction Testing
TDD  Test driver development

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
Penali
Firma e
approvazione
16/06/2011

… e dopo un mese?
Oggetto del contratto: OK
Elenco Specifiche: A, B, C, D, E
Dettaglio Specifiche: in realta’ C e’ 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 Trivellazioni Felici 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 e’ l’incaricato di Trivellazioni Felici per
fornirvi tutte le informazioni necessarie,
l’importante e’ 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

Collaborazione con il cliente
Domande di difficile risposta
Che bisogni ha il cliente?
Come lavora il cliente?
Cosa vede il cliente?
Come comunicare con lui?
Quali aspettative ha?
1. Lavorare a stretto contatto con il cliente
2. Respirare la stessa “aria”
3. Avere le stesse aspettative
Fa superare piu’ facilmente la conflittualita’ intrinseca dei contratti

Esempi di contratti “Agili”
•A forchetta minima e massima
(PERT aiuta)
•A bande: si concorda il budget,
si fissa di volta in
volta lo step a
prezzo fisso
•Time and material
classico

Piano
Gantt?
PERT?
Milestones?
Project Management Plan?
Analisi dei Requisiti?
Quante volte questi piani sono stravolti
il giorno dopo che sono stati scritti?

Valore?
Cos’e’ per il Cliente il valore?
Un servizio/un prodotto che apporta valore al
proprio business
Aumenta la competitivita’
Riduce i costi
Aumenta i ricavi
Aumenta la penetrazione di mercato
Alza le barriere di ingresso ai competitor
Crea nuovi mercati
Ecc…
Questi valori sono scolpiti nella pietra o variano nel tempo?

Progetti falliti* ma di valore
Progetto falliti (fuori budget, scope o time)
hanno portato valore in azienda. Ecco alcuni
esempi:
Post-it
Facebook
GMail
* nella accezzione di Scope-Cost-Schedule

Teoria del controllo
Misurare l’output per calibrare gli input

Verificare il software funzionante per validare i
requisiti implementati e pianificati

Quindi? Piano o Valore?
VS
•Una pianificazione e’ 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 e’ pianificazione con un controllore retroattivo

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

Cosa non e’ scrum
Scrum != Ad Hoc
Scrum non e’ una scusa per far meno e costare meno:
- “Non abbiamo bisogno di analisi dei requisiti”
- “Non abbiamo bisogno di stime”
- “Siamo agili!”
FALSO!

Una formula per Scrum?
Scrum = timeboxed iteration + backlogs + meeting giornalieri
NON BASTA SOLO QUESTO!
Implemetare Agile?  NO
Implementare Scrum ed essere Agili  SI’

Ambito
Lean
• 5 Principici
• 10 Cause di Spreco
Agile
• 4 Valori
• 12 Principi
Aspettative
Team
Necessita e Bisogni
Cliente
Valore

Storia
jeffsutherland.com
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”
kenschwaber.wordpress.com

Most common methodologies
Dic 2008

Obiettivi di Scrum
1. Energia
2. Concentrazione sugli obiettivi
3. Chiarezza
4. Transparenza
Auto organizzarsi! INSIEME!

Aiuta a
•Aumentare la velocita’ di sviluppo
•Allineare il progetto con le esigenze
del business
•Creare valore in azienda
•Comunicare in modo costante e trasparente
a tutti i livelli aziendali
•Migliorare l’ambiente di lavoro delle persone

Le tre gambe di Scrum
Trasparenza
Ispezione
Adattamento

Dove si inserisce Scrum

Scrum Roles

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
 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

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 puo’ essere un membro del Team
•ATTENZIONE PM o Team Leaders che diventate
Scrum Master: dovete cambiare molto il vostro
approccio, e’ 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
 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 e’ fondamentale!
Da assegnare attivita’, verificare lo stato a
 Aiutare, supportare, fare coaching e mentoring, rimuovere
gli impedimenti
 Essere al servizio del team!

Scrum Artifacts

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

Esempio – Product backlog

Cosa include
Funzionalita’/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>"

User Story ID Front Back Busin
alarm.searc
h
"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
Priori
ty
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

Product Backlog a muro

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

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

Un momento di analisi del Product

Architettura emergente

Esercizio
Creare il product backlog per la
presentazione di un’idea di
applicazione iPad che favorisca la
diffusione di Agile e di Scrum

Scrum Workflow

Overview

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-6 settimane (2 consigliate)
 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)
 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

Sprint Review
 Durata: 2-4 ore
 Strumenti: PSPI
 Obiettivo: validare con il Product Owner la chiusura
dello Sprint

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

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

Scrum Planning

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

Poker game con Fibonacci

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 – Poker Game
• 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

Stime - PERT
ID Days --> optim
um
likely worst pert var
1 Global
Analysis
1.1 Analysi
s
1,00 1,00 1,00 1,00 0,00
1.2 Design 2,00 2,00 2,00 2,00 0,00
2 Codin
g
2.1 Desktop
container
2.1.1 Window Manager 1,00 2,00 2,00 1,83 0,17
2.1.2 Background 0,20 0,50 1,00 0,53 0,13
2.1.3 Screen resize 0,20 0,20 0,50 0,25 0,05
2.1.4 HTML Integration 0,10 0,20 0,50 0,23 0,07
2.1.5 Unit Testing 0,50 1,00 1,00 0,92 0,08

Re-stimare

Risk analysis
Tenere un registro dei rischi del progetto
Stimare un peso dell’impatto
Stimare una probabilita’ che il rischio possa
manifestarsi
Definire dei piani di contigency
Attribuire dei responsabili ad ogni rischio
Si possono usare analisi di Montecarlo (vedi Riskology
- http://www.systemsguild.com/riskology)
 Tutte le attivita’ di risk vanno nello Sprint
Backlog

Esempio di Risk register
Risk
Category Risk Name Risk
Number
Probability
(1-3)
Impact
(1-3) Risk Score Mitigation Contingency Action By Action When
Guests
The guests
find the
party boring
1.1. 2 2 4
Invite crazy
friends,
provide
sufficient
liquor
Bring out
the karaoke
Mack within 2hrs
Guests
Drunken
brawl
1.2. 1 3 3
Don’t invite
crazy
friends,
don't provide
too much
liquor
Bring in the
guards
Jerry Now
*da wikipedia

Priorita’!
3 variabili
Costo Valore Rischio
Priorita’
Product Owner
Priorita’ massima: minor costo, maggior valore (rischio minimo)

Esercizio
Fare la stima del vostro product backlog

Scrum Reporting

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

Trasparenza a diversi livelli
I Chicken NON devono vedere lo Sprint
Burndowchart
La trasparenza e’ sulle features completate
NON su come il team si auto organizza
Lo sprint backlog e’ per il team, meglio su
carta!

Velocity = 43 points in 10 days

Velocity

Alcuni scrum anti-patterns
•Ottimizzazione prematura del processo
Scrum
•Accumulare lavoro non fatto e continuare a
farne di nuovo
•Lavorare come singoli paladini e non in
Team
•Piu’ di un Product Owner
•Nessun Stakeholder
•“Copiate e migliorate quello che c’era prima”
•Nuove storie sono aggiunte allo Sprint
backlog durante lo sprint (con la scusa

12 Principi di Agile
http://agilemanifesto.org/iso/it/principles.html

“La nostra massima
priorità è soddisfare
il cliente
rilasciando software
di valore, fin da
subito
e in maniera
continua.”
Unit Tesing +
Continuos Integration
Jenkins-CI

Esercizio

“Accogliamo i
cambiamenti nei requisiti,
anche a stadi avanzati
dello sviluppo.
I processi agili sfruttano
il cambiamento
a favore del vantaggio
competitivo del cliente.”
Prendere le decisioni
architetturali il piu’
tardi possibile per
poterle cambiare
quando serve.
Prendere le decisioni
di valore.
Semplicita’!!!!

“Consegnamo
frequentemente software
funzionante,
con cadenza variabile
da un paio di settimane
a un paio di mesi,
preferendo i periodi
brevi.”
Ritmo e buone
abitudini

“Committenti e
sviluppatori devono
lavorare insieme
quotidianamente per
tutta la durata del
progetto.”
Stesso ufficio
openspace
oppure
Video conferenze

“Fondiamo i progetti su
individui motivati.
Diamo loro l'ambiente e
il supporto di cui hanno
bisogno
e confidiamo nella loro
capacità di portare il
lavoro a termine.”
No incentivi singoli
Incentivi sul team
Trasparenza
Comunicazione
Autonomia
Fiducia

“Una conversazione
faccia a faccia
è il modo più
efficiente e più
efficace per
comunicare
con il team ed
all'interno del team.”
Non dire le cose per
email quando si
possono dire di
persona

“Il software funzionante
è il principale metro di
misura di progresso.”
I feedback del cliente
sono la piu’ grande
misura del successo
del progetto

“I processi agili
promuovono uno sviluppo
sostenibile.
Gli sponsor, gli
sviluppatori e gli utenti
dovrebbero essere in grado
di mantenere
indefinitamente un ritmo
costante.” Ritmo sostenibile

“La continua
attenzione
all'eccellenza tecnica
e alla buona
progettazione
esaltano l'agilità.” Eccellenza e
progettazione portano
alla semplicita’

“La semplicità -
l'arte di
massimizzare la
quantità
di lavoro non svolto
- è essenziale.”
Imports System.Console
Class HelloWorld
Public Shared Sub Main()
WriteLine("Hello, world!")
End Sub
End Class

ANTI-IF CAMPAGN
esercizio

“Le architetture, i
requisiti e la
progettazione
migliori emergono
da team che si
auto-organizzano.”
No micro gestione
Si’ ritmo e abitudini
No best practices
Si’ preferred practices

“A intervalli regolari il
team riflette su come
diventare più efficace,
dopodiché regola e
adatta
il proprio
comportamento di
conseguenza.”
Essere leali e obiettivi
Saper gioire per i
successi
Saper riconoscere gli
sbagli
Non vivere con
l’incubo dell’errore ma
con la consapevolezza
di saper riconoscere e
correggere gli errori

5 WHYs
esercizio

Esercizio
A coppie scrivere su un foglio a muro
• 4 valori di Agile
• 12 principi sottostanti ad Agile

Simuliamo un progetto Agile
Agile: The Board Game

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.

XP - eXtreme programming

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

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
•Uno scopo
•Ridurre gli sprechi
•Dare valore subito al cliente

Lean Flow
Spostare l’attenzione dalla creazione del
prodotto al processo produttivo:
“the production flow”
http://www.lean.org/WhatsLean/Principles.cfm

5 principi di Lean
1.Definire il valore, per ogni famiglia di prodotto, dal punto di
vista del cliente finale.
2.Identificare i passi del value stream, per ogni famiglia di
prodotto, eliminando possibilmente tutti gli step che non
creano valore.
3.Assicurarsi che i vari passi del value siano vicini e possano
creare un flusso veloce verso il cliente finale.
4.Una volta che il value stream e’ attivato favorire l’intervento
del cliente per atto ad aumentare il valore degli step.
5.Una volta che il valore e’ definito, il value stream identificato,
gli sprechi rimossi e il flusso introdotto ricominciare di
nuovo il processo fino a quando il valore e’ prodotto senza
sprechi.

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 

Bugs
Una lista molto lunga di bugs “vecchi” non aiuta a
mantenere il flusso di valore:
Se un bug e’ piu’ vecchio di X mesi significa che non
e’ importante (altrimenti sarebbe venuto giu’ il
mondo!)
Avere tanti bugs e non risolverli non aiuta a dare le
giuste priorita’
Meglio mettere nel cassetto
i bugs e riaprire il cassetto quando
si avra’ il tempo
Meglio non avere bugs!

Gemba
In Toyota e’ la pratica di andare a vedere la linea di
produzione
I manager non guardano email, grafici, report, ma
direttamente la linea di produzione
I problemi sono vissuti sul campo, ci si rende conto
della complessita’ e delle persone.
Nei progetti software cos’e’ il Gemba?

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?

Title:
Background
Current Situation
Goal
Analysis
Recommendations
Plan
Follow - up
A3 -Verble/Shook


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

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
Done
Done
Done

Pomodoro Technique
1. Scegli il task da completare
2. Imposta il Pomodoro a 25 minuti
(Il Pomodoro è il timer)
3. 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
4. Prenditi un piccolo break (5 minuti vanno bene)
5.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

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

Kanban Board

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

Altro esempio di Kanban board

Agile anti-patterns
Never meeting iteration commitments
Testing late
Poor estimating
Not trying to improve
Not assigning action items
http://www.agileforall.com/2009/06/03/agile-antipattern-insanity-
5-insanity-antipatterns/
http://agileantipatterns.com/

Scrum#
E’ una evoluzione di Scrum ponendo Scrum all’interno del Lean
Thinking
Rilassa certi aspetti a seconda dei progetti. Es:
Iterazioni: time boxed oppure flow-based.
Prodotto: il team e’ responsabile del prodotto.
Management: i manager guida e fa coach al team. Si lavora
insieme.
Imparare: dal modello del flow con la big picture sempre
presente.
Priorita’: non solo valore per il cliente ma anche sulla
riduzione degli sprechi.
Continuos Integration: build che funzionano in automatico
Acceptance Test: definiti prima di codificare.
Limitare il WIP: non iniziare nuove storie se non sono
concluse quelle precendenti.

Scrum Scaling

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 Agile in Azienda

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.

Una ricetta per Kanban
1. Concentrarsi a rilasciare sempre software di
Qualita': TDD, Code Inspection, Arcihtecture
and Design Patterns e Software Factories
2.Ridurre il Work-in-Progress (WIP)
3.Rilasciare spesso
4.Bilanciare la domanda di nuove funzionalita'
con il lavoro che si riesce a smaltire
(Throughput)
5.Dare priorita' alle cose
6.Ridurre le cause di variabilita' migliorando la
predicibilita'
da “Kanban: Successful Evolutionary Change for Your Technology Business”

Conclusioni

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

Studiare come Scrum Master
Seguire il corso di Scrum Master di due giorni
insegnato da un Scrum Trainer Certificato
Applicare Scrum su un progetto e/o partecipare ad un
progetto Scrum
Studiare il libro di Ken Schware “Agile Project
Management with Scrum”
Sostenere un esame online con 40 domande in 60
minuti.

Studiare per PMI-ACP
Pre-requisiti: 2000h di PM + 1500h di Agile PM + 21h di Training su Agile (16 ore questo
corso)
Studiare i libri:
Agile Project Management with Scrum
The Art of Agile development
User Stories Applied
Agile Estimation and Plannig
Scaling Lean Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
The Software Project Manager's Bridge to Agility
Lean-Agile Software Development: Achieving Enterprise Agility
Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Manager...
Agile Project Management: Creating Innovative Products (2nd Edition)
Agile Retrospectives: Making Good Teams Great
Kanban: Successful Evolutionary Change for Your Technology Business
Inoltre questo link ti da una panoramica di tutte le aree da studiare - http://agiletraining.com/
2011/09/24/pmi-acp-agile-certification-exam-study-tips
Qui l’handbook PMI - http://www.pmi.org/Certification/~/media/PDF/Certifications/PMI-ACP_
Handbook.ashx

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/

Letture consigliate

Progetti
Complessi Persone
Mercato e Requisiti
dinamici
Controllare il
Progetto
Motivare il
Team
Prodotti/Servizi di
Qualita’ e Valore
A
GILE!
Agile quando?

Riferimenti
Giulio Roggero
roggero@intre.it
www.intre.it
http://it.linkedin.com/in/giul ioroggero

Ringraziamenti
Si ringraziano tutti i partecipanti ai corsi 2011 per i preziosi
feedback e la grande partecipazione al corso.
Si ringrazia Michael Vizdos che con i suoi fumetti mi ha ispirato
e divertito - www.implementingscrum.com.
Ringrazio tutti i colleghi di Intré che fanno da cavia per tutte le
mie sperimentazioni.
Ringrazio Elena, Arturo e Edoardo per la pazienza che hanno
avuto durante le mie sere di studio e ricerca.

Agile Project Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Agile Project Management

Similar to Agile Project Management (20)

More from Giulio Roggero

More from Giulio Roggero (20)

Agile Project Management