1. Migliorare la produttività del software
con Extreme Programming
XPLabsTour07@EclipseIT2007
Venerdì, 5 ottobre 2007
Francesco Cirillo
CEO, XPLabs - S.R.L.
francesco.cirillo@xplabs.com
ah
2. 2
u Acceptance Test
Il metodo di sviluppo software supporta lo sviluppo del business?
3. 3
u Il problema
n “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
4. 4
u Il problema
n “Perché i progetti falliscono?”
4 Complessità
4 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
5. 5
u La risposta XP
n Sostituire il motore dei valori con: comunicazione,
feedback, semplicità, coraggio, rispetto
n Applicare pratiche volte a ridurre la complessità di
business, tecnica e di comunicazione
6. 6
u La risposta XP
Massimizzare le opportunità di business
Minimizzare il costo del cambiamento
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
7. 7
è Minimizzare il costo del cambiamento
n 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à
n 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
•Complessità del sistema
•Tempo
8. 8
Ridurre la complessità marginale
n Come?
Mantenere bassa la complessità del sistema
Mantenere bassa la complessità intrinseca del problema
9. 9
à Mantenere bassa la complessità del sistema
n Il Refactoring:
4 Aumentare la capacità del codice di rivelare le intenzioni di
Lightweight
design, a qualsiasi membro del team, alla prima occhiata
4 Migliorare la struttura interna del sistema, consentendo alle
necessarie astrazioni di emergere
“Our job is to solve problems, not spoonfeed compilers (…)
We need clarity so we can communicate using our code. We
value conciseness and the ability to express a requirement in
code accurately and efficiently”.
--Dave Thomas
10. 10
à Mantenere bassa la complessità del sistema
for(int i = 0; i < employees.size(); i++) {
Employee employee = (Employee) employees.get(i);
System.out.println(employee.getName());
System.out.println(employee.getSalary());
}
employees.forEach(printSlip);
“Our job is to solve problems, not spoonfeed compilers (…)
We need clarity so we can communicate using our code. We
value conciseness and the ability to express a requirement in
code accurately and efficiently”.
--Dave Thomas
11. 11
à Mantenere bassa la complessità del sistema
n Malleabilità
n Continua applicazione di sforzo
4 Identificare possibilità di refactoring
4 Assicurare che le strutture dipendono dalle funzionalità
12. à Mantenere bassa la complessità intrinseca 12
del problema
n Per supportare il cambiamento, la complessità intrinseca
della nuova funzionalità da introdurre nel sistema deve
essere continuamente ridotta in componenti ortogonali
più piccoli
4 No dividi e conquista
4 Guidato da test
13. 13
Strategie di sviluppo
Step 1: Obiettivo:
Stanze disponibili Fare una
in un giorno per prenotazione in un
un albergo con albergo per un
una stanza periodo di tempo
Step 2: Step 3:
Stanze disponibili Stanze disponibili
in un giorno per in un giorno per
un albergo con un albergo con
una stanza con una stanza con
una prenotazione una prenotazione
in un giorno in un periodo
14. 14
Test-Driven versus Test-First
n Test Driven =
4 Test-First
4 Incrementalità
4 No gold plating
4 No testing
Some Themes of Quality Assurance
Quality is everybody’s business
Quality must be an early focus of a project
The best way to achieve quality is to build it in
--James Tomayko
17. 17
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 Iterazione 4 2 Iterazione 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 14 mar 2004 19 mar 2004 24 mar 29 mar 3 apr 2004 23 feb 2004 28 feb 2004 4 mar 2004 9 mar 2004 14 mar 2004 19 mar 2004 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
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,2
1,15
1,15
1,1
1,1
1,05
1,05 Number of Classes
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
45
DSI / Method 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 400
3,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
375
350 Number of Classes and Methods
400
325
375
300
DSI 350
275
325
250
300
1500 275
225
1400 250
200
225
1300 175
200
1200 150
175
1100 125
150
125
100
1000 10075
900 75
50
800 50
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 2004
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
