La presentazione di Pascal Jansen discute i benefici dell'agilità nel project management, evidenziando l'importanza di sviluppi incrementali e la misurazione del valore per il cliente. Viene proposto un approccio agile per affrontare la transizione, enfatizzando il ruolo delle nuove metodologie e indicatori per ottimizzare le performance. Il documento conclude sottolineando la necessità di adattare le pratiche agili alle specifiche esigenze del contesto aziendale.

1. Presentazione per
«Quando il Project Management si fa agile»
Pascal Jansen – pascal.jansen@inspearit.com
Evento «AGILE PROJECT MANAGEMENT IN ACTION!»
Roma, 12 Aprile 2013

2. Agenda
Due parole su inspearit
I benifici dell’agilità nel settore ICT
Come affrontare la transizione
Conclusioni
2

3. Agenda
Due parole su inspearit
I benifici dell’agilità nel settore ICT
Come affrontare la transizione
Conclusioni
3

4. Eccellenza nell’ingegneria di Sistema, del
Software e nell’erogazione Servizio dal 1989
170 consulenti
Francia, Paesi Bassi, Italia
Singapore, Hong Kong, Shanghai
Partner qualificati in UK, Spagna, Germania e USA
23%
23%
54%
Media età: 42 anni
Popolazione femminile: 17%
15% dei ricavi
80 corsi, in-house & iscrizioni open
1500 studenti all’anno
4
PHD/equivalente
Master/equivalente
Bachelor/equivalente

5. “Aligning for Customer Value”
5

6. La nostra offerta di gestione del
cambiamento culturale
Miglioramento delle performance
Service management / Product
development process assessment &
industrialization
IT technical debt assessment and
improvement
IT sourcing strategy assessment &
improvement
Trasformazione agile
Transition to agile organization
Value stream mapping
Agile project management
Kan-ban based maintenance
Test driven development
Continuous integration
Partnerships with customers, measurable impact,
benchmarked improvements
6

7. Agenda
Due parole su inspearit
I benifici dell’agilità nel settore ICT
Come affrontare la transizione
Conclusioni
7

8. L’importanza del ciclo di vita incrementale
A
B
8

9. I benefici dell’agilità nel settore ICT
Business Value
Design to
Value l’80%
del valore è
«good
enough»
Sviluppo
incrementale
« Feature Driven »
Sviluppo
tradizionale
« Blackbox »
100 %
80 %
Massimizzare
il lavoro
«non fatto»
60 %
40 %
20 %
Tempo e costi risparmiati
Time
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 9
«non fatto»

10. Un vero cambiamento di paradigma per il
project management
Approccio traditionale
Approcio agile
10

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

12. Cambiamenti sono tollerati fin quando
possibile: il valore per il cliente è centrale
Opzione #1
”Change for free” finché lo scope
complessivo rimane invariato
Mi necessità subito!
ROI
Opzione #2
”Early termination”
Il cliente può concludere il
progetto prima quando il ROI
minimo è raggiungibile
La priorità aumenta!
Si può farne a meno!
Fine del progetto!
ROI
cutoff
Time
12

13. Un ciclo di vita più agile riduce il debito tecnico:
incrementi più piccoli e più utili prima
Source: Standish Group Study Reported
at XP2002
Source: Vrije Universiteit
prof. dr. Chris Verhoef
13

14. Agenda
Due parole su inspearit
I benifici dell’agilità nel settore ICT
Come affrontare la transizione
Conclusioni
14

15. 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?
15

16. Un ciclo di vita più agile significa trovare il
giusto equilibrio tra agilità e disciplina
Agile Manifesto (2001): we are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions
Working software
documentation
Customer collaboration
Responding to change
That is,
while
we
over processes and tools
over
comprehensive
over contract negotiation
over following a plan
there is value in the items on the right,
value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
E’ efficace valutare la “organizational readiness” per l’adozione dei
principi agili e costruire uno scenario di trasformazione che permetta di
16
creare subito valore con dei quick-wins

17. Gli «ingredienti» da valutare attentamente
prima e durante la transizione
User
Client
Management
Maintenance Operations
Una gestione
più fluida del
change
IT
Un vero
commitment
Una diversa
strategia di
sviluppo
PM
Architecture
Una diversa
dinamica del
team
Test
User
Supplier
L’agilità del
business
Enterprise
Architecture
Uso del
visual
management
Development
QA/QC
Client
Un’
architettura
flessibile
Nuove
pratiche di
ingegneria
Integration
Adeguati ambienti di
sviluppo e di integrazione
CM
Una nuova cultura, un “mindset”
17

18. Nuovi indicatori per il monitoraggio
On Quality ?
Dashboard della
Software Factory
On Performance ?
 Velocity Chart
La quantità di lavoro (in points)
deliverato per iterazione
La Velocity è utilizzato per fare
il forecast di scope , tempi e
budget
On Scope ?
Product Burn-Chart
Quantità di features completati
Cockpit
Are we
doing
well ?
On Budget ?
Budget Burn-Chart
Ore burnt + stima af finire
18
1
8

19. Agenda
Due parole su inspearit
I benifici dell’agilità nel settore ICT
Come affrontare la transizione
Conclusioni
19

20. 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…
20

21. 21