Questa presentazione esplora la metodologia Scrum in tutti i suoi aspetti. Illustra nel dettaglio i concetti, gli attori e i processi coinvolti, evidenziando gli errori più comuni che rischiano di minarne l'efficacia.

1. Scrum by the book

2. Francesco Pavone

3. Iniziamo con un piccolo gioco...

4. Regole
● Ogni squadra deve “consegnare” il maggior numero di palline in 2 minuti
● Una pallina per essere “consegnata” deve:
○ essere toccata da tutti i membri del team
○ toccata al massimo da 2 membri del team contemporaneamente
○ essere toccata per ultima dal primo membro del team che l’ha toccata
● Se una pallina tocca per terra non è più valida e deve ripetere il processo

5. Quante palline riuscite a consegnare in 2
minuti?
(avete 30 secondi per stimare)

6. Consegnate...
● Una pallina per essere “consegnata” deve:
○ essere toccata da tutti i membri del team
○ toccata al massimo da 2 membri del team contemporaneamente
○ essere toccata per ultima dal primo membro del team che l’ha toccata
● Se una pallina tocca per terra non è più valida e deve ripetere il processo
2 minuti

7. Controlliamo i risultati...

8. Ancora una volta...

9. Si può fare meglio?
1 minuto per discutere una strategia

10. Consegnate… di nuovo
● Una pallina per essere “consegnata” deve:
○ essere toccata da tutti i membri del team
○ toccata al massimo da 2 membri del team contemporaneamente
○ essere toccata per ultima dal primo membro del team che l’ha toccata
● Se una pallina tocca per terra non è più valida e deve ripetere il processo
2 minuti

11. Controlliamo i risultati...

12. Cos’è Scrum
“L’idea alla base di Scrum è di abilitare un gruppo di persone chiamato Scrum
Team a sviluppare un prodotto in iterazioni di breve durata chiamate Sprint, in
modo da permettere un riorientamento dello sviluppo - una ripianificazione - alla
fine di ogni iterazione. Inoltre ogni iterazione deve consegnare del valore al cliente
finale.”
Pierluigi Pugliese

15. ISPEZIONE

17. ISPEZIONE

18. ISPEZIONE

19. ADATTAMENTO

20. ADATTAMENTO

21. Scrum Team
Product Owner
Team di Sviluppo
Scrum Master

22. Scrum Team
● Specificità nei ruoli
● I ruoli non definiscono vincoli stretti alle responsabilità
● Lavoro Cooperativo
● Tutto lo Scrum Team è responsabile del successo o fallimento del progetto

23. Team di Sviluppo
● Sviluppa attivamente il prodotto
○ Programmatore
○ Tester
○ Analista
○ UX designer
● Cross-Funzionale
○ Svolge tutte le funzioni necessarie allo sviluppo del prodotto
○ Nessuna dipendenza forte
○ Collective Code Ownership
○ Specialista = Collo di bottiglia
■ T-shaped person

24. Product Owner
● Massimizza il valore generato dallo sviluppo
● Responsabile del Product Backlog
○ Presenza di funzionalità
○ Priorità
● Comunica con
○ Stakeholder
○ Team di Sviluppo
● Facilitatore dello sviluppo del prodotto

25. Product Owner

26. Product Owner - Donts
● Canale di trasmissione di informazioni
○ Collo di bottiglia
○ Errori
● Traduttore “Businessish” - “Geekish”
○ Distorsione di informazioni
○ Richieste competenze forti di entrambi i mondi

27. Product Owner - The right way

28. Product Owner - Dos
● Canale diretto tra Stakeholders e Team di Sviluppo
○ Errori di “traduzione” meno probabili
● Product Owner facilitatore
○ Connette le persone giuste al momento giusto
○ Evince le strategie di progetto e le priorità dalle discussioni
○ Riunisce autorità e responsabilità

29. Scrum Master
● Ruolo di allenatore
● Facilitatore
○ Aiuta il team ponendo domande chiave
○ Più raramente dà consigli diretti
○ Ispira la riflessione
● Osservatore esterno al team
○ Guarda il team lavorare per capirne i margini di miglioramento
● Portatore dell’esperienza Scrum
● Risolve gli impedimenti
○ Interazione con il Management
○ Intervento su meccanismi aziendali deleteri
○ Interazione fra Team e altri dipartimenti
○ Ecc

30. Lo Sprint

32. Product Backlog
● Elenco di attività da svolgere
● Lista ordinata di elementi (Product Backlog Items)
● Descrizione di funzionalità del prodotto finito (valore per il customer)
● Ordine deciso dal Product Owner (dopo allineamento con stakeholders)
○ Massimizzare il valore di ogni iterazione

33. Sprint Planning
● Decidere cosa sviluppare nello Sprint
● Il PO determina le priorità
● Il Dev Team determina quanto entra nello Sprint
● Ogni sprint ha un obiettivo specifico
● Risultato: Sprint Backlog

34. Esecuzione Sprint
● Lavorazione degli elementi dello Sprint Backlog
● Collaborazione attiva del team di sviluppo
● Sforzo comune per risolvere i problemi
○ A prescindere dalle specializzazioni dei membri

35. Esecuzione Sprint - Daily Scrum
● Aggiornamento giornaliero per il Team di Sviluppo
● 15 min - Stessa ora - Stesso posto
● Verificare l’andamento dello sviluppo in relazione all’obiettivo dello Sprint
○ Cosa ho fatto ieri
○ Ho incontrato qualche difficoltà
○ Cosa penso di fare oggi
● Correggere eventualmente il tiro

36. Esecuzione Sprint - Product Backlog Refinement
● Preparazione del Product Backlog per i prossimi Sprint
● Parallelo alle attività di sviluppo dello Sprint
● Modalità decise dal team
○ 1 meeting cadenzato
○ Vari meeting
● Se non fatto costantemente il Product Backlog
diventa inutilizzabile (Obsolescenza)

37. Quando ho terminato?
Lo sviluppo è concluso se
soddisfa criteri ...
Generali Specifici
Criteri Condivisi !!!!!
Definition of Done Acceptance Criteria

38. Definition of Done (DoD)
Fare o non fare. Non c’è
“È fatto, deve solo essere testato”

39. Potentially Shippable Product Increment
● Risultato dello Sprint
○ Aggiunta di funzionalità al prodotto
○ Qualità di produzione
○ Minimizzazione rework (undone work)
○ Potenzialmente consegnabile al cliente
PRINCIPIO ATTIVO PIU’
IMPORTANTE DI SCRUM

40. Sprint Review
● Ispezione del prodotto
● lo Scrum Team presenta il prodotto agli Stakeholders
● Risultato: adattamenti al Product Backlog

41. Sprint Retrospective
● Ispezione del processo di sviluppo dello Scrum Team
● Facilitata dallo Scrum Master
● Identificazione di possibili miglioramenti
○ Start Doing
○ Continue Doing
○ Stop Doing
● Miglioramento continuo

42. Facciamo un ultimo sprint… però

43. Regole
● Ogni squadra deve “consegnare” il maggior numero di palline in 2 minuti
● Una pallina per essere “consegnata” deve:
○ essere toccata da tutti i membri del team
○ toccata al massimo da 2 membri del team contemporaneamente
○ essere toccata per ultima dal primo membro del team che l’ha toccata
● Se una pallina tocca per terra non è più valida e deve ripetere il processo
● Non è possibile che 2 membri del team che sono adiacenti tocchino una
pallina contemporaneamente
2 minuti

44. Tiriamo le somme
● Quanto sono state precise le stime iniziali?
● Abbiamo migliorato le performance nelle successive iterazioni?
● Abbiamo migliorato le stime?
● Come abbiamo reagito davanti al cambiamento?

45. Bonus Content

46. Strumenti a supporto di
Scrum
“Persone e interazioni, piuttosto che strumenti e
processi”

47. User Stories
COME <RUOLO>
COSI’ CHE <OBIETTIVO>
VOGLIO <FARE QUALCOSA>

48. User Stories
COME <RUOLO>
COSI’ CHE <OBIETTIVO>
VOGLIO <FARE QUALCOSA>

49. User Stories
Lorem ipsum dolor
sit amet,
consectetur
adipiscing elit. Nam
ullamcorper
molestie tempus.
Morbi tristique
augue non est
cursus efficitur
tincidunt ut elit.
CORPO
CRITERI
ACCETTAZIONE

50. User Stories
● Non sono frutto di un’imposizione dall’alto
● Risultato di
○ Collaborazione
○ Discussione continua
○ Raffinamenti successivi
● Indicano sempre un valore per l’utente finale
● Diverse granularità
○ Epic
○ Funzionalità
○ Storie

51. Stime Agili
● Dare un valore quantitativo ad una Story
○ Story points
○ Ore sviluppo
○ ...
● Basato sul ragionamento durante lo Sprint Backlog Refinement
● Possono essere aggiornate iterativamente

52. Stime Agili - Planning Poker

53. Stime Agili - Planning Poker

54. Stime Agili - Planning Poker

55. Task Board

56. Tasks vs Stories
STORY
Hey, questo mi
interessa!

57. Tasks vs Stories
TASKMmm, questa
roba non mi
interessa!

58. Scomposizione Storie
Scomposizione di Storie in Storie più piccole

59. Scomposizione Storie
Scomposizione di Storie in Task

60. Burn-Down Chart

61. Burn-Down Chart

62. Burn-Down Chart

63. Velocity
● Story Points che il Team di Sviluppo riesce a consegnare nello Sprint
● Indicatore della capacità del lavoro del gruppo
○ Altalenante nei primi Sprint
○ Stabile negli Sprint successivi
● Utile per pianificare gli Sprint futuri

64. Velocity

65. Retrospettiva - Glad / Sad / Mad

66. Riferimenti
J. Sutherland, K. Schwaber (2016) - The Scrum Guide™
P. Pugliese (2016) - Scrum Essenziale
H. Kniberg (2015) - Scrum and XP from the Trenches - 2nd Edition
G. Puliti - Guida galattica per agilisti, Capitolo 3 - Scrum

67. Contatti
@FrancescoKujaku
https://www.linkedin.com/in/francescomariapavone
f.pavone@apuliasoft.com