Presentazione per

«La governance dei progetti agili:

esperienze a confronto»

Pascal Jansen – pascal.jansen@inspearit.com

Evento «Agile Project Management»

Firenze, 6 Marzo 2013

Agenda

Due parole su inspearit

I benifici dell’agilità nel settore ICT

Riscontro dalla pratica

Conclusioni

2

Agenda

Due parole su inspearit

I benifici dell’agilità nel settore ICT

Riscontro dalla pratica

Conclusioni

3

Eccellenza nell’ingegneria di Sistema, del Software e nell’erogazione Servizio dal 1989

15% dei ricavi

80 corsi, in-house & iscrizioni open

1500 studenti all’anno

23%

54%

23%

PHD/equivalente

Master/equivalente

Bachelor/equivalente

Media età: 42 anniPopolazione femminile: 17%

170 consulenti

Francia, Paesi Bassi, Italia

Singapore, Hong Kong, Shanghai

Partner qualificati in UK, Spagna, Germania e USA

4

5

“Aligning for Customer Value”

Agenda

Due parole su inspearit

I benifici dell’agilità nel settore ICT

Riscontro dalla pratica

Conclusioni

6

L’importanza del ciclo di vita incrementale

A

B

7

Business Value

Time

& CostTempo e costi risparmiati

8

100 %

80 %60 %

40 %

20 %

Sviluppoincrementale

« Feature Driven »

Sviluppotradizionale« Blackbox »

Design to

Value: l’80% del valore è

«good

enough»

Lo sviluppo tradizionale misura l’avanzamento rispetto alla trasformazione successiva di documenti (da requisito in specifica in disegno): soltanto l’ultima trasformazione genera il prodotto software

Adottare uno sviluppo incrementale «Feature Driven» permette di misurare l’avanzamento in prodotto software funzionante, con il vantaggio di potersi fermare prima della fine del progetto quando l’80% del valore è stato creato, massimizzando il lavoro «non fatto»

Massimizzare il lavoro

«non fatto»

I benefici dell’agilità nel settore ICT

Agenda

Due parole su inspearit

I benifici dell’agilità nel settore ICT

Riscontro dalla pratica

Conclusioni

9

Approccio traditionale Approcio agile

Un vero cambiamento di paradigma per il project management

10

Penny game: un modo convincente per simulare l'impatto potenziale

11

Fine del progetto!

Opzione #2”Early termination”

Il cliente può concludere il progetto prima quando il ROI minimo è raggiungibile

ROI

Time

ROI

cutoff

Opzione #1

”Change for free” finché lo scope complessivo rimane invariato

Mi necessità subito!

Si può farne a meno!

La priorità aumenta!

Cambiamenti sono tollerati fin quando possibile: il valore per il cliente è centrale

12

Source: Standish Group Study Reported

at XP2002

Source: Vrije Universiteit

prof. dr. Chris Verhoef

Un ciclo di vita più agile riduce il debito tecnico: incrementi più piccoli e più utili prima

13

Le domande che ci si pone frequentemente

Applicabilità?

Sviluppo con ambienti distribuiti?

Sviluppo esternalizzato?

Sviluppo di componenti riusabili?

Team di dimensioni elevate?

Software safety-critical?

Software complesso di dimensione elevata?

Completezza?

Esiste una metodologie? Degli best practice?

Quali strumenti?

Cosa succede con l’assicurazione qualità?

E la gestione del change infrastrutturale?

Una moda o una soluzione reale?

14

Gli ingredienti da non sottovalutare per introdurre un tale approccio

ClientUser

IT

Mgmt

Una nuova cultura, un “mindset”

ClientUser

OperMaint

PM

ArchiDev

Test

Integ

QA/QCCM

Ent.Archi

Un vero

commitment

Una diversa

strategia di sviluppo

Una diversa

dinamica del team

Nuove

pratiche di ingegneria

Un’

architettura flessibile

L’agilità del

business

Uso del

visualmanagement

Una gestione

più fluida del change

Adeguati ambienti di

sviluppo e di integrazione

15

L'importanza del commitment, della presenza congiunta di chi decide e di chi fa

16

Productowner

BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev.

Business Business Business Business Business

Workshop

e UAT

Team 1 Team 2

Scrum discrum

Iniziare con un solo team Aggiungere gradualmente Successivi team

Stabilire il gruppo di utenti chiave

Il “product owner” è il collegamento tra utenti e team

Attivare bene il ruolodel productowner è vitale

Disciplina ed efficienza nella gestione dello scope

17

Dallavisione

Al backlog

Productbox

Producttree

Storymapping

Al backloggrooming

Productowner

BusinessAnalyst

Business

Workshop Incontri regolariProductowner

BusinessAnalyst

Dev.

Il backlog necessità diuna prima revisione globaleper omogenizzare la granularità

Il backlog è revisionatoogni settimana permantenerlo allineatoalla visione

L'importanza della gestione dell’impatto organizzativa

18

BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

Dev. Dev. Dev. Dev. Dev. Dev. Dev. Dev.

Team 1 Team 2

Scrum discrum

Definiremeccanismi disincronizzazione

Delivery teams

Architectsand committees

QA

Environment teams Qualification

Othernot agileteams

Steering committee

Definire un meccanismodi gestione della transizione all’agile

Iniziare subito a deliverare

Interagire frequentementecon gli architetti

repositories

MaintenanceBusinessChangemngt

Gestire subitoi rischi di AQ

Coinvolgere la gestionedel cambiamento nelle demo

Uso del visual management

19

L’importanza delle nuove dinamiche

Department / name 20

Pratiche Benefici Quando

Ruoli specifici (Product

Owner, Scrum Master, Team)

Processi di decision making più

rapidiAumento dell’autonomia e della delega

Dall’inizio

Sprint (iterazioni) brevi con

relativi rituali

Visibilità nel progresso, feedback

loop immediato

Dall’inizio

Rilasci frequenti Visibilità nel progresso, feedback

loop immediatoAnticipare l’intercezione dei difetti

Appena possibile

Gestione dei Backlog Gestione delle priorità e del valore

creatoFlessibilità

Dall’inizio

Team Room, scrum board Aumento della comunicazione e

della visibilità

Dall’inizio

Definizione del concetto di

“Done”KPI Agile

Visibilità sul progresso, sulla qualità Graduale adozione

Build & Test:Test Driven DevelopmentContinuous InspectionContinuous Integration

Anticipare l’intercezione dei difetti Graduale adozione

Nuove pratiche per la gestione dei requisiti

21

Product Backlog

User Stories

Story Mapping

Stima in Story Points

“As [role]

I need to do [ action]

in order to [objective]

SCRUM

Team

Nuovi indicatori per il monitoraggio

2222

Cockpit

On Scope ?Product Burn-ChartQuantità di features completati

On Performance ? Velocity Chart

La quantità di lavoro (in points)

deliverato per iterazioneLa Velocity è utilizzato per fare il forecast di scope , tempi e

budget

On Budget ?Budget Burn-ChartOre burnt + stima af finire

On Quality ?Dashboard della Software Factory

Are we

doingwell ?

Nuove pratiche per le WBS di progetto

Focus sul ciclo di vita

Design -> Build -> Test

Continuous UAT

System

TestsFinal UAT

Productio

n

Project

Start

End

Development Release 1

End Test

Release 1

Sprint 1 Sprint 2 Sprint NSprint 3

Release N

Delivery

Design -> Build -> Test

Continuous UAT

System

TestsFinal UAT

Productio

n

Project

Start

End

Development Release 1

End Test

Release 1

Sprint 1 Sprint 2 Sprint NSprint 3

Release 2

Delivery

Design -> Build -> Test

Continuous UAT

System Tests

Final UATProduction

Project

Start

End

Development Release 1

End Test

Release 1

Sprint 1 Sprint 2 Sprint NSprint 3

Release 1

Delivery

23

La “vita” nello sprint

PlanningMeeting

Product Realisat

ion

BacklogGrooming

Product Realisat

ion

Demo Meeting

Retrospective

Meeting

Scope Meeting

Stand-up Meeting (ogni giorno)

Meeting What Duration When Who

Planning Stories decomposition in technical tasks

1 hour 1st day (Tuesday) Team, SM, PO

Stand-up Tasks and stories progress 15 minutes Daily basis (before lunch) Team, SM, PO

Backlog Grooming Epics are decomposed to smaller size, then estimated

2/4 hours 5th day(Monday)

Team, SM, PO

Demo Demonstration of what wasdeveloped. Feedback gathering

2 hours 10th day(Monday)

Team, SM, POAny other stakeholder

Retrospective Reflections on how the processcan be improved

2 hours 10th day(Monday)

Team, SM, PO

Scope Stories selection to bedeveloped the next sprint

1 hour 10th day(Monday)

Team, SM, PO

24

Non dimenticare l’adeguatezza degli ambienti e degli strumenti di sviluppo e integrazione

Continuous Integration, Delivery, Test Automation

Un « Broken Build » crea uno stato di emergenza

25

Esempio di continuous inspection

26

Agenda

Due parole su inspearit

I benifici dell’agilità nel settore ICT

Riscontro dalla pratica

Conclusioni

27

Conclusioni

Dosare gli ingredienti agile in base alle esigenze del contesto

Usare il ROI come driver della trasformazione

Feedback loop continui in base ai risultati

No «one-size-fits all»

Supporto continuo e comunicazione: coach, coach, coach…

28

29