Redistributable intro to scrum ita

Un’Introduzione
a Scrum

<il tuo nome qui>
<data>

Mountain Goat Software, LLC

Un’Introduzione a Scrum

Presentata da
<you>
<date>


We’re losing the relay race
“L’approccio ‘a staffetta’ allo sviluppo dei
prodotti ...può entrare in conﬂitto con gli
obettivi di massima velocità e ﬂessibilità.
Invece, un approccio olistico o ‘rugbystico’ -
in cui un team cerca di coprire la distanza
come un’unità, passandosi la palla a vicenda -
puà servire meglio gli odierni requisiti di
competitività.” Hirotaka Takeuchi e Ikujiro Nonaka, “The
New New Product Development Game”,
Harvard Business Review, January 1986.


Scrum in 100 parole
• Scrum è un processo agile che ci permette di
concentrarci sulla consegna del maggior valore
business nel più breve tempo.
• Ci permette di ispezionare software funzionante
rapidamente e ripetutamente (ogni due settimane o
ogni mese)
• Il business stabilisce le priorità. I team si organizzano
per scegliere la strada migliore per consegnare le
funzionalità a priorità più alta.
• Ogni due settimane o ogni mese, chiunque può vedere
il software funzionante e decidere se rilasciarlo così
com’è o continuare a migliorarlo per un altro sprint.


Origini di Scrum
• Jeff Sutherland
• Primi scrum presso Easel Corp nel 1993
• IDX e 500+ persone applicano Scrum
• Ken Schwaber
• ADM
• Presenta Scrum a OOPSLA 96 insieme a
Sutherland
• Autore di tre libri su Scrum
• Mike Beedle
• Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
• Fondano la Scrum Alliance nel 2002, inizialmente
all’interno dell’Agile Alliance

Scrum è stato usato da:
• Microsoft • Nielsen Media
• Yahoo • First American Real Estate
• Google • BMC Software
• Electronic Arts • Ipswitch
• IBM • John Deere
• Lockheed Martin • Lexis Nexis
• Philips • Sabre
• Siemens • Salesforce.com
• Nokia • Time Warner
• Capital One • Turner Broadcasting
• BBC • Oce
• Intuit

Scrum è stato usato per:
• Software commerciale • Sviluppo di videogames
• Sviluppo software in-house • Sistemi life-critical approvati
dall’FDA (Food & Drug
• Sviluppo per conto terzt Administration)
• Progetti “a corpo”
• Software di controllo satellitare
• Applicazioni ﬁnanziarie
• Siti web
• Applicazioni certiﬁcate ISO
• Software per dispositivi
9001 handheld
• Sistemi embedded
• Telefoni cellulari
• Sistemi 24x7 con requisiti di
• Applicazioni di Network
99.999% switching
Finire
• Il Joint Strike Fighter
• Applicazioni di produttori di
software indipendenti


Caratteristiche
• Team che si organizzano da soli
• Progressi del prodotto in una serie di “sprint”
lunghi 2 settimane - 1 mese
• I requisiti sono catturati come voci in un elenco:
“product backlog”
• Non sono prescritte pratiche ingegneristiche
speciﬁche.
• Usa regole generative per creare un ambiente agile
che produca progetti


The Agile Manifesto – una
dichiarazione di valori
Individui ed interazioni più che Processi e strumenti

Fonte: www.agilemanifesto.org


Documentazione
Software funzionante più che
esaustiva



Documentazione
esaustiva

Collaborazione con il Negoziazione dei
più che
cliente contratti



Documentazione
esaustiva

Collaborazione con il Negoziazione dei
più che
cliente contratti

Rispondere al più che Seguire un piano
cambiamento

Livello di rumore del progetto

Lontani da un accordo

Anarchia
Complessi
requisiti

Co
m
pli
ca Fonte: Strategic Management and
ti Organizational Dynamics by Ralph Stacey in
Agile Software Development with Scrum by
Semplici Ken Schwaber and Mike Beedle.
Vicini ad un accordo
Tecnologia
Consolidata

Incerta

Scrum

Return
Gift wrap
Cancel
Product
backlog


Scrum

Sprint
2-4 settimane

Return
Gift wrap
Cancel
Product
backlog


Scrum

Sprint
2-4 settimane
Sprint goal
Return

Gift wrap
Cancel
Product
backlog


Scrum

Sprint
2-4 settimane
Sprint goal
Return
Sprint
backlog
Gift wrap
Cancel
Product
backlog


Scrum

Sprint
2-4 settimane
Sprint goal
Return
Sprint Incremento del prodotto
backlog potenzialmente rilasciabile
Gift wrap
Cancel
Product
backlog


Scrum

Sprint
2-4 settimane
Sprint goal
Return
backlog potenzialmente rilasciabile
Gift wrap
Cancel Coupons
Product
backlog


Scrum

Sprint
2-4 settimane
Sprint goal
Return
Cancel backlog potenzialmente rilasciabile
Coupons
Gift wrap
Product
backlog


Scrum 24 ore

Sprint
2-4 settimane
Sprint goal
Return
Cancel backlog potenzialmente rilasciabile
Coupons
Gift wrap
Product
backlog


Putting it all together

Immagine
disponibile presso
www.mountaingoatsoftware.com/scrum

Sprints
• I progetti Scrum fanno progressi in una serie di
“sprint”
• Analoghi alle iterazioni di Extreme Programming

• La durata tipica è in genere di 2–4 settimane o un
mese di calendario.
• Una durata costante, permette una migliore
cadenza
• Il prodotto è progettato, realizzato e testato
durante lo sprint


Sviluppo sequenziale o
sovrapposto?
Requisiti Design Codice Test

Anziché fare una cosa
sola alla volta...
...gli Scrum team fanno un
po’ di tutto, tutto il tempo

Fonte: “The New New Product Development Game” by Takeuchi
and Nonaka. Harvard Business Review, January 1986.

Non si cambia durante lo sprint

Cambiamenti

• Stabiliamo la durata degli sprint sulla base di
quanto possiamo mantenere i cambiamenti
all’esterno di un singolo sprint.

Scrum framework
Ruoli
• Product owner
• ScrumMaster
• Team Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts

Product owner
• Deﬁne the features of the product
• Decide on release date and content
• Be responsible for the proﬁtability of the
product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed
• Accept or reject work results


The ScrumMaster
• Represents management to the project
• Responsible for enacting Scrum values and
practices
• Removes impediments
• Ensure that the team is fully functional and
productive
• Enable close cooperation across all roles and
functions
• Shield the team from external interferences

The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints


Scrum framework
Ruoli
• Product owner
• ScrumMaster
• Team
Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifacts
• Product backlog
• Sprint backlog
• Burndown charts

Sprint planning meeting
Capacità
del team

Product
backlog

Condizioni
Business

Prodotto
attuale

Tecnologia


Capacità
del team Prioritizzazione Sprint

• Analizzare e valutare il product
Product backlog
backlog • Selezionare gli obiettivi dello
sprint
Condizioni
Business

Prodotto
attuale

Tecnologia


Capacità

• Analizzare e valutare il product Sprint
Product backlog
backlog • Selezionare gli obiettivi dello goal
sprint
Condizioni
Business

Prodotto
attuale

Tecnologia


Capacità

Product backlog
sprint
Condizioni
Pianiﬁcazione Sprint
Business
• Decidere come raggiungere gli
Prodotto obiettivi (design)
attuale • Creare lo sprint backlog (tasks)
partendo dagli Item del product
backlog (user stories / features)
Tecnologia • Stimare lo sprint backlog in ore


Capacità

Product backlog
sprint
Condizioni
Pianiﬁcazione Sprint
Business
• Decidere come raggiungere gli
Prodotto obiettivi (design) Sprint
attuale • Creare lo sprint backlog (tasks)
partendo dagli Item del product backlog
backlog (user stories / features)
Tecnologia • Stimare lo sprint backlog in ore


Sprint planning
• Il Team seleziona dal product backlog gli item che può
impegnarsi a completare
• Viene creato lo Sprint backlog
• Vengono identiﬁcati i Tasks, e ciascuno di questi viene stimato
(1-16 ore)
• Collaborativamente, non dallo ScrumMaster in solitudine
• Consideriamo anche il design di alto livello
Scrivere lo strato business (8
Come pianificatore ore)
di vacanze, voglio Scrivere l’interfaccia utente (4)
vedere le foto degli Scrivere le test ﬁxtures (4)
Scrivere la classe pippo(6)
alberghi. Aggiornare i performance tests
(4)

Il daily scrum (la mischia quotidiana)
• Parametri
• Tutti i giorni
• 15-minuti
• In piedi
• Non è per risolvere i problemi
• Sono tutti invitati
• Solo i membri del team, lo Scrum Master ed il
Product owner hanno diritto di parola.


Ogni membro del team risponde a 3 domande:
1
Cos’hai fatto ieri?

2
Cosa farai oggi?

C’è qualcosa che ti impedisce di 3
farlo?
• Queste non sono un report per lo ScrumMaster
• Sono impegni presi di fronte ai colleghi

La sprint review
• Il team presenta i risultati raggiunti durante lo
sprint
• Di solito, il formato è quello di una demo delle
nuove funzionalità o dell’architettura
sottostante.
• Informale
• Regola:2 ore di preparazione
• Niente slides
• Tutto il team partecipa
• Invitate il mondo

Sprint retrospective
• Periodicamente diamo un occhiata a cosa sta
funzionando e cosa no.
• Tipicamente da15 a 30 minuti
• Fatta al termine di ogni sprint
• Partecipa tutto il team
• ScrumMaster
• Product Owner
• Team
• Possibilmente anche i clienti ed altri ruoli coinvolti

Start / Stop / Continue
• Tutto il team si raduna e discute cose che
vorrebbero:
Iniziare a fare

Smettere di fare
Questo è solo
uno fra molti Continuare a fare
modi di fare una
retrospettiva


Product backlog
• I requisiti
• Una lista di tutto il lavoro
richiesto sul progetto
• Idealmente espresso in modo
tale che ogni item abbia valore
per gli utenti o i clienti del
prodotto
• La priorità degli item è stabilita
dal Product Owner

Questo è il
• La priorità è aggiornata
all’inizio di ogni sprint
product backlog

Esempio di product backlog
Backlog item Stima
Permettere ad un ospite di effettuare una
3
prenotazione
Come ospite, voglio cancellare una prenotazione. 5
Come ospite, voglio cambiare le date di una
3
prenotazione.
Come impiegato dell’hotel, posso lanciare i report
RevPAR (Revenue Per Available Room = Fatturato 8
per camera disponibile)
Migliorare la gestione delle eccezioni 8
... 30
... 50

Sprint goal
• Una breve indicazione dell’obiettivo principale
dello Sprint
Life Sciences
Supportare le features
Database Application necessarie per gli studi genetici
sulla popolazione
Fare girare l’applicazione anche
su SQL Server oltre che su
Oracle. Financial services
Supportare più indicatori
tecnici di quanto faccia ABC
con dati in tempo reale.

Gestire lo sprint backlog
• I singoli individui prendono in carico un compito a loro scelta
• Il lavoro non è mai assegnato

• La stima del lavoro rimanente è aggiornata ogni giorno
• Ciascun membro del team può aggiungere, cancellare o
cambiare lo sprint backlog
• Il lavoro necessario per lo sprint emerge
• Se il lavoro non è chiaro, deﬁnire un item dello sprint backlog
di dimensione maggiore da scomporre successivamente
• Aggiornare il lavoro rimanente man mano che questo viene
riconosciuto


Uno sprint backlog
Tasks Lun Mar Mer Gio Ven
Scrivere la UI 8
Scrivere il middle tier 16
Testare il middle tier 8
Scrivere l’help online 12
Scrivere la classe foo 8


Uno sprint backlog
Scrivere la UI 8 4
Scrivere il middle tier 16 12
Testare il middle tier 8 16
Scrivere la classe foo 8 8


Uno sprint backlog
Scrivere la UI 8 4 8
Scrivere il middle tier 16 12 10
Testare il middle tier 8 16 16
Scrivere la classe foo 8 8 8
Logging degli errori 8


Uno sprint backlog
Scrivere il middle tier 16 12 10 4
Testare il middle tier 8 16 16 11
Scrivere la classe foo 8 8 8 8
Logging degli errori 8 4


Uno sprint backlog
Testare il middle tier 8 16 16 11 8
Scrivere la classe foo 8 8 8 8 8
Logging degli errori 8 4


Uno sprint burndown chart
1,000

800

600
Hours

400

200

0
4/29/02

5/6/02

5/13/02

5/20/02

5/24/02

Scrivere la UI 8
Scrivere il middle tier 16
Testare il middle tier 8

50
40
30
Hours

20
10
0
Lun Mar Mer Gio Ven


Scrivere la UI 8 4
Scrivere il middle tier 16 12
Testare il middle tier 8 16

50
40
30
Hours

20
10
0
Lun Mar Mer Gio Ven


Testare il middle tier 8 16 16 11 8

50
40
30
Hours

20
10
0
Lun Mar Mer Gio Ven


Scalabilità
• Il tipico team è formato da 7 ± 2 persone
• La scalabilità viene ottenuta con team di team
• Fattori chiave per la scalabilità
• Tipo di applicazione
• Dimensione del team
• Dispersione del team
• Durata del progetto
• Scrum è stato usato su diversi progetti
coinvolgenti più di 500 persone


Scaling through the Scrum
of scrums


Scrum of scrums of scrums


Come proseguire
• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com
• scrumdevelopment@yahoogroups.com


Letture consigliate:
• Agile and Iterative Development: A Manager’s Guide di Craig Larman
• Agile Estimating and Planning di Mike Cohn
• Agile Project Management with Scrum di Ken Schwaber
• Agile Retrospectives di Esther Derby e Diana Larsen
• Agile Software Development Ecosystems di Jim Highsmith
• Agile Software Development with Scrum di Ken Schwaber e
Mike Beedle
• Scrum and The Enterprise di Ken Schwaber
• User Stories Applied for Agile Software Development di Mike Cohn
• Un sacco di articoli su www.scrumalliance.org


Copyright notice
Siete liberi:
• di Condividere―di copiare, distribuire e trasmettere il presente
lavoro
• di Riassemblare―di adattare il presente lavoro
Alle seguenti condizioni
• Attribuzione. L’opera deve essere attribuita nel modo speciﬁcato
dall’autore o dal detentore della licenza (ma in nessun modo tale
da suggerire che questi approvino voi o l’uso che fate dell’opera).
Nulla in questa licenza indebolisce o impone restrizioni i diritti
morali dell’autore.


Contatti:
Presentazione di: Mike Cohn
mike@mountaingoatsoftware.com
www.mountaingoatsoftware.com
(720) 890-6110 (ofﬁce)

Siete liberi di rimuo vere
questa (o una qualsiasi)
slide ma per favore
attribuitene la fonte da
qualche parte nella
vostra presentazione


Redistributable intro to scrum ita

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Redistributable intro to scrum ita

Semelhante a Redistributable intro to scrum ita (20)

Redistributable intro to scrum ita

Notas do Editor