Presentazione realizzata nell'ambito degli incontri del Programmer User Group Belluno per offrire ai partecipanti una panoramica sul framework scrum.

1. Scrum!
Sopravvivere e gestire progetti
tra polli, maiali e clienti
Belluno, 16 aprile 2015 @larin

2. Toyota Way / Lean
Production
• L’obiettivo di un’azienda è il miglioramento continuo, cercando innovazione ed evoluzione.
• Il rispetto per le persone è alla base di un’azienda: fare il possibile per capirsi l'un l'altro,
prendersi la responsabilità delle proprie azioni e fare del nostro meglio per costruire una
fiducia reciproca.
• Lavoro di squadra: stimolare la crescita personale e professionale, condividere le
opportunità per sviluppare abilità di squadra ed individuali.
• Basa le decisioni manageriali su una filosofia a lungo termine, anche se questo comporta
sacrifici economici a breve termine. Il giusto processo produrrà i giusti risultati
• Costruisci la cultura di fermarsi per correggere i problemi, la qualità come primo obiettivo.
• Usa un sistema di controllo visuale, così non ci saranno problemi nascosti.
• Cresci leader che capiscano veramente il lavoro, che vivano la filosofia dell’azienda e che
la insegnano agli altri.
• Prendi decisioni lentamente. implementa le decisioni rapidamente.

3. Scrum!
Ogniuno ha il suo ruolo. Tutti spingono nella stessa
direzione.

4. A cosa mi serve?
Facciamo un esempio.

5. Gestire un progetto di cui
non sono chiare le
specifiche in fase iniziale.
E vivere felici.

6. Manifesto per lo sviluppo
Agile di Software
Stiamo scoprendo modi migliori di creare software,
sviluppandolo e aiutando gli altri a fare lo stesso.
Grazie a questa attività siamo arrivati a considerare
importanti:
Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei
contratti
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

7. Seguiamo questi principi:
La nostra massima priorità è soddisfare il cliente
rilasciando software di valore, fin da subito
e in maniera continua.
Accogliamo i cambiamenti nei requisiti,
anche a stadi avanzati dello sviluppo.
I processi agili sfruttano il cambiamento
a favore del vantaggio competitivo del cliente.
Consegnamo frequentemente software funzionante,
con cadenza variabile da un paio di settimane a un paio di mesi,
preferendo i periodi brevi.
Committenti e sviluppatori devono lavorare insieme
quotidianamente per tutta la durata del progetto.

8. 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.
Una conversazione faccia a faccia
è il modo più efficiente e più efficace per comunicare
con il team ed all'interno del team.
Il software funzionante è il principale metro di misura di
progresso.
I processi agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in
grado
di mantenere indefinitamente un ritmo costante.

9. La continua attenzione all'eccellenza tecnica
e alla buona progettazione esaltano l'agilità.
La semplicità - l'arte di massimizzare la quantità
di lavoro non svolto - è essenziale.
Le architetture, i requisiti e la progettazione
migliori emergono da team che si auto-organizzano.
A intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
il proprio comportamento di conseguenza.

10. Scrum
Le regole del gioco

11. Parleremo di..
• Ruoli
• Strumenti
• Il “ciclo” di Scrum (sprint cycle)

12. I ruoli nello scrum
Un Maiale ed un Pollo camminavano per
strada.
Il Pollo disse: "Hey Maiale, mi è venuta
una bella idea, potremmo aprire un
ristorante!"
Il Maiale replicò: "Hm, non so, come
potremmo chiamarlo?"
Il Pollo rispose: "Che dici di 'uova e
pancetta'?"
Il Maiale pensò un momento e disse:
"No grazie. Io sarei completamente
coinvolto mentre tu saresti solo
interessato!"

13. I “maiali” dello scrum
1. Product Owner -> rappresenta il cliente
2. Scrum Master -> un maniaco dello scrum
3. Team Master -> I membri del team

14. Il product owner
• Rappresenta il cliente
• Deve massimizzare il ritorno del prodotto in termini di
business.
• Per raggiungere questo obiettivo:
• E’ l’unico autorizzato a chiedere al team di sviluppo
di fare un lavoro e ne detta le priorità.
• Ha la responsabilità di spiegare BENE al team cosa
deve fare.

15. Lo scrum master
• E’ un membro del team di sviluppo.
• Il suo obiettivo è un team motivato, organizzato,
preciso.
• Non è il capo del team! Ma è quello con
maggior esperienza nel metodo scrum.

16. Il team di sviluppo
• Ha completa autonomia sul COME realizzare il
lavoro e su QUANTO tempo richiede.
• Gli elementi sono altamente collaborativi:
l’obiettivo non è FARE IL MIO lavoro ma
raggiungere i risultati nei tempi previsti.

17. Il membro di uno scrum
team in sintesi:
• è responsabile del completamento delle user-
story
• si organizza autonomamente per svolgere tutto il
lavoro che deve fare
• crea ed è responsabile dei preventivi
• decide “come” fare un lavoro
• non risponde mai “non è il mio lavoro"

18. • Lo scrum team ideale è composto dai cinque ai
nove elementi.
• Meno persone difficilmente hanno tutte le
competenze per sviluppare un prodotto
complesso, con più persone è difficile gestire la
fase organizzativa e le comunicazioni.

19. Gli strumenti dello scrum
• Il “product backlog”
• Le “user-story”
• Lo “sprint backlog”
• Definition of “Done”

20. Il product backlog
• è un documento gestito dal product owner. Contiene la lista
delle implementazioni desiderate per un prodotto. Include
nuove caratteristiche, bugfix, modifiche alla documentazione.
• I punti di un product backlog vengono chiamati backlog-item
o “user story”, per ricordare che l’obiettivo di ogni modifica è
rispondere ad un’esigenza dell’utente.
• Queste “storie” sono ordinate in ordine di importanza: le prime
da “evadere” saranno all’inizio della lista. Dovranno essere
brevi e molto chiare per il team. Le storie in fondo alla lista
potranno essere più generiche e meno chiare, tanto passerà
del tempo prima che il team ci lavori.

21. User Story
• Le “cose da fare” nello scrum sono descritti sottoforma di storie.
Una storia dovrebbe contenere queste informazioni:
1. Quale utente ne trarrà benefici
2. Una breve descrizione delle funzionalità desiderate
3. Che scopo ha questa storia
4. Quante ore lavoro richiede l’implementazione di questa
storia*
5. Con che criteri capiamo se l’abbiamo implementata
correttamente*

22. “As a <role>, I want <a feature>, so I can
<accomplish something>”
“Come <ruolo>, Voglio <funzionalità>, in
modo da <obiettivo>”

23. Sprint Backlog
• Sono le story del product backlog che si
puntano a sviluppare durante il ciclo di scrum
corrente (ne parliamo tra poco..)
• A queste si aggiungono le “task”. Ogni story è
composta da più tasks che tutte insieme portano
al completamento della storia: es. aggiungi un
campo al database, inserisci una pagina nella
guida, aggiungi un javascript al menu, ecc.

24. Definition of “Done”
• Un team scrum lo decide a priori, condividendo una
definizione di “fatto”, trasformandola in checklist e
attaccandola dove tutti possono vederla. (es. scrittura
codice, revisione codice, superamento test, scrittura
documentazione).

25. La “liturgia” dello scrum: lo
sprint cycle.
• Pianificazione dello sprint
• Daily Scrum
• Story Time
• Revisione dello sprint
• Team meeting di revisione

26. Lo sprint cycle
Lo “sprint cycle” è il ritmo del processo scrum. All’interno di questo si
prendono in mano poco a poco, pezzettino per pezzettino, dei pezzi di
software, si completano prima di prendere in mano un pezzettino
successivo. Alla fine ci un ciclo di sprint, devi dimostrare di aver prodotto
del software o “sei fottuto”.
Sostanzialmente deve rispettare due requisiti:
• Ha la qualità giusta per essere rilasciato?
• Produce un incremento di valore tale da avere senso sotto il profilo
business?
Il senso di un cycle in scrum è avere feedback continui sui prodotti, in
questo senso più breve è uno sprint meglio è. Normalmente un ciclo dura
2 settimane, ma è sempre maggiore la tendenza di cicli di una settimana.

27. Meeting di pianificazione
dello sprint
• E’ diviso in due parti:
• PARTE PRIMA: Che “user story” vogliamo sviluppare? -> il
“product owner” presenta cosa gli piacerebbe che il team
sviluppasse durante lo sprint. Le richieste vengono strutturate
in “user story” e approfondite finché il team di sviluppo non è
sicuro di averle capite bene. Poi il team decide se può
impegnarsi a sviluppare tutte quelle cose per la fine dello
sprint o se rimandarle a uno sprint successivo.
• NB: la separazione dei ruoli! Il “product owner” decide che
storie dovranno essere prese in considerazione, ma solo
il team decide se sono fattibili o no all’interno di questo sprint.

28. Pianificazione dello sprint
• E’ diviso in due parti:
• PARTE SECONDA: Quali sono le task to-do per ogni
user story? (es. aggiungere un campo al database,
scrivere un aiuto, inserire un menù, ecc). In questa
parte del meeting il “product owner” è a disposizione
per rispondere alle domande.
• DURATA: Da 1 a 2 ore per settimana di sprint.
• RISULTATO: lo sprint backlog. Il product owner si
impegna a non chiedere altro al team durante lo sprint
a meno che la richiesta non arrivi dal team stesso.

29. Daily Scrum
• meeting quotidiano e breve (15 minuti)
• ogni partecipante dice che task ha completato il
giorno precedente, che task conta di completare
durante il giorno, che ostacoli vede.
• Se ci sono dei problemi l’obiettivo è che
emergano in questo meeting, non che vengano
risolti! Le persone più adatte si accorderanno per
confrontarsi dopo il meeting se necessario per
risolvere un problema.

30. Story Time
• Un’ora alla settimana, con il product owner, per
ragionare su possibili “user story” future, sui tempi
da assegnare a ciascuna e per rivedere la
definizione di “fatto” del team.
• In questo meeting si fa “story splitting”: le storie
prossime allo sviluppo devono essere brevi e chiare.
• Anche se lo story-splitting è responsabilità del
product-owner, questo meeting è l’occasione per
chiedere l’aiuto al team di sviluppo.

31. Revisione dello sprint
• E’ la fine dello sprint. E l'occasione per il team di
mostrare quello che ha fatto, per raccogliere
osservazioni, suggerimenti, ecc.
• In questo senso è un meeting che può essere aperto
anche ad esterni - clienti, beta tester, stakeholders, ecc.
• In questo meeting NON si prendono decisioni, è solo un
momento di condivisione e di raccolta di opinioni.
• Durata: dai 30 minuti a 1 ora per ogni settimana di
sprint.

32. Team meeting di revisione
• L’obiettivo dello scrum è la crescita continua e
costante del team. Questo meeting, riservato al
team di sviluppo, è l’occasione per condividere
quello che ha imparato e di identificare uno
o due cambiamenti strategici da testare durante
lo sprint successivo.
• Durata: da 1 a 2 ore per settimana di sviluppo.

33. Ricapitolando.. lo sprint
cycle

34. Tool per gestire lo scrum

35. Tool per gestire lo scrum