Confronto tra i framework Agile@Scale, SAFe & DAD.

1. Agile@Scale: be SAFe!
DAD & SAFe
07 Aprile 2014
@felicepescatore Disciplined Agile Delivery Italy Groupwww.felicepescatore.it
Felice Pescatore

2. Agile@Scale: be SAFe!
Reality is complex… software is complex!
COMPLEX
Emergent
Practices
COMPLICATED
Good
Practices
CHAOTIC
Novel
Practices
SIMPLE
Best
Practices
Cynefin Model
2

3. Agile@Scale: be SAFe!
Too complicated and too complex for traditional
approach
If a process is too unpredictable or too complicated for the planned,
(predictive) approach, then the empirical approach (measure and adapt)
is the method of choice. - Ken Schwaber
3

4. Agile@Scale: be SAFe!
Con il cappello “Agile” non si intende un
insieme di processi e tool.
Agile è un set di Valori e Pratiche su cui
basare le proprie attività, e, perché no, I
processi e i tool utilizzati.
Agile… what?
4

5. Agile@Scale: be SAFe!
Agile Manifesto
5

6. Agile@Scale: be SAFe!
What Agile isn’t…
6

7. Agile@Scale: be SAFe!
DSDM Atern
RUP / Open UP
FDD
Fuller Approaches (still agile)
SCRUM
Crystal
eXtreme Programming
Lightweight Approaches
Disciplined Agile Delivery, DAD Scaled Agile Framework, SAFe@Scale
Agile
Agile Umbrella
7

8. Agile@Scale: be SAFe!
Domain Complexity
Straight
-forward
Intricate,
emerging
Compliance requirement
Low risk Critical,
audited
Team size
Under 10
developers
1000’s of
developers
Co-located
Geographical distribution
Global
Enterprise discipline
Project
focus
Enterprise
focus
Technical complexity
Homogenous Heterogeneous,
legacy
Organization distribution
(outsourcing, partnerships)
Collaborative Contractual
Disciplined Agile
Delivery
Flexible Rigid
Organizational complexity
@Scale… what?
8

9. Agile@Scale: be SAFe!
A project is more than only development…
@Scale… why?
9

10. Agile@Scale: be SAFe!
The Idea, the Build, the Environment
Aggredire il mercato con una nuova idea
• Generata dall’esigenza, Pensata per creare un’esigenza
• Chi finanzia il progetto? Quali sono i rischi? Di quante persone ho
bisogno? Quanti Team? Dove avvengono le attività? Quali sono le
tecnologie di supporto?, ...
Program Level & Inception
Program Level & Inception
• Creare il Program Backlog (Feature), Creare i Team Backlog (User Story),
Identificare i PSI (Potential Shippable Increment), ….
Team Level & Construction
• Prendere in carico il Team Backlog, Definire le iterazioni in relazione ai PSI, Definire i
Task, Scegliere le pratiche da utilizzare, …
Program Level & Transition
• Completato lo sviluppo, il sistema deve essere manutenuto in erogazione e
fruibile correttamente da client di tipologia diversa (anche molto!)
10

11. Agile@Scale: be SAFe!
Leaders (in ALM) have strong
capabilities in agile practices, including
driving portfolio management support
and support for enterprise agile
capabilities, such as SAFe and
Disciplined Agile Delivery (DAD)*
* Tratto da: Magic Quadrant for Application Development
Life Cycle Management (19 November 2013)
SAFe and DAD
11

12. Agile@Scale: be SAFe!
SAFe, Scaled Agile Framework
• Framework maturo per l’adozione di
pratiche Agili all’interno di contesti
Enterprise
• In grado di gestire, con successo, un
ampio numero di «Agilisti» e di Team
• Costruito sui principi delle metodologie
Agile@Core e Lean
• Sincronizzazione tra sviluppo e delivery
Grazie alla «Big Picture» è possibile evidenziare le
relazioni ed i ruoli dei vari attori aziendali che
concorrono al processo Agile@Scale, unitamente
agli artefatti e le cerimonie di riferimento
12

13. Agile@Scale: be SAFe!
SAFe «Big Picture»
13

14. Agile@Scale: be SAFe!
SAFe: Portfolio Level
Ruoli / Team
• Program Portfolio Manager
• Enterprise Architect
• Epic Owner
Cerimonie
• Strategic Investment
Planning
• Kanban Portfolio Planning:
Epic
Artefatti
• Investment Themes
• Business and Architecture
Epics
• Portfolio Backlog
• Portfolio Vision
• Metrics
14

15. Agile@Scale: be SAFe!
SAFe: Program Level
Ruoli / Team
• Product Management
• Release Management
• System Team
• DevOps
• Business Owners
• System Architect
• Release Train Engineer
• UX Architect
Cerimonie
• PSI/Release Planning
• System Demo
• Inspect & Adapt Workshop
Artefatti
• Product Roadmap
• Vision
• Program Backlog
• Team Backlog
• NFRs
• Architecture Runway
• Business and Architecture
Feautures
• PSI Objectives
• Metrics
15

16. Agile@Scale: be SAFe!
SAFe: Team Level
Ruoli / Team
• Agile Teams
• Product Owner
• Scrum/Agile Master
Cerimonie
• Sprint Planning
• Backlog Grooming
• Daily Stand-up
• Sprint Demo
• Sprint Retrospective
• HIP Sprints
Artefatti
• Team Backlog (vincolato dai
NFRs)
• Team PSI Objective
• Sprint Goals
• Working Software
• Spikes
• Metrics
16

17. Agile@Scale: be SAFe!
DAD, Disciplined Agile Delivery
• Framework per lo sviluppo di soluzioni
End-to-End con ampia libertà di
personalizzazione
• Costruito sui principi delle metodologie
Agile@Core e Lean
• Scalabile, people-first oriented, learning
oriented, goal-driven, enterprise aware,
risk and value driven
• Linee guida per la governance di team
enterprise secondo le best-guide Agili
Grazie alla «Big Picture» è possibile evidenziare le fasi di
sviluppo di una soluzione end-to-end in ambito enterprise
secondo i principi Agili.
DAD è un framework ibrido, Value & Risk driven, fortemente
orientano alle persone e al loro apprendimento, il tutto con la
finalità di produrre in modo ottimale il delivery della soluzione.
I
C
T
Inception
Construction
Transition
17

18. Agile@Scale: be SAFe!
DAD, Agile Big Picture
Inception Construction 1 Construction 2 Construction 3 Transition 1 Construction 4 Transition 2
Avere una
visione
PSI PSI PSI Deploy in
Produzione
New PSI (Next
Release)
Nuovo Deploy
in Produzione
PSI: Potential Shippable Increment
18

19. Agile@Scale: be SAFe!
DAD, Lean Big Picture
Inception Lean Construction 1 Transition 1 Lean Construction 2 Transition 2
Avere una visione PSI when Done Deploy in Produzione New PSI (Next
Release)
Nuovo Deploy in
Produzione
PSI: Potential Shippable Increment
19

20. Agile@Scale: be SAFe!
THE AGILE 3C RHYTHM
Concept
Inception
Coordinate
Construction
Collaborate
Transition
Conclude
Release
rhythm
Iteration
rhythm
Development
Collaborate
Iteration
Planning
Coordinate
Stabilize
Conclude
Daily
rhythm
Coordinatio
n Meeting
Coordinate
Daily Work
Collaborate
Stabilize
Conclude
La terna (rhythm) Coordinate-Collaborate-Conclude ritorna a vari livelli in un progetto governato
tramite DAD:
20

21. Agile@Scale: be SAFe!
DAD PHASES: INCEPTION
Stakeholderconsensus
Project/ProductApprovedtostart
Collaborate ConcludeCoordinate
• Individuare i possibili Team
Member;
• Pianificare una sessione di “vision”
del progetto;
• Precettare gli stakeholder per la
sessione di “vision” .
• Rifinire la Vision;
• Effettuare una prima valutazione dei
requisiti;
• Effettuare una prima ipotesi
Architetturale;
• Valutare la fattibilità del progetto;
• Creare un primo Release Plan;
• Strutturare il (i) Team;
• Settare l’ambiente;
• Garantirsi la sostenibilità economica
• Identificare i rischi.
• Review di quanto definite
(mailstone);
• Comunicare la Vision agli
stakeholder;
• Impegnarsi sulle Iterazioni ed i
rilasci continui.
Fino ad alcune ore
(se tutti gli stakeholder
sono disponibili)
Idealmente: 1-2 settimane
Media: 4 settimane
Caso Peggiore: Più mesi
Qualche ora
21

22. Agile@Scale: be SAFe!
DAD PHASES: CONSTRUCTION PHASE
Second
Stakeholderconsensus
SufficientFunctionality
Collaborate ConcludeCoordinate
Dimostrare che le assunzioni
Architetturali sono corretti tramite
pezzi funzionati della stessa
• Produrre incrementalmente
soluzioni utilizzabili;
• Condividere lo stato del progetto con
gli stakeholder;
• Essere in linea con gli obiettivi
organizzativi;
• Allinearsi con gli altri Team;
• Migliorare se stessi ed il Team
nell’insieme.
• Determinare quando quello che si è
sviluppato è sufficiente per il
raggiungimento degli obietti;
• Stabilizzare la soluzione.
Tipicamente: 1 iterazione
Caso peggiore: Molte
iterazioni
Tipicamente: diverse
iterazioni Idealmente: alcune ore
22

23. Agile@Scale: be SAFe!
DAD PHASES: AGILE CONSTRUCTION PHASE
Typical Construction Iteration for Agile DAD Approach
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di una o
più story);
• Continuous Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungimento
dell’obiettivo;
• Aggiornamento del
Release plan.
2 ore per ogni
settimana
dell’iterazione
Tipicamente: due settimane nel caso di progetti standard,
Quattro settimane nel caso di progetti complessi con
integrazione tra Team cross-agile
Caso peggiore: Sei Settimane
2 ore per ogni
settimana
dell’iterazione
Pratiche avanzate:
• Test-driven development
(TDD);
• Acceptance TDD;
• Continuous deployment
(CD);
• Parallel independent
testing;
• Non-solo development;
• Look-ahead modeling;
• Look-ahead planning;
• Continuous
documentation.
Iterationstart
Potentiallyconsumablesolution
Coordinate Collaborate Conclude
23

24. Agile@Scale: be SAFe!
DAD PHASES: AGILE CONSTRUCTION PHASE
Typical Construction Day
Coordinate Collaborate Conclude
StartofDay
WorkingBuild
• Meeting di coordinamento
giornaliero;
• Aggiornamento della Taskboard
• Aggiornamento dell’Iteration
Burndown.
• Affrontare i problemi bloccanti;
• Creare i test;
• Sviluppare codice;
• Integrare quanto sviluppato;
• Risolvere i problemi ed i bug;
• Modellazione;
• Validazione del Codice.
• Stabilizzare quanto realizzato.
Fino a 15 minuti Tipicamente: 5 o 6 ore Idealmente: Non necessario
24

25. Agile@Scale: be SAFe!
DAD PHASES: TRANSITION PHASE
Third
Sufficientfunctionality
Productionready
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine sviluppo;
• Pilot della soluzione;
• Finalizzare la documentazione;
• Comunicare il deployment;
• Preparazione ambiente di erogazione;
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di
un ora
Caso Peggiore: Più
mesi
25

26. Agile@Scale: be SAFe!
GOAL DRIVEN
Not all iterations are created equal!
Construction Goals Transition GoalsInception Goals
• Costituire il Team
• Identificare la Vision del progetto
• Portare gli stakeholder a
concordare sulla Vision
• Essere allineati al contest aziendale
• Identificare la strategia tecnica
iniziale, i requisiti iniziali e definire
il piano di release iniziale
• Configurare l’ambiente (fisico e
digitale) di lavoro
• Assicurarsi la sostenibilità
economica del progetto
• Identificare i rischi
• Produrre sempre una soluzione
potenzialmente utilizzabile
• Catturare le richieste di
cambiamento proveniente dagli
stakeholder
• Avvicinarsi velocemente ad una
release per il deploy
• Mantenere e migliorare i livelli
qualitative esistenti
• Verificare il prima possibile
l’architettura
• Garantire che la soluzione è pronta
per la produzione
• Essere sicuri che gli stakeholder
sono pronti per usare la soluzione
• Effettuare il deploy della soluzione
in produzione
• Compiere la missione del progetto
• Incrementare le competenze (skill) dei Team Member
• Migliorare le infrastrutture esistenti
Ongoing Goals
• Migliorare i process e l’ambiente
• Sfruttare le infrastrutture esistenti
• Governare il rischio
26

27. Agile@Scale: be SAFe!
DAD Governance Strategy
• Esistono modalità diverse di governance per i progetti @Scale, in
particolare rispetto al contesto di applicazione
• DAD supporta differenti strategie e modalità di governance
• Le strategie fanno tesoro di quanto già in essere presso l’azienda
• Applicare ogni decisione quanto più localmente possibile
Corporate
Investimenti ITOperationDelivery/Deployment
Security
Infrastrutture
(Servizi, Cloud…)
Dati
Information Technology
27

28. Agile@Scale: be SAFe!
SAFe Governance Deliverable and Alignments
Shared Resources
• Operat.l Acceptance Plan
• Acceptance Criteria Plan
• Reqs Specification Doc
• Sys Security Plan
• Production Ops Manual
• Security Guide
• 508 Certification
• ATO
• Privacy Impact Assess
• User Guide
• SLA
Program Portfolio Man.
• Quad Chart
• IPT Charter
• BRD
• Project Charter
• Acquisition Strategy
Program and Release
Management
• PMP
• Transition Plan
• Risk Register/Log
• Outcome Stmt
• Version Description Doc
• Deployment Plan
• Lessons Learned
• Legislation
• Budget
• Policy
• Directives
• Architectural
Standard
• Data
Exchange
Standards
• Hosting
Stregies
• Security
Standards
System Architect
• System Design Doc
System Team
• Test Evaluation
• Master Test Plan
Ruoli SAFe con responsabilità inerenti la documentazione
dell’SDLD (Software Development Lifecycle Documentation)
28

29. Agile@Scale: be SAFe!
DAD «on» SAFe
InceptionI ConstructionC TransitionT
I C TI C T
29

30. Agile@Scale: be SAFe!
DAD «on» SAFe
I
30

31. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
• Individuare i
possibili Team
Member;
• Pianificare una sessione di
“vision” del progetto;
• Precettare gli stakeholder per
la sessione di “vision” .
• Rifinire la Vision;
• Effettuare una prima
valutazione dei requisiti;
• Effettuare una prima ipotesi
Architetturale;
• Valutare la fattibilità del
progetto;
• Creare un primo Release Plan;
• Strutturare il (i) Team;
• Settare l’ambiente;
• Garantirsi la sostenibilità
economica
• Identificare i rischi.
• Review di quanto definite
(mailstone);
• Comunicare la Vision agli
stakeholder;
• Impegnarsi sulle Iterazioni ed
in rilasci continui.
Fino ad alcune ore
(se tutti gli stakeholder
sono disponibili)
Idealmente: 1-2 settimane
Media: 4 settimane
Caso Peggiore: Più mesi
Qualche ora
I
31

32. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
• Individuare i possibili Team
Member;
• Pianificare una sessione di
“vision” del progetto;
• Precettare gli stakeholder per
la sessione di “vision” .
• Rifinire la Vision;
• Effettuare una prima
valutazione dei requisiti;
• Effettuare una
prima ipotesi
Architetturale;
• Valutare la fattibilità del
progetto;
• Creare un primo Release Plan;
• Strutturare il (i) Team;
• Settare l’ambiente;
• Garantirsi la sostenibilità
economica
• Identificare i rischi.
• Review di quanto definite
(mailstone);
• Comunicare la Vision agli
stakeholder;
• Impegnarsi sulle Iterazioni ed
in rilasci continui.
Fino ad alcune ore
(se tutti gli stakeholder
sono disponibili)
Idealmente: 1-2 settimane
Media: 4 settimane
Caso Peggiore: Più mesi
Qualche ora
I
32

33. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
• Individuare i possibili Team
Member;
• Pianificare una sessione di
“vision” del progetto;
• Precettare gli stakeholder per
la sessione di “vision” .
• Rifinire la Vision;
• Effettuare una prima
valutazione dei requisiti;
• Effettuare una prima ipotesi
Architetturale;
• Valutare la fattibilità del
progetto;
• Creare un primo
Release Plan;
• Strutturare il (i) Team;
• Settare l’ambiente;
• Garantirsi la sostenibilità
economica
• Identificare i rischi.
• Review di quanto definite
(mailstone);
• Comunicare la Vision agli
stakeholder;
• Impegnarsi sulle Iterazioni ed
in rilasci continui.
Fino ad alcune ore
(se tutti gli stakeholder
sono disponibili)
Idealmente: 1-2 settimane
Media: 4 settimane
Caso Peggiore: Più mesi
Qualche ora
I
33

34. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
• Individuare i possibili Team
Member;
• Pianificare una sessione di
“vision” del progetto;
• Precettare gli stakeholder per
la sessione di “vision” .
• Rifinire la
Vision;
• Effettuare una prima
valutazione dei requisiti;
• Effettuare una prima ipotesi
Architetturale;
• Valutare la fattibilità del
progetto;
• Creare un primo Release Plan;
• Strutturare il (i) Team;
• Settare l’ambiente;
• Garantirsi la sostenibilità
economica
• Identificare i rischi.
• Review di quanto definite
(mailstone);
• Comunicare la Vision agli
stakeholder;
• Impegnarsi sulle Iterazioni ed
in rilasci continui.
Fino ad alcune ore
(se tutti gli stakeholder
sono disponibili)
Idealmente: 1-2 settimane
Media: 4 settimane
Caso Peggiore: Più mesi
Qualche ora
I
34

35. Agile@Scale: be SAFe!
DAD «on» SAFe
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di
una o più story);
• Continuous Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungiment
o dell’obiettivo;
• Aggiornamento
del Release
plan.
Pratiche
avanzate:
• Test-driven
development (TDD);
• Acceptance TDD;
• Continuous
deployment (CD);
• Parallel independent
testing;
• Non-solo
development;
• Look-ahead
modeling;
• Look-ahead
planning;
• Continuous
documentation.
Coordinate Collaborate Conclude
C
35

36. Agile@Scale: be SAFe!
DAD «on» SAFe
InceptionI ConstructionC TransitionT
I C TI C T
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di
una o più story);
• Continuous
Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungiment
o dell’obiettivo;
• Aggiornamento
del Release
plan.
Pratiche
avanzate:
• Test-driven
development (TDD);
• Acceptance TDD;
• Continuous
deployment (CD);
• Parallel independent
testing;
• Non-solo
development;
• Look-ahead
modeling;
• Look-ahead
planning;
• Continuous
documentation.
Coordinate Collaborate Conclude
C
36

37. Agile@Scale: be SAFe!
DAD «on» SAFe
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di
una o più story);
• Continuous Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i
work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungiment
o dell’obiettivo;
• Aggiornamento
del Release
plan.
Pratiche
avanzate:
• Test-driven
development (TDD);
• Acceptance TDD;
• Continuous
deployment (CD);
• Parallel independent
testing;
• Non-solo
development;
• Look-ahead
modeling;
• Look-ahead
planning;
• Continuous
documentation.
Coordinate Collaborate Conclude
C
37

38. Agile@Scale: be SAFe!
DAD «on» SAFe
38
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di
una o più story);
• Continuous Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungiment
o dell’obiettivo;
• Aggiornamento
del Release
plan.
Pratiche avanzate:
• Test-driven
development
(TDD);
• Acceptance TDD;
• Continuous deployment
(CD);
• Parallel independent
testing;
• Non-solo development;
• Look-ahead modeling;
• Look-ahead planning;
• Continuous
documentation.
Coordinate Collaborate Conclude
C

39. Agile@Scale: be SAFe!
DAD «on» SAFe
• Iteration
planning
• Iteration
modeling
Pratiche standard:
• Focalizzare le attività;
• Meeting di Coordinamento
giornaliero;
• Test di regressione;
• Evoluzione dell’Architettura ed
eventuali Spike relativi (task di
una o più story);
• Continuous Integration;
• Refactoring;
• Ritmo sostenibile;
• Priorizzare i work item;
• Attività di configurazione;
• “Track “done” delle attività (es.
Burndown)
• JIT model storming
• Iteration
demo;
• Retrospettiva;
• Valutare le
funzionalità
sufficienti al
raggiungiment
o dell’obiettivo;
• Aggiornamento
del Release
plan.
Pratiche avanzate:
• Test-driven
development (TDD);
• Acceptance TDD;
• Continuous deployment
(CD);
• Parallel independent
testing;
• Non-solo development;
• Look-ahead modeling;
• Look-ahead planning;
• Continuous
documentation.
Coordinate Collaborate Conclude
C
39

40. Agile@Scale: be SAFe!
DAD «on» SAFe
I C TI C T
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione;
• Comunicare il deployment;
• Preparazione ambiente di
erogazione
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
T
40

41. Agile@Scale: be SAFe!
DAD «on» SAFe
41
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione;
• Comunicare il deployment;
• Preparazione
ambiente di
erogazione;
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
T

42. Agile@Scale: be SAFe!
DAD «on» SAFe
TransitionT
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e
fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione;
• Comunicare il deployment;
• Preparazione ambiente di
erogazione
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
42
T

43. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione
• Comunicare il deployment;
• Preparazione ambiente di
erogazione;
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
T
43

44. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione
• Comunicare il deployment;
• Preparazione ambiente di
erogazione;
• Training degli stakeholder.
• Review dello
stato di ready
in
produzione;
• Deploy della soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
T
44

45. Agile@Scale: be SAFe!
DAD «on» SAFe
Collaborate ConcludeCoordinate
Pianificazione • Piano di transizione;
• Testing e fixing di fine
sviluppo;
• Pilot della soluzione;
• Finalizzare la
documentazione
• Comunicare il deployment;
• Preparazione ambiente di
erogazione;
• Training degli stakeholder.
• Review dello stato di ready in
produzione;
• Deploy della
soluzione.
Idealmente: nessun effort
temporale
Tipicamente: 1 ora a
settimana per l’intera fase
Idealmente: nessun effort
temporale
Media: 4 settimane
Caso Peggiore: Più mesi
Idealmente: meno di un ora
Caso Peggiore: Più mesi
T
45

46. Agile@Scale: be SAFe!
SAFe Key Point
• Framework maturo e robusto, ben
documentato e utilizzato in diversi
contesti reali;
• Ruolo centrale delle persone in tutte le
fasi di delivery, con ruoli chiari, artefatti
precisi e eventi espliciti;
• Visione olistica dell’organizzazione
aziendale, con una identificazione di 3
livelli di partecipazione e valore;
• Focus sulla qualità del software (Agile
& DevOps);
• Costanti review ed aggiornamenti.
• Prescrittivo;
• Pesante/Complesso;
• Incentrato sui processi di
Certificazione;
Pro Pro
46

47. Agile@Scale: be SAFe!
DAD Key Point
• Framework ibrido che si fonda su
approcci Agile e Lean affermati;
• La gestione delle milestone permette
di adattarlo a contesti enterprise reali;
• Ampia flessibilità rispetto alle pratiche
Agili da adottare;
• Forte attenzione sugli aspetti
architetturali ed ingegneristici;
• Governance chiara per i
program/product manager.
• Adozione poco nota;
• Limitata azione di
formazione per la
certificazione;
• Mancanza di prescrizioni
per un’adozione sistematica
delle pratiche Agili.
Pro Pro
47

48. Agile@Scale: be SAFe!
@felicepescatore
ABOUT ME
get in touch
Disciplined Agile Delivery Italy
Group
Felice Pescatore, Agile Software Architect
Email: felice.pescatore@gmail.com
Cell. 392/7157684
www.felicepescatore.it
48

49. Agile@Scale: be SAFe!
THANKS FOR WATCHING
Quest'opera è distribuita con Licenza Creative Commons Attribuzione - Non commerciale 3.0 Italia.