Il documento offre una panoramica dettagliata del framework Scrum, evidenziando la sua importanza nell'approccio agile allo sviluppo software. Vengono descritti i ruoli chiave nel team Scrum, inclusi il Product Owner, lo Scrum Master e il Development Team, insieme ai principali artefatti e cerimonie che favoriscono la collaborazione e l'efficienza. Infine, viene sottolineata la centralità dei valori e dei principi agili, che guidano la realizzazione di software di alta qualità attraverso iterazioni frequenti e feedback continuo.

1. Scrum Framework
Agile@Core
Felice Pescatore

2. Agile@Core: Scrum2
get in touch
ABOUT ME
felice.pescatore@gmail.com
Agile Coach – Agile Enterprise Architect
Microsoft MVP Visual Studio ALM
GetLatestVersion.it il primo sito in
italiano sull'Application Lifecycle
Management
felicepescatore.it
@felicepescatore
Felice Pescatore
Disciplined Agile Delivery Italy Group

3. Agile@Core: Scrum3
Team di Sviluppo
Cliente

4. Agile@Core: Scrum4

5. Agile@Core: Scrum5
Deadline make all angry and crazy!

6. Agile@Core: Scrum6
Waterfall approach
… not bad every times!
Problem: known
Solution: known (?)
Aspetti critici:
• Si suppone di conoscere
approfonditamente il problema
• Si suppone di poter progettare in anticipo
(big-up front) la soluzione di dettaglio
• Al passaggio alla nuova fase, la precedente
è ritenuta conclusa e immodificabile
• I feedback del cliente arrivano solo alla fine

7. Agile@Core: Scrum7
Waterfall in practice

8. Agile@Core: Scrum8
Value Guided Approach
… modern approach!
Con “Agile” non si intende un insieme di processi e tool, bensì un set di Valori e Pratiche su cui
basare le proprie attività, e, perché no, I processi e i tool utilizzati.
Problem: known
Solution: unknown

9. Agile@Core: Scrum9
Agile Values

10. Agile@Core: Scrum10
Agile Principles
Gli individui e le interazioni
• Fondare lo sviluppo del progetto su individui
motivati, fiducia nella loro capacità di portare a
termine il lavoro
• Fornire l’ambiente e supporto agli individui
• Conversazioni frequenti faccia a faccia con il team
e all’interno del team
• Ritmo e interazioni costanti
• Ad intervalli regolari il team riflette su come
diventare più efficace, dopodiché regola e adatta
il proprio comportamento di conseguenza
La collaborazione col cliente
• Collaborazione costante anche quotidiana tra
committenti e sviluppatori
Il software funzionante
• Rilascio funzionante del software
• Rilascio continuo del software, in maniera
incrementale e con cadenza variabile da
bisettimanale a mensile
• Software funzionante come misura del progresso
di sviluppo
• Attenzione all'eccellenza tecnica e alla buona
progettazione esaltano l'agilità
• La semplificazione come l'arte per massimizzare
la quantità di lavoro non svolto - è essenziale.
Rispondere al cambiamento
• Sfruttare le richieste di cambiamento in itinere
anche a stadi avanzati a vantaggio dello
sviluppo competitivo del cliente

11. Agile@Core: Scrum11
Agile Software Development
… agilemanifesto.org
Agile Philosophy
• Sistemi complessi e progetti con caratteristiche non lineari e dinamiche;
• Stabilità, accuratezza e predicibilità sono difficili da ottenere nelle fasi iniziali;
• La progettazione big-up front è un’inutile spreco.
Adaptive (Agile) vs. Predictive
• Planning adattativo, rilascio as-soon-as-possible, miglioramenti continui;
• Team autorganizzati e cross-funzionali;
• Risposta veloce al cambiamento.
Iterative vs. Waterfall
• Processi iterativi, incrementali e in continua evoluzione (adattativi);
• Comunicazione face-to-face;
• Ottenimento rapido dei feedback e ciclo di adattamento ridotto;
• Focus sul Valore e sulla Qualità.

12. Agile@Core: Scrum12
Agile Umbrella
… more than one methodologies
DSDM Atern
Agile Unified Process (AUP)
Feature Driven Development
Process Approaches (still agile)
SCRUM
Crystal
eXtreme Programming (XP)
Lightweight Approaches
Agile
RUP (120+)
XP (13)
Scrum (9)
Kanban (3)
Do Whatever!! (0)
More Prescriptive
More Adaptive
RUP has over 30 roles, over 20
activities, and over 70 artifacts
more rules to follow
fewer rules to follow

13. Agile@Core: Scrum13
Agile Software Development
… distilled
Creare una Vision,
Abbracciare il Cambiamento,
Priorizzare le Attività, Creare
mini/micro WorkItem,
Ottenere Feedback, Decidere i
prossimi step, Collaborazione,
Lavoro di Team, Brevi
Iterazioni, Minimizzare i
Rischi, Minimal Plannig, Small
Team (5-9), Close Work

14. Agile@Core: Scrum14
Agile Software Development MYTHS
They are alive!
• no design
• no testing
• no documentation
• no idea of progress
• poor quality
• no plan
• auditors won’t allow it

15. Agile@Core: Scrum15
Scrum
Ken Schwaber
Jeff Sutherland

16. Agile@Core: Scrum16
Scrum in 10 parole
An Empirical Methodology
for Maximizing ROI
of Software Development Projects
… but not only
La parola Scrum deriva dal gergo utilizzato nel rugby ed è utilizzata per rappresentare un
Team che si muove come un'unica entità verso la meta.

17. Agile@Core: Scrum17

18. Agile@Core: Scrum18
Why Scrum
… the essence.
• Scrum is an agile process that allows us to focus on delivering the highest business value
in the shortest time.
• It allows us to rapidly and repeatedly inspect actual working software (every two weeks
to one month).
• The business sets the priorities. Teams self-organize to determine the best way to deliver
the highest priority features.
• Every two weeks to a month anyone can see real working software and decide to release
it as is or continue to enhance it for another sprint.
Jeff Sutherland : Initial Scrums at Easel Corp in 1993 , IDX and 500+ people doing Scrum
Ken Schwaber: ADM, Scrum presented at OOPSLA 96 with Sutherland,
Mike Beedle: Scrum patterns in PLOPD4
Ken Schwaber and Mike Cohn: Co-founded Scrum Alliance in 2002, initially within the Agile Alliance

19. Agile@Core: Scrum19
Scrum Values
… five basic values
OPENNESS
COURAGE
RESPECT
FOCUS
COMMITMENT
“Concentrate all your thoughts upon the work
at hand. The sun’s rays do not burn until
brought to a focus.” – Alexander Graham Bell
“Fortes fortuna adiuvat – fortune
favours the brave” – Latin proverb
“It is impossible for a man to learn what
he thinks he already knows.” – Epictetus
“Do, or do not. There is no try.” – Master Yoda
“I speak to everyone in the same way,
whether he is the garbage man or the
president of the university.” – Albert Einstein

20. Agile@Core: Scrum20
Big Picture
… is all there!

21. Agile@Core: Scrum21
Big Picture
… is all there!

22. Agile@Core: Scrum22
Scrum Team
… roles
Product Owner
Scrum Master
Development Team
E’ il responsabile della
Vision di prodotto e ha
come obiettivo quello di
massimizzarne il Valore.
Ha come obiettivo quello di implementare fattivamente Scrum, in
modo efficace ed efficiente, all’interno del Team stesso.
Stakehoder /
Client
Core Team
Professionisti in grado di
realizzare soluzioni Value Driven
e Strong Quality compliance.

23. Agile@Core: Scrum23
Scrum Team: Product Owner
… capabilities
Il Product Owner (PO) armonizza la voce degli stakeholder e
governa, in modo esclusivo, il Product Backlog:
• work Item knowledge (PBI, product backlog
items);
• priorizzazione PBI in funzione del Valore;
• definizione e verifica dei test di accettazione.

24. Agile@Core: Scrum24
Scrum Team: Scrum Master
… capabilities
Lo Scrum Master (SM) si comporta da Servant Leader /
Facilitatore:
• promuove l’adozione di Scrum e le relativa
implementazione;
• protegge il Team verso le interferenze e le
distrazioni esterne;
• promuove l’autogestione volta alla crescita
delle competenze complessive;
• elimina gli ostacoli agli avanzamenti.
Not “So, what are you going to do for me today?”
But “So, what can I do today to help you and the team be more effective?”

25. Agile@Core: Scrum25
Scrum Team: Development Team
… capabilities
Il Development Team (DT) è il Braccio Operativo dello
Scrum Team:
• auto-organizzato, è in grado
trasformare autonomamente il
Product Backlog in un prodotto
rilasciabile;
• cross-funzionali, il dev Team ha tutte
le competenze (progettazione, analisi,
design, sviluppo, testing, ecc…)
necessarie;
• T-shaped pattern, i singoli membri
hanno spesso competenze verticali
profonde in un settore (Deep) ma
sono in grado di supportare il resto del
Team su tutte le attività (Broad);
• piccole dimensioni, tipicamente da 3 a
7/9 componenti.

26. Agile@Core: Scrum26
Product Artefacts
… just few
Il Product Backlog è un elenco, pirolizzato, delle funzionalità (Product Backlog Item, PBI) previste per il
prodotto, sotto esclusivo governo del Product Owner:
• evolve in funzione del know-how acquisito sul prodotto e alla maturità del Team;
• i PBI sono caratterizzati: descrizione, priorità, effort, e valore di progetto.
Per l’affinamento del Product Backlog viene effettuato il Grooming, sotto
piena responsabilità del Product Owner:
• definizione dei Product Backlog Item (PBI);
• priorizzazione;
• stima dell’effort relativo da parte dello Scrum Team tramite, ad
esempio, Planning Poker;
• eliminazione, aggiunta, ri-priorizzazione PBI.
• I PBI in cima allo stack sono quelli ad ala priorità e, tipicamente,
di maggior dettaglio, pronti, quindi, ad essere inseriti nel
prossimo Sprint Backlog;
• Viene definito il significato di «DONE», «DONE-done», «Ready»
I Product Backlog Item sono:
• sintetici;
• scritti tipicamente in forma di User Story;
• corredati di Test di Accettazione;

27. Agile@Core: Scrum27
Product Backlog Grooming
… all together

28. Agile@Core: Scrum28
Sprint
… focus
Lo Sprint è l'evento principale di Scrum:
• tipicamente dura da 1 a 4 settimane;
• produce un incremento funzionale e testato della soluzione;
• è accompagnato da uno «Sprint Goal» che ne definisce l’obiettivo;
• è Time-boxed, ovvero, una volta iniziato, non può essere modificato se non in rarissimi casi e con
conseguenze organizzative da non sottovalutare.
Ogni Sprint inizia con lo Sprint Planning Meeting:
• viene definito lo «Sprint Goal»;
• viene creato lo Sprint Backlog, in accordo con lo
Sprint Goal, selezionando i PBI a maggiore
priorità e in linea con il goal;
• ha una durata relativa (4h per uno Sprint di
2settimane, 8h per uno da 4settimane).
Il Daily Scrum avviene giornalmente sempre alla stessa ora:
• massimo 15 minuti, preferibilmente ad inizio giornata;
• ogni membro del Team risponde rapidamente a tre
domande implicite:
• Cosa ho fatto ieri?
• Cosa farò oggi?
• Quali sono gli ostacoli da rimuovere?

29. Agile@Core: Scrum29
Sprint Artefacts
… simple and consistent
Lo Sprint Backlog è l'insieme degli elementi del Product Backlog selezionati per lo Sprint:
• la selezione viene effettuata dallo ST in funzione dello Sprint Goal e della propria storia (Velocity in
primis);
• I PBI sono suddivisi in task che descrivono come sviluppare il PBI, e ne viene stimata la durata in ore
(tipicamente da 4h a 16h);
• I task sono auto-assegnati, sia durante il Daily Scrum che durante l’attività di lavoro quotidiana.
Il Burndown Chart consente di visualizzare rapidamente
quando lavoro fatto e quanto lavoro resta da fare:
• ordinate: ore totali;
• ascisse: giorni dello Sprint;
• contiene l’andamento ideale e quello corrente;

30. Agile@Core: Scrum30
Ceremonies
… inspect and adapt
Lo Sprint Review avviene a fine Sprint per presentare quanto realizzato nel complessivo.
• ha una durata variabile (4ore per Sprint da 2settimane, 8ore per sprint da 4settimane);
• viene mostrato ai presenti l’As-Is;
• il PO identifica la congruità con lo Sprint Goal, ciò che è stato fatto e cosa no;
• viene effettuato il Grooming del Product Backlog;
Lo Sprint Retrospective viene tenuto a fine Sprint, dopo lo Sprint Review:
• è la cerimonia per eccellenza che permette di trasformare un Team in un High
Performance Team, ispezionando se stesso al fine di individuare i punti deboli e
migliorarsi;
• Ha una durata tipica di 2-3 ore;
• Vengono svolte delle Activity che consentono di ispezionare l’operato del Team, creare
una foto dello stato attuale e affinare un piano di miglioramento.

31. Agile@Core: Scrum31
Sprint Review
… inspect and adapt

32. Agile@Core: Scrum32
Sprint Retrospective
… inspect and adapt

33. Agile@Core: Scrum33
PSI, Potentially Shippable product Increment
… the solution.
• il PSI è il risultato dell’attività di Continous Integration ad ogni Sprint, cosa che rende
potenzialmente pronta la soluzione per il delivery
• alla fine di ogni Sprint viene preparato un nuovo PSI che deve essere compliance con la Definition
of Done (DoD);
• Il PSI deve essere utilizzabile indipendentemente dal fatto che il PO decida di rilasciarlo realmente
o meno agli stakeholder/clienti.

34. Agile@Core: Scrum34
We spoke about…
• Scrum Master (SM), responsabile dell’applicazione di Scrum;
• Product Backlog (PB), contiene le funzionalità da implementare;
• Product Owner (PO), responsabile del prodotto e della relazione stakeholder – Team;
• Development Team (DT), responsabile dell’implementazione delle feature;
• Scrum Team (ST), professionisti impegnati nella produzione di Valore;
• Sprint, intervallo Time-boxed nel quel il Development Team lavoro per completare le feature presenti nello
Sprint Backlog;
• Sprint Backlog, feature da realizzare nello Sprint;
• Daily Scrum, meeting giornaliero per fare il punto della situazione;
• Sprint Planning, meeting dello Scrum Team per fissare gli obiettivi del prossimo Sprint;
• Sprint Review, incontro per la verifica dell’AS-IS del progetto;
• Sprint Retrospective, incontro riservato all’intero Scrum Team per l’inspect-and-adapt;
• Grooming, attività di definizione/perfezionamento del Product Backlog;
• PSI, Potentially Shippable product Increment, soluzione potenzialmente consegnabile ed utilizzabile.

35. Agile@Core: Scrum35

36. Agile@Core: Scrum36
Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.
Imparare senza pensare è fatica perduta;
pensare senza imparare è pericoloso.
Confucio