1. Migliorare la produttività del software
con Extreme Programming
XPLabsTour07@UniModenaReggio
Mercoledì, 6 giugno 2007
Francesco Cirillo
CEO, XPLabs - S.R.L.
francesco.cirillo@xplabs.com
ah
2. 2
Introduzione
Compito
Lo sviluppo software può essere più efficace con XP?
Come?
CONCLUSIONI INTRODUZIONE
Perché?
Obiettivo
Migliorare
AVVERTENZE la produttività
IL CONTESTO
PER L'USO del software
con XP
Scelta informata
Pragmatic Approach LA RISPOSTA XP IL PROBLEMA
3. 3
Il contesto
Business case use case
Esempio: vendite on-line
Software = prodotto?!
Il software è valore in continuo mutamento
Acceptance test
Il metodo di sviluppo software supporta lo sviluppo del
business?
4. 4
Il problema
“Perché i progetti falliscono?”
Overly optimistic schedules
Undermined motivation
Insufficient risk management
Weak Personnel
Contractor failure
Uncontrolled problem employees
Insufficient planning
Heroics
Abandonment of planning under pressure
Adding people to a late project
Wasted time during the fuzzy front end
Noisy, crowded offices
Shortchanged upstream activities
Friction between developers and customers PEOPLE PROCESS
Inadequate design
Unrealistic expectations
Shortchanged quality assurance
Lack of effective project sponsorship
Insufficient management controls
Lack of stakeholder buy-in
Premature or overly frequent convergence
Lack of user input Classic
Mistakes Omitting necessary tasks from estimates
Politics placed over substance
Planning to catch up later
Wishful thinking
Code-like-hell programming
Silver-bullet syndrome
Overestimated savings Requirements gold-plating
from new tools or methods
Feature creep
Switching tools in TECHNOLOGY
PRODUCT Developer gold-plating
the middle of a project
Push-me, pull-me negotiation
Lack of automated
source-code control Research-oriented development
Rielaborato da Rapid Development di Steve McConnell
5. 5
Il problema
“Perché i progetti falliscono?”
Complessità
Velocità
Overly optimistic schedules
Undermined motivation
Insufficient risk management
Weak Personnel
Contractor failure
Uncontrolled problem employees
Insufficient planning
Heroics
Abandonment of planning under pressure
Adding people to a late project
Wasted time during the fuzzy front end
Noisy, crowded offices
Shortchanged upstream activities
Friction between developers and customers PEOPLE PROCESS
Inadequate design
Unrealistic expectations
Shortchanged quality assurance
Lack of effective project sponsorship
Insufficient management controls
Lack of stakeholder buy-in
Premature or overly frequent convergence
Lack of user input Classic
Mistakes Omitting necessary tasks from estimates
Politics placed over substance
Planning to catch up later
Wishful thinking
Code-like-hell programming
Silver-bullet syndrome
Overestimated savings Requirements gold-plating
from new tools or methods
Feature creep
Switching tools in TECHNOLOGY
PRODUCT Developer gold-plating
the middle of a project
Push-me, pull-me negotiation
Lack of automated
source-code control Research-oriented development
Rielaborato da Rapid Development di Steve McConnell
6. 6
La risposta XP
Sostituire il motore dei valori con: comunicazione,
feedback, semplicità, coraggio, rispetto
Applicare pratiche volte a ridurre la complessità di
business, tecnica e di comunicazione
7. 7
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
8. 8
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
9. 9
Massimizzare le opportunità di business
Identificare nuove opportunità di business
Assicurare ritorno investimenti rapido e frequente
Consentire di cambiare quando necessario
“Since the whole system development starts from what the
“Since the whole system development starts from what the
users wish to be able to do with the system, we build the
users wish to be able to do with the system, we build the
system from the users’ point of view. In this way, it will be
system from the users’ point of view. In this way, it will be
easy to discuss the requirements model with the users, and
easy to discuss the requirements model with the users, and
changes to the model will be simple to make”
changes to the model will be simple to make”
--Ivar Jacobson
--Ivar Jacobson
13. 13
Un esempio: Il videogioco di ChengQi
4 settimane
Partita
Space
Invader
2,5 settimane
Movimento
orizzontale Movimento
cannoncino orizzontale Strategia Strategia
astronave Incremento
attacco attacco
punteggio
UFO2 UFO1
Movimento Strategia
verticale attacco Collisione
UFO astronave Balistica proiettile
proiettile cannoncino
Strategia cannoncino
attacco
Balistica UFO3 Collisione
proiettile Collisione
UFO proiettile
proiettile UFO e nave
Morte barriera
cannoncino
Rotazione
360°
cannoncino Movimento Collisione
verticale Collisione asteroide
asteroide proiettile cannoncino
asteroide
Partita
Asteroids
14. 14
Vantaggi
Release più piccole
Flussi di cassa immediati e continui
Maggiore accuratezza nelle stime
Tracking più efficace
Più storie, più opportunità di business
Maggiore conoscenza del sistema
15. 15
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
16. 16
Minimizzare il costo del cambiamento
Per supportare il cambiamento, i costi marginali per unità
addizionale di funzionalità devono essere molto bassi e il
cambiamento deve avvenire in breve tempo
Possiamo assumere che il costo marginale e il tempo
necessari per effettuare il cambiamento possano essere
spiegati dallo sforzo necessario per regolare la
complessità necessaria per introdurre il cambiamento
richiesto nel sistema
Seguono una serie di interessanti relazioni...
17. 17
Relazioni utili
Meno strutturalmente complesso è il sistema corrente, e
meno intrinsecamente complesso è il problema da
risolvere, e minore sarà lo sforzo e quindi i costi e i tempi
necessari per introdurre la nuova funzionalità
Se per complessità marginale consideriamo l’incremento
di complessità del sistema necessario per introdurre la
nuova funzionalità, al fine di favorire il cambiamento nel
tempo, lo sforzo da applicare dovrà essere indirizzato a
ridurre la complessità marginale fino a renderla negativa
18. 18
Ridurre la complessità marginale
Come?
Mantenere bassa la complessità del sistema
Mantenere bassa la complessità del sistema
Mantenere bassa la complessità intrinseca del problema
Mantenere bassa la complessità intrinseca del problema
19. 19
Mantenere bassa la complessità del sistema
Il Refactoring:
Aumentare la capacità del codice di rivelare le intenzioni di
Lightweight
design, a qualsiasi membro del team, alla prima occhiata
Lightweight
Migliorare la struttura interna del sistema, consentendo alle
necessarie astrazioni di emergere
“Our job is to solve problems, not spoonfeed compilers (…)
“Our job is to solve problems, not spoonfeed compilers (…)
We need clarity so we can communicate using our code. We
We need clarity so we can communicate using our code. We
value conciseness and the ability to express aarequirement in
value conciseness and the ability to express requirement in
code accurately and efficiently”.
code accurately and efficiently”.
--Dave Thomas
--Dave Thomas
20. 20
Mantenere bassa la complessità del sistema
for(int i i==0; i i<<employees.size(); i++) {{
for(int 0; employees.size(); i++)
Employee employee ==(Employee) employees.get(i);
Employee employee (Employee) employees.get(i);
System.out.println(employee.getName());
System.out.println(employee.getName());
System.out.println(employee.getSalary());
System.out.println(employee.getSalary());
}}
employees.forEach(printSlip);
employees.forEach(printSlip);
“Our job is to solve problems, not spoonfeed compilers (…)
“Our job is to solve problems, not spoonfeed compilers (…)
We need clarity so we can communicate using our code. We
We need clarity so we can communicate using our code. We
value conciseness and the ability to express aarequirement in
value conciseness and the ability to express requirement in
code accurately and efficiently”.
code accurately and efficiently”.
--Dave Thomas
--Dave Thomas
21. 21
Mantenere bassa la complessità del sistema
Malleabilità
Continua applicazione di sforzo
Identificare possibilità di refactoring
Assicurare che le strutture dipendono dalle funzionalità
22. 22
Perché rifattorizzare continuamente?!
Ordine e complessità
Design anticipatorio
Managing complexity with complexity
Design emergente
Managing complexity with simplicity
23. Mantenere bassa la complessità intrinseca 23
del problema
Per supportare il cambiamento, la complessità intrinseca
della nuova funzionalità da introdurre nel sistema deve
essere continuamente ridotta in componenti ortogonali
più piccoli
No dividi e conquista
Guidato da test
24. 24
Strategie di sviluppo
Step 1:
Step 1: Obiettivo:
Stanze disponibili Obiettivo:
Stanze disponibili Fare una
Fare una
in un giorno per
in un giorno per prenotazione in un
un albergo con prenotazione in un
un albergo con albergo per un
albergo per un
una stanza
una stanza periodo di tempo
periodo di tempo
Step 2:
Step 2: Step 3:
Step 3:
Stanze disponibili
Stanze disponibili Stanze disponibili
Stanze disponibili
in un giorno per
in un giorno per in un giorno per
in un giorno per
un albergo con
un albergo con un albergo con
un albergo con
una stanza con
una stanza con una stanza con
una stanza con
una prenotazione
una prenotazione una prenotazione
una prenotazione
in un giorno
in un giorno in un periodo
in un periodo
25. 25
Test-Driven versus Test-First
Test Driven =
Test-First
Incrementalità
No gold plating
No testing
Some Themes of Quality Assurance
Some Themes of Quality Assurance
Quality is everybody’s business
Quality is everybody’s business
Quality must be an early focus of aaproject
Quality must be an early focus of project
The best way to achieve quality is to build it in
The best way to achieve quality is to build it in
--James Tomayko
--James Tomayko
26. 26
E le architetture?
Passo 1: Esplorazione
Passo 2: Interfacce minimali (no persistenza)
Passo 3: “Seleziona Progetto” (in memoria)
Passo 4: Distribuzione via socket
Passo 5: “Seleziona Progetto” (in file system)
Passo 6: Gestione comandi via applet-servlet
Passo 7: “Seleziona Progetto (su DBMS)
Passo 8: Miglioramento interfacce
27. 27
La complessità può aumentare…
Il processo non è deterministico
I due cappelli
Il “maialino” fa aumentare la complessità
Complessità del sistema
Tempo
28. 28
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
29. 29
Impiegare al meglio le risorse umane
In XP:
Il sistema viene sviluppato da piccoli team
Ogni sviluppatore offre le sue stime per ciascuna user story o
engineering task e quindi firma per quelle per le quali intende
assumersi la responsabilità
I membri del team lavorano in coppie
Gli sviluppatori ruotano frequentemente
Il team lavora in open space
Ruoli nel team
30. 30
Impiegare al meglio le risorse umane (continua)
Path of Communication:
Intra-Team Path of Communication
Intra-Pair Path of Communication
Inter-Pair Path of Communication
Constructive Path of Communication
31. 31
Impiegare al meglio le risorse umane (continua)
Modello responsabilità-collaborazione
Despecializzazione
Metafora degli impianti
Ispezioni e Pair Programming
Turn-over Results of inspections
Results of inspections
Fagan’s data indicate 82 percent
Fagan’s data indicate 82 percent
Motivazione efficace of all errors could be found with
of all errors could be found with
No signing-up inspections. Some applications
inspections. Some applications
had rates of 93 percent
had rates of 93 percent
No overtime “Defects found” decrease as
“Defects found” decrease as
speed of inspections increases
speed of inspections increases
--James Tomayko
--James Tomayko
32. 32
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
33. 33
Tracciare il progetto XP
Perché
Sapere come lavora/sta lavorando la mia organizzazione
Quanto guadagna la mia organizzazione
Quanto è efficace nella produzione di software
Functional
Functional
Oriented
Oriented
Accertare il progresso del progetto
“Ritmo” versus “completamento”
Imparare a stimare
Cosa
ROI
ROI
Oriented
Misure di valore
Oriented
Misure di processo
Misure di prodotto
37. 37
La lavagna del team Bees di XPLabs
Rythm Rythm
10 10
9 9
8 8
7 7
6 6
5 5
4 Iteration 1 4 Iteration 1
3 3
2 Ite razione 4 2 Ite razione 4
1 Iteration 2 Iteration 3 1 Iteration 2 Iteration 3
0 0
23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 1 mar 2004
4 1 mar 2004
9 24 mar 29 mar 3 apr 2004 23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 1 mar 2004
4 1 mar 2004
9 24 mar 29 mar 3 apr 2004
Accepted Completed Not Completed Average Accepted Completed Not Completed Average
McCabe
McCabe DSI / Class
1,6
1,6 32
1,55
1,55 30
1,5
1,5 28
1,45
1,45 26
1,4
1,4 24
1,35
1,35 22
1,3
1,3 20
1,25
1,25 18
1,2 23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 apr 2004
1,2
1,15
1,15
1,1
Number of Classes
1,1
1,05
1,05
11 60
23 feb 2004 28 feb 2004 4 mar 2004
23 feb 2004 28 feb 2004 4 mar 2004 99mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004
mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 apr 2004
3 apr 2004 55
50
DSI / Method
45
40
4,8 35
4,7
4,6 30
4,5
25
4,4
4,3 20
4,2
4,1 15
4 23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 apr 2004
3,9
3,8
3,7
3,6
3,5
Number of Classes and Methods
3,4 375
23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 apr 2004 350
400
325
375
300
DSI
350
275
325
250
300
1500 275
225
1400 250
200
225
1300 175
200
1200 150
175
125
150
1100
100
125
1000 100
75
900 75
50
50
800 25
25
700 00
600 23 feb 2004 28 feb 2004 44mar 2004
23 feb 2004 28 feb 2004 mar 2004 99mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 3 apr 200
mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 apr 2004
500
Test Classes Test Methods Application Classes Application Methods
23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 apr 2004
Test classes Test methods Application classes Application methods
38. 38
La tecnica del pomodoro
Quando
Ogni 30 minuti
Processo
La raccolta
La rilevazione
L’analisi
Vantaggi
Motivante
Responsabilizzante
Efficace
No interruzioni
39. 39
La risposta XP
Massimizzare le opportunità di business
Massimizzare le opportunità di business
Minimizzare ililcosto del cambiamento
Minimizzare costo del cambiamento
Impiegare al meglio le risorse umane
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
Sapere come lavoriamo/stiamo lavorando
40. 40
XP: Avvertenze per l’uso
Cosa èèXP
Cosa XP
Cosa non èèXP
Cosa non XP
Quando fallisce XP
Quando fallisce XP
43. 43
Cosa non è XP?!
Non è hacking
Non è NO analisi
Non è NO design
Non è NO pianificazione
Non è caos
Non è un silver bullet
44. 44
Quando fallisce XP?!
Mancanza di
Presenza continua del cliente
Una adeguata suite di test
Rifattorizzazione continua
Disciplina di team
Alto costo rifattorizzazione
Tool
XP fallisce se mancano i valori
45. 45
Conclusioni
Improving Software Productivity
Get the Best From People
Make Steps More Efficient
Eliminate Steps
Eliminate Rework
Build Simpler Products
Reuse Components
XP e ingegneria del software
