Disciplined Agile Deliveryframework

Ing. Felice Pescatorewww.felicepescatore.it

Introduzione

1 Febbraio 2013

AGENDA

Defining Disciplined Agile Delivery (DAD)

People first

Learning oriented

Hybrid agile framework

A risk and value driven lifecycle

Goal driven lifecycle

Enterprise aware

Optimize the whole

Agile governance

Scalable: Agility@scale

DAD - Introduzione

2

DEFINING DISCIPLINED AGILE DELIVERYFriendly: DAD

DAD process framework è un APPROCCIO Agile al delivery di una soluzione IT che

predilige:

• People-first

• Learning-oriented

• Risk and value driven

• Goal-driven

• Hybrid

• Enterprise aware

• Scalable

DAD - Introduzione

3

Le Persone ed il modo in cui collaborano sono l’elemento primario per il

successo

PEOPLE FIRSTPrinciples and Values

DAD - Introduzione

4

Self Disciplined:

impegnati solo sul lavoro che si

è in grado di fare bene

Self Organizing:

stima e pianificazione

del proprio lavoro

Self Aware:

capire come migliorarsi

DAD TEAM Member

Cross functional

teams

Specialisti trasversali

Nessuna gerarchia nel TeamDAD encourages

PEOPLE FIRSTPotential roles on disciplined agile teams

DAD - Introduzione

5

Primary roles:

• Stakeholder

• Team Lead

• Product Owner

• Agile Team Member

• Architecture Owner

Secondary/optional roles:

• Domain Expert

• Technical Expert

• Independent Tester

• Integrator

• Specialist

PEOPLE FIRSTPotential transition strategies for existing business analysts

DAD - Introduzione

6

LEARNING ORIENTEDKnow-how is all

DAD - Introduzione

7

Domain learning

• Primo approccio ai requisiti

• Rilascio incrementali di soluzioni potenzialmente

utilizzabili

• Partecipazione attiva degli stakeholder durante

tutto il ciclo di vita del sistema

Process improvement

• Retrospettiva alla fine delle Iterazioni

• Monitoraggio dei miglioramenti

• Condivisione degli skill tramite la pratica del “non-

solo development”

Technical learning

• Spike Architetturali

• Confutare le scelte Architetturali tramite soluzioni

funzionanti (working code)

General strategies

• Training

• Education

• Mentoring/coaching

• I Membri del Team sono “general specialist” e non

solo “specialist”

RISK-VALUE DRIVENManage the Risk as soon as possible

DAD - Introduzione

8

Risk Driven

• Validare l’Architettura il prima possibile;

• Ottenere il consenso degli Stakeholder con

dimostrazioni pratiche;

• Essere compliance con la direzione aziendale

(enterprise aware);

• Lavorare prima su ciò che porta un reale

incremento di know-how al Team

Value Driven

• Lavorare prima sugli elementi a maggior Valore per

gli stakeholder;

• Continua verifica del Valore prodotto;

• Determinare quando è stato state implementate

funzionalità sufficienti a soddisfare il Valore

richiesto;

• Produrre sempre soluzioni potenzialmente

utilizzabili durante il ciclo di vita;

• Valutare continuamente nuovi elementi di lavoro

aggregate alla crescente comprensione di ciò che

realmente si vuole ottenere

DISCIPLINED AGILE DELIVERY life cycle BASIC

DAD - Introduzione

9

DISCIPLINED AGILE DELIVERY life cycle ADVANCED

DAD - Introduzione 10

DAD PHASES: INCEPTIONFirst

DAD - Introduzione

11

Pro

ject

/ P

rod

uct

Ap

pro

ved

to

start

Sta

keh

old

er

con

sen

sus

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 settimaneCaso Peggiore: Più

mesi

Qualche ora

DAD PHASES: CONSTRUCTION PHASESecond

DAD - Introduzione

12

Sta

keh

old

er c

on

sen

sus

Suffi

cien

t Fun

ction

ality

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 iterazioneCaso peggiore: Molte

iterazioni

Tipicamente: diverse iterazioni Idealmente: alcune

ore

DAD PHASES: CONSTRUCTION PHASETypical Construction Iteration

12

• 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.

Itera

tion

star

t

Pote

ntial

ly c

onsu

mab

le s

oluti

on

Coordinate Collaborate Conclude

DAD - Introduzione

13

DAD PHASES: CONSTRUCTION PHASETypical Construction Day

Coordinate Collaborate Conclude

DAD - Introduzione 14

Star

t of D

ay

Wor

king

Bui

ld

• 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

DAD PHASES: TRANSITION PHASEThird

DAD - Introduzione

15

Suffi

cien

t fun

ction

ality

Prod

uctio

n re

ady

Collaborate ConcludeCoordinate

Pianificazione • Piano di transizione;

• Testing e fixing di fine sviluppo;

• Pilot della soluzione;

• Finalizzare la documentazione;

• Comunicare il deployment;

• 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 settimaneCaso Peggiore: Più

mesi

Idealmente: meno di un ora

Caso Peggiore: Più mesi

GOAL DRIVENNot all iterations are created equal!

DAD - Introduzione

16

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

GOAL DRIVENAn Example

DAD - Introduzione

17

Istruzioni:

• Considerare l’attuale esperienza su progetti Agile,

qualora ve ne fossero;

• Condividere la propria esperienza esplorando i

requisiti iniziali/scope all’inizio di un nuovo

progetto Agile.

Questioni (problemi) da considerare:

• Con chi lavorerete?

• Che tipo di modelli/artefatti andrete a creare?

• Che tipo di dettaglio bisognerà raggiungere?

• Quanto tempo sarà necessario?

• Come pensate di realizzare il tutto?

• Quali sono i vantaggi e gli svantaggi di quello che

vi apprestate a fare?

DAD ADOPTS BEST PRACTICES FROM SEVERAL AGILE METHODS

Hybrid

DAD - Introduzione

18

Unified Process (UP)

Extreme

Programming (XP)

Scrum

HarmonyProcess

Disciplined Agile

Delivery (DAD)

Lean

Agile

Modeling

DAD è un process framework ibrido che adotta il meglio delle pratiche e delle filosofie delle varie metodologie

“CORE” Agile

THE AGILE 3C RHYTHMConcept

DAD - Introduzione

19

Inception

Coordinate

Construction

Collaborate

Transition

Conclude

Release rhythm

Iteration rhythm

Development

Collaborate

Iteration Planning

Coordinate

Stabilize

Conclude

Daily rhythm

Coordination

Meeting

Coordinate

Daily Work

Collaborate

Stabilize

Conclude

La terna (rhythm) Coordinate-Collaborate-Conclude ritorna a vari livelli in un progetto

governato tramite DAD:

ENTERPRISE AWAREOptimizing the whole

DAD - Introduzione

20

Seguire le convenzioni aziendali:

• Standard e best practice Architetturali;

• Best practice di Codifica;

• Best practice di gestione dei Dati;

• Linee guida nella definizione della User Interface

(UI);

• ……

Migliorare l’ecosistema aziendale:

• Riutilizzare e sfruttare al massimo le infrastrutture

aziendali;

• Migliorare e sviluppare le infrastrutture aziendali;

• Lavorare a stretto contatto con l’Enterprise

Architecture (EA) Team.

Condivisione della conoscenza

• Contribuire alla crescita personale e del Team;

• Contribuire alla crescita dell’azienda nel

complesso;

• Arricchire e rafforzare il know-how relativo

all’Agile.

Interazione con altri Team (Agile e non):

• Enterprise Architecture Team;

• Data Management Team;

• Governance Aziendale;

• Quality Assurance;

• Project management Office (PMO).

ENTERPRISE AWAREGoverning agile teams

DAD - Introduzione

21

Un Team Agile, per propria natura, fornisce:

• Un aggiornamento continuo dello stato di

avanzamento del progetto (fotografia) agli

stakeholder;

• Importanti momenti di condivisione per consentire

agli stakeholder di indirizzare lo scope del

progetto;

• Richiede un impegno superiore per gli stakeholder

che devono essere fattivamente presenti.

Pratiche:

• Partecipazione attiva degli stakeholder;

• Soluzioni potenzialmente utilizzabili ad ogni

iterazione;

• Risk-value lifecycle;

• Review esplicite di milestone light-weight

• Meeting giornaliero di coordinamento;

• Demo al completamento di ogni iterazione;

• Demo «all-hands», ovvero con il supporto di tutto il

Team e tenuta a rotazione;

• Seguire le convenzioni aziendali;

• Lavorare a stretto contatto con gli Architect

aziendali;

• Metriche automatizzate per la valutazione dei

risultati in ottica auto-migliorativa.

DAD, The Road Ahead for agility@scale

DAD - Introduzione

22

Domain Complexity

Straight-forward

Intricate,emerging

Compliance requirement

Low risk Critical,audited

Team size

Under 10developers

1000’s ofdevelopers

Co-located

Geographical distribution

Global

Enterprise discipline

Projectfocus

Enterprisefocus

Technical complexity

HomogenousHeterogeneous,

legacy

Organization distribution(outsourcing, partnerships)

Collaborative Contractual

Disciplined Agile

Delivery

Flexible Rigid

Organizational complexity

RiferimentiBook and Web Resources

DAD - Introduzione

23

www.DisciplinedAgileDelivery.com

Authors

Scott Ambler:

http://twitter.com/scottwambler

Mark Lines: http://twitter.com/Mark_Lines

@DAD - Introduzione

ABOUT MEget in touch

DAD - Introduzione

24

Disciplined Agile Delivery Italy Group

Felice Pescatore, Agile Software

Architect

Email: felice.pescatore@gmail.com

Cell. 392/7157684

www.felicepescatore.it

THANKS FOR WATCHINGbased on a Scott Amblers works and IBM © Materials

scott_ambler@ca.ibm.com

DAD - Introduzione

25