20080124 XPLabs Tour08 @UniAQ.it L'Aquila-IT [ITA]

Migliorare la produttività del software
con Extreme Programming
XPLabsTour08@UnivAQ.it
Giovedì, 24 gennaio 2008

Francesco Cirillo
CEO, XPLabs - S.R.L.
francesco.cirillo@xplabs.com

ah

 Questo intervento sostiene:

© 2000-2008 Francesco Cirillo Migliorare la produttività del software con XP XPLabs - S.R.L. 2

 Introduzione
 Compito
 Lo sviluppo software può essere più efficace con XP?
 Come?
CONCLUSIONI INTRODUZIONE

 Perché?

Obiettivo
Migliorare
 AVVERTENZE
PER L'USO
la produttività
del software
IL CONTESTO

con XP
 Scelta informata
 Pragmatic Approach
LA RISPOSTA XP IL PROBLEMA


 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?


 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

 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


 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


 La risposta XP

Massimizzare le opportunità di business

Minimizzare il costo del cambiamento

Impiegare al meglio le risorse umane

Sapere come lavoriamo/stiamo lavorando


 La risposta XP






 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
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
easy to discuss the requirements model with the users, and
changes to the model will be simple to make”
--Ivar Jacobson


User Story


Il Planning Game
Splitting

Natura User Story Splittate
Legoland di utilità

Emergent Value
Natura delle User Story

Un esempio: Il videogioco di ChengQi


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
proiettile Collisione
Collisione
UFO proiettile
proiettile
UFO e nave
Morte barriera
cannoncino

Rotazione
360°
cannoncino Movimento Collisione
verticale Collisione asteroide
asteroide proiettile cannoncino
asteroide

Partita
Asteroids


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


 La risposta XP






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


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


Ridurre la complessità marginale
 Come?

Mantenere bassa la complessità del sistema

Mantenere bassa la complessità intrinseca del problema


 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
 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


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


 Malleabilità

 Continua applicazione di sforzo
 Identificare possibilità di refactoring
 Assicurare che le strutture dipendono dalle funzionalità


Perché rifattorizzare continuamente?!
 Ordine e complessità
 Design anticipatorio
 Managing complexity with complexity

 Design emergente
 Managing complexity with simplicity


 Mantenere bassa la complessità intrinseca
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


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


Test-Driven versus Test-First
 Test Driven =
 Test-First
 Incrementalità
 No gold plating
 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


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


La complessità può aumentare…
 Il processo non è deterministico
 I due cappelli
 Il “maialino” fa aumentare la complessità
Complessità del sistema

Tempo


 La risposta XP






 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


 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


 Impiegare al meglio le risorse umane (continua)
 Modello responsabilità-collaborazione
 Despecializzazione
 Metafora degli impianti
 Ispezioni e Pair Programming
 Turn-over Results of inspections
Fagan’s data indicate 82 percent
 Motivazione efficace of all errors could be found with
 No signing-up inspections. Some applications
had rates of 93 percent
 No overtime “Defects found” decrease as
speed of inspections increases
--James Tomayko


 La risposta XP






 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
Oriented  Accertare il progresso del progetto
 “Ritmo” versus “completamento”
 Imparare a stimare

 Cosa
ROI
Oriented
 Misure di valore
 Misure di processo
 Misure di prodotto


EasyTracking II - xplabs


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 20
1,3

1,25 18
1,25
23 f eb 2004 28 f eb 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

Number of Classes
1,1
1,1

1,05
1,05

11 60

23 f f eb2004
23 eb 2004 28 f f eb2004
28 eb 2004 4 mar 2004
4 mar 2004 99mar 2004
mar 2004 14 mar 2004
14 mar 2004 19 mar 2004
19 mar 2004 24 mar 2004
24 mar 2004 29 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
4,4 25
4,3
20
4,2
4,1 15
4 23 f eb 2004 28 f eb 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
Number of classes and methods
3,5 400
3,4
375
350
Number of Classes and Methods
400
325
375

DSI
300
350
275
325
250
300
1500 275
225
1400 250
200
225
1300 175
200
1200 150
175
125
150
1100
125
100
1000
100
75
900 75
50
800 50
25
25
700 00
600 23 f eb 2004
23 f eb 2004 28 f f eb2004
28 eb 2004 44mar 2004
mar 2004 9 9 mar 2004
mar 2004 14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 3 3 apr 2004
14 mar 2004 19 mar 2004 24 mar 2004 29 mar 2004 apr 2004

500
Test Classes Test Methods Application Classes Application Methods
Test classes Test methods Application classes Application methods


La tecnica del pomodoro
 Quando
 Ogni 30 minuti

 Processo
 La raccolta
 La rilevazione
 L’analisi

 Vantaggi
 Motivante
 Responsabilizzante
 Efficace
 No interruzioni


 La risposta XP






 XP: Avvertenze per l’uso

Cosa è XP

Cosa non è XP

Quando fallisce XP


Cosa è XP?!


L’importanza dei principi in XP2ed


Cosa non è XP?!
 Non è hacking
 Non è NO analisi
 Non è NO design
 Non è NO pianificazione
 Non è caos

 Non è un silver bullet


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


 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


Risorse – Da dove iniziare?


Domande?
 Riferimenti:
 Sito XPLabs:
http://www.xplabs.it
 Risorse:
http://www.xplabs.it/risorse.html
http://www.metodiagili.it
 Tecnica del Pomodoro:
http://www.tecnicadelpomodoro.it
 EasyTracking:
http://www.myagileprojects.com
 Gruppo XPLabs’ Friends- Italia:
http://it.groups.yahoo.com/group/xplabs-friends/
 Gruppo Extreme Programming - Italia:
http://it.groups.yahoo.com/group/extremeprogramming-it/
 Extreme Programming User Group – Italia:
http://www.xpug.it/


20080124 XPLabs Tour08 @UniAQ.it L'Aquila-IT [ITA]

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a 20080124 XPLabs Tour08 @UniAQ.it L'Aquila-IT [ITA]

Semelhante a 20080124 XPLabs Tour08 @UniAQ.it L'Aquila-IT [ITA] (20)

Mais de Francesco Cirillo

Mais de Francesco Cirillo (13)

20080124 XPLabs Tour08 @UniAQ.it L'Aquila-IT [ITA]