Extreme

Programming
Giuseppe Scanniello
Università della Basilicata
giuseppe.scanniello@unibas.it
 Why Extreme Programming
¢ CHAOS Report, Standish
Group, 1994
l 31.1% dei progetti non
vengono mai realizzati
l 52.7% dei progetti costerà
il 189% del costo
preventivato.
l 16.2% dei progetti viene
completato nei tempi e nei
costi stabiliti (larger
companies: 9%)
l I progetti completati hanno
approssimativamente il
42% delle caratteristiche e
delle funzionalità richieste.
Agile versus
tayloristic methods
¢ Agile methods ¢ Tayloristic methods
l Human-centric (plan-driven,
l Tacit knowledge traditional,
sharing heavyweight)
l Code-centric l Process-centric
l Replace l Explicit knowledge
documentation by l Documentation-
face-to-face centric
communication l Role specialization
l Generalists l Plan and control
l Plan and correct l Contract-focused
l Customer-focused
Knowledge sharing needed

t
Bu en
Kn sine o pm ss
ow ss l
led e ve oce
ge D Pr

Delivered
Software Technology
System Knowledge
XP un po’ di storia
¢ XP è un metodo di sviluppo proposto da
Kent Beck, dopo aver lavorato per parecchi
anni con Ward Cunningham.
¢ Un nuovo approccio al problema dello
sviluppo del software che renda le cose più
semplici degli attuali metodi a cui siamo
abituati.
¢ Secondo Beck e Cunningham l’XP è
basato sul “buon senso comune.”
Beck e l’XP

¢ “Tutto cambia nel software. I requisiti

cambiano. La progettazione cambia. Gli
aspetti commerciali cambiano. La
tecnologia cambia. I componenti del team
cambiano. Il problema non è il
cambiamento, di per sé, perché i
cambiamenti avverranno; il problema,
piuttosto, è l’inabilità di far fronte ai
cambiamenti quando essi avvengono.”
Beck … definisce l’XP

¢ “XP è un metodo per sviluppare

software: leggero, efficiente, low-risk,
flessibile, prevedibile e scientifico”
…e…
¢ Si distingue dagli altri metodi di sviluppo:
l È rapido, concreto, e fornisce continui feedback.
l È un approccio di pianificazione incrementale, il quale
rapidamente produce un pianificazione generale che prevede
l’evoluzione del progetto attraverso i suoi cicli di vita.
l “Flessibilizza” la schedulazione dell’implementazione delle
funzionalità rispettando i cambiamenti.
l Si basa su test sviluppati da programmatori e clienti per
consentire al software di evolvere rapidamente e catturare
difetti il prima possibile.
l Test, comunicazione verbale e codice sorgente sono gli
strumenti per comunicare la struttura del sistema e i suo
“intent”.
l Utilizza un processo di progettazione evolutivo che dura
quanto il progetto.
l I programmatori sono medi programmatori.
l Si basa a breve termine sull’istinto dei programmatori e a
lungo termine sull’interesse del progetto.
L’XP è innovativo???
¢ Molte delle pratiche sono vecchie come la
programmazione.
¢ In qualche senso è conservativo.
¢ Molte delle tecniche utilizzate sono in uso da decadi.
¢ In sintesi le innovazioni sono:
l Mettere tutte queste pratiche sotto un “unico
ombrello”.
l Essere sicuri che possono essere praticabili in ogni
contesto.
l Essere sicuri che il grado di supporto offerto da
queste pratiche sia il più alto possibile, per ogni
individui coinvolto nel progetto.
Alcuni paradossi (presunti)
¢ XP si focalizza su gruppi di sviluppo piccoli (2/10) che
naturalmente possono essere ingranditi se necessario,
ma non prima, altrimenti il risultato sarà generalmente
l’opposto di ciò che si intendeva.
l E’ buona norma, invece, aumentare il costo del
progetto su aspetti come macchine più veloci, più
specialisti in certe aree o uffici migliori per il gruppo
di sviluppo.
Alcuni paradossi (presunti)
¢ La qualità:
l Aumentare la qualità significa completare il progetto
in meno tempo.
l Il fatto è che appena il gruppo di progetto si abitua a
fare test intensivi e gli standard di codifica vengono
seguiti, il progetto inizierà a progredire più
velocemente.
l La qualità del progetto rimarrà assicurata al 100% -
grazie ai test – e questo a sua volta introdurrà
maggiore confidenza nel codice e, quindi, maggiore
facilità nel far fronte al cambiamento.
l Questo permetterà alle persone di programmare più
velocemente … e così via.
Alcuni paradossi (presunti)
¢ L’altra faccia della medaglia è la tentazione di
sacrificare la qualità interna del prodotto (i.e., quella
percepita dai programmatori) per ridurre il tempo di
rilascio del progetto, ritenendo che la qualità esterna
(i.e., quella percepita dai clienti) non sarà
eccessivamente deteriorata.
¢ Si ignora il principio “ognuno lavora meglio se gli è
permesso di fare un lavoro di qualità”.
¢ Ignorare questo significa:
l demoralizzato in gruppo nel lungo termine
l rallentare il progetto
l perdere più tempo di quello che si sperava di
guadagnare
Economia dello sviluppo del
software
¢ Sviluppare software rendendolo il più
economicamente vantaggioso,
spedendo risorse economiche molto
lentamente, avendo introiti veloce, ed
incrementando la produttività del
progetto.
Il costo dei cambiamenti

Costo del cambiamento nell’ingegneria del

software “tradizionale”
Il costo dei cambiamenti

¢ Questa curva non è più valida con una

combinazione di buone pratiche di
programmazione e di tecnologia
Il costo dei cambiamenti
¢ Non tutti sono d’accordo con questa supposizione.
¢ Se si decide di usare XP occorre accettare questa curva
come valida.
¢ L’ idea di base è che invece di progettare in funzione dei
cambiamenti (anticipazione del cambiamento),
progettiamo nel modo più semplice possibile, facendo
solo ciò che assolutamente necessario in un certo
momento.
¢ Grazie alla semplicità del codice, il test e l’integrazione
continua, i cambiamenti possono essere portati avanti
ogni volta che è necessario.
¢ Il modo differente di programmare aiuta i cambiamenti.
Learning to Drive

La metafora della scuola guida.

¢Guidare un autovettura non significa seguire la
giusta direzione, ma fare piccole correzioni con lo
sterzo prestando attenzione a quello che accade
intorno.

¢E’ necessario controllare lo sviluppo del software

facendo molti piccoli cambiamenti.
¢Non bisogna effettuare pochi grandi aggiustamenti.
¢Questo significa che sono necessari continui
feedback.
¢Per apportare correzioni ad un costo ragionevole.
XP l’essenza
¢ Variabli
l Cost, Time,
Quality, Scope
¢ Valori
l Communication, Simplicity, Feedback, and Courage
¢ Principi
l Provide feedback, assume simplicity, make
incremental changes, embrace change, quality work
¢ Pratiche
l Planning game, small releases, simple design,
automated testing, continuous integration, refactoring,
pair programming, collective ownership, 40-hour
week, on-site customer, coding standard, metaphor
Le quattro variabili Portata (scope)

Costo (cost) Tempo (time)

Qualità (quality)

¢ Tre possono essere stabilite da

elementi al di fuori del progetto (clienti
e project manager).
¢ Il valore della variabile libera è
stabilito dal gruppo di sviluppo in
accordo con le altre tre variabili.
Cosa c’è di nuovo?

¢ I project manager
l “Voglio che questi requisiti siano
soddisfatti per i primi del mese
prossimo, e devi fare in modo che la
tua squadra lavori con questo
obiettivo.”
¢ E la qualità?
 … hmmm !!!

¢ Naturalmente quando questo succede – e

sfortunatamente succede piuttosto spesso –
la qualità è la prima cosa che viene
sacrificata.
¢ E questo accade per una semplice ragione
che viene frequentemente ignorata:
l nessuno è in grado di lavorare bene quando è
messo sotto una forte pressione.
Il giusto compromesso

¢ XP rende visibili le quattro variabili a

tutti: programmatori, clienti e project
manager.
¢ I valori iniziali possono essere
manipolati finché il quarto valore
soddisfa tutti.
 Portata

Variabile libera Costo Tempo

Qualità

¢ E’ una buona idea lasciare la portata

(scope) del progetto come variabile libera.
¢ Il gruppo di sviluppo potrà decidere la
portata in termini di:
l Stima delle attività da svolgere per
soddisfare i requisiti del cliente.
l Realizzazione anticipata dei requisiti più
importanti, in modo che in ogni momento il
progetto offra la maggior funzionalità
possibile.
I quattro valori dell’XP

¢ Communication
¢ Simplicity

¢ Feedback

¢ Courage
 ¢ Communication

Communication ¢
¢
Simplicity
Feedback
¢ Courage

¢ Uno degli scopi è favorire la giusta

comunicazione tra le persone coinvolte in un
progetto.
¢ Bisogna favorire la comunicazione mediante
pratiche che non possono essere fatte senza
comunicare.
¢ Devono essere pratiche di breve durata.
 ¢ Communication

Communication ¢
¢
Simplicity
Feedback
¢ Courage

¢ Customer centric
l Scrivere "Stories", che siano
sempre disponibili
¢ Pair programming
¢ Task estimation
¢ Iteration planning
¢ Design sessions

“story” descrizione da parte di un cliente di una feature del sistema.

 ¢ Communication

Simplicity ¢
¢
Simplicity
Feedback
¢ Courage

¢ Qual è la cosa più semplice che potrà

sicuramente funzionare? (Coach to
programmers).
¢ La semplicità non è facile.
¢ E’ meglio fare una cosa semplice oggi
ed eventualmente cambiarla domani
con basso costo.
¢ Semplicità e comunicazione devono
mutuamente supportarsi.
 ¢ Communication

Feedback ¢
¢
Simplicity
Feedback
¢ Courage

¢ Feedback lavorano a differenti scale

di tempo.
¢ Minuti e giorni. (unit)

¢ Settimane e mesi. (story)

 ¢ Communication

Feedback ¢
¢
Simplicity
Feedback
¢ Courage

¢ Small Iterations
¢ Frequent deliveries

¢ Pair programming

¢ Constant code review

¢ Continuous integration

¢ Automated unit tests

 ¢ Communication

Courage ¢
¢
Simplicity
Feedback
¢ Courage

¢ Coraggio di buttare tutto quello che hai fatto.

E’ come se ci fosse stato:
l Crash improvviso del sistema a fine giornata.
l L’indomani riscrivi lo stesso codice
l La qualità e la leggibilità è …
¢ Coraggio di dire che il codice realizzato da
te o da un altro potrebbe essere fatto
meglio.
 ¢ Communication

Courage ¢
¢
Simplicity
Feedback
¢ Courage

¢ Seguire tutte le possibili alternative di

progettazione, e successivamente
scegliere la più semplice.
¢ Il coraggio deve sempre condurre ad
una soluzione più semplice.
¢ Stima - su una scala da 1 a 5, noi
possiamo farlo in 2
¢ Iteration planning.
I 5 principi di base dell’XP

¢ Provide feedback.
¢ Assume simplicity.

¢ Make incremental changes.

¢ Embrace change.

¢ Quality work.
 ¢ Provide feedback.
¢ Assume simplicity.
Provide Feedback ¢ Make incremental
changes.
¢ Embrace change.
¢ Quality work.

¢ Il tempo fra un’azione ed il suo feedback è

un aspetto critico da imparare.
¢ Gli sviluppatori forniscono ed ottengono
feedback prima possibile, li interpretano ed
agiscono sul sistema in funzione.
¢ Giorni non mesi per ottenere feedback dai
customer.
¢ Minuti non settimane per ottenere feedback
dai developer.
 ¢ Provide feedback.
¢ Assume simplicity.
Assume Simplicity ¢ Make incremental
changes.
¢ Embrace change.
¢ Quality work.
¢ Progetta solo quello che è importante per quello
che stai facendo.
¢ Si può risparmiare il 98% del tempo e dedicarlo
a cose realmente più complesse.
¢ Pianifica per il futuro e progetta per il riuso.
¢ Fai cose di qualità (tests, refactoring,
communication) e confida nel fatto che la
complessità viene dopo.
 ¢ Provide feedback.

Make Incremental ¢
¢
Assume simplicity.
Make incremental
Change ¢
changes.
Embrace change.
¢ Quality work.

¢ I problemi sono risolti con una serie di

piccoli cambiamenti.
¢ Progettare cambiamenti un po' per volta,
¢ Pianifica cambiamenti un po' per volta
¢ Il team cambia un po' per volta.
¢ Adotta il metodo di sviluppo XP un po' per
volta.

Embracing Change
¢ Provide feedback.
¢ Assume simplicity.
¢ Make incremental
changes.
¢ Embrace change.
¢ Quality work.

¢ Preserva la maggior parte delle

opzioni mentre risolvi la maggior parte
dei problemi pressanti.
 ¢ Provide feedback.
¢ Assume simplicity.
Quality work ¢ Make incremental
changes.
¢ Embrace change.
¢ Quality work.
¢ Il team deve essere composto da persone
che amano fare un buon lavoro.
¢ La qualità non dovrebbe essere ne
eccellente ne estremamente eccellente.
¢ Senza Qualità:
l you don't enjoy work;
l you don't work well;
l il progetto va a rotoli.
 Cosa sono le “Pratiche”???

¢ Che cosa richiede effettivamente l’XP

¢ Cosa sono esattamente queste pratiche
a cui abbiamo facciamo riferimento?
¢ Perché sarebbero capaci di portare
questo cambiamento di mentalità nello
sviluppo del software?
 Principi
¢ Provide feedback.

Le 12 Pratiche ¢ Assume simplicity.

¢ Make incremental changes.
¢ Embrace change.
¢ Quality work.
Valori Communication Variabli
¢ ¢Cost
¢ Simplicity ¢Time
¢ Feedback ¢Quality
¢ Courage ¢Scope

l on-site customer l refactoring

l planning game l pair programming
l small releases l collective
l simple designs ownership
l automated testing l 40-hour week
l continuous l coding standard
integration l metaphor
Practiche: On-site customer

¢ Molti progetti software falliscono perchè non

rilasciano software che soddisfa i requisiti
funzionali.
¢ I customer nell’XP rivestono un ruolo
fondamentale.
¢ I customer devono essere parte del team di
sviluppo
l Defines business needs;
l Answer questions and resolves issues;
l Prioritizes features.
Pratiche: Planning Game

¢ Coinvolge story cards

l Forniscono una stima per il customer
l Sono indipendenti tra loro
l Testabili
¢ I Customer scrivono story card e le
“priorizzano”.
¢ Developer stimano come “fare
andare” una story.
Pratiche: Planning Game
¢ Business decisions (customer)
l Portata: quale story dovrebbe essere
sviluppata.
l Priorità delle story.
l Date delle Release.
¢ Technical decisions (developers)
l Tempo stimato per le story.
l Elaborare le conseguenze di business
decision.
l Organizzazione del team e del processo
l Scheduling.
 Pratiche: Estimation

¢ Basate su storie simili del passato

(“yesterday’s weather”).
¢ Team effort.

¢ Ottenere una buona stima di una story

realizzandola.
¢ Ideal Engineering Time.
l Potrebbe essere un obiettivo.
¢ Velocità.
Pratiche: Small Releases

¢ Le release dovrebbero essere più piccole

possibili.
¢ Dovrebbero avere senso compiuto.
¢ Inseriscile nel sistema appena possibile.
l Fast feedback.
¢ Rilascia prima valuable features.
¢ Short cycle time.
l Pianifica 1-2 mesi piuttosto che 6-12 mesi.
Pratiche: Simple design

¢ “The right design”:

l Supera tutti i test.
l Evita la duplicazione di codice.
l Il minor numero di classi.
l Metodi di piccola lunghezza.
l Soddisfa tutti i business requirement.
¢ Evitare che cambiamenti in una parte del
sistema richiedano cambiamenti in altri parti del
sistema.
¢ Una buona progettazione consente di estendere
il sistema senza influenzare altre parti del
sistema.
Pratiche: Metaphor

¢ E’la pratica favorita degli XP programmers.

¢ Difficilmente sarà possibile iniziare lo sviluppo
di un sistema senza aver individuato una
metafora.
¢ Soprattutto la metafora aiuta il customer a
meglio comprendere il sistema.
¢ Una storia che clienti, programmatori, e
manager possono raccontare circa il
funzionamento del sistema:
l Come funziona l’intero sistema?
l Qual è l’idea generale del sistema?
Pratiche: Metaphor

¢ Esempio: ”questo programma

funziona come uno sciame d’api, che
cerca il polline a lo porta nell’alveare”
(sistema di information retrieval
basato su agenti).
¢ Non sempre la metafora è poetica. In
ogni caso il team deve usare un
glossario comune di nomi di entità
rilevanti per il progetto.
Pratiche: Testing

¢ Il testing è una pratica che vorrebbe essere

evitata da tutti I programmatori.
l Chi è d’accordo??? Chi non lo è???
¢ Nell’XP il testing è il più facile possibile e
prende poco tempo.
¢ Fornisce fiducia nel codice.
¢ E’ eseguito in coppia, per cui quello che uno
sviluppatore non vede può essere visto
dall’altro.
¢ Da fiducia al customer.
Pratiche: Testing

¢ Progettare i test mentre si produce il codice

l Unit test  developer
l Feature test  customer
¢ Non è necessario un test per ogni metodo.
¢ Il testing può essere utilizzato per guidare lo
sviluppo e la progettazione del codice.
l Semplifica il testing (uno dei goal delle
prossime settimane)
Pratiche: Testing

¢ Regression Testing
l Bisogna ritestare un software ogni qual
volta viene modificato.
• Assicura che non sono stati introdotti errori in
conseguenza di cambiamenti.
l I test cases sono stati progettati per essere
ripetuti - sono utilizzati per test successivi.
l Il testing di regressione può essere
eseguito su tutti i tipi di applicazione ( e-
Commerce and web-based systems).
Pratiche: Testing
¢ La pratica del testing pone enfasi sul
regression testing
l Unit test vengono eseguiti continuamente
l I test per feature del sistema vengono
eseguiti continuamente
l Una unit deve superare il test al 100%
¢ Acceptance test – mostra il progresso con il
quale le story sono eseguite.
¢ Possono essere utilizzati tool automatici o
framework per il testing.
l Es. JUnit, JMeter, HttpUnit, JProbe,
OptimizeIt
Pratiche: Refactoring

¢ Ristrutturare il codice senza cambiarne le

funzionalità.
¢ Goal: mantenere il design semplice
l Cambiare un cattivo design quando
identificato.
l Rimuovere code bad smells.
¢ Martin Fowler http://www.refactoring.com/
l “a change made to the internal structure
of software to make it easier to
understand and cheaper to modify without
changing its observable behavior.”
Pratiche: Pair programming
¢ Tutto il codice è sviluppato in coppia:
l un solo monitor;
l una sola tastiera.
¢ La persona che scrive il codice penserà al miglior
modo per realizzare un particolare metodo, il
collega farà lo stesso da un punto di vista più
strategico:
l E’ il modo giusto?
l Cosa potrebbe andare male?
l Cosa va controllato nei test?
l Esiste un modo per semplificare il sistema?
¢ I ruoli sono interscambiabili.
¢ La composizione delle coppie potrebbe cambiare.
Pratiche: Pair programming
¢ Vantaggi
l Non ci sono singoli esperti su singole parti
del sistema.
l Il codice è continuamente analizzato e
presenta pochi difetti.
l E’ più divertente ed è più economico a lungo
termine.
¢ Problemi:
l Il pair programmi non piace a tutti.
l Affinché questa pratica abbia successo le
persone devono essere abituate a lavorare
insieme.
Pratiche: Collective
ownership
¢ Il codice può essere cambiato da tutti i
membri del team.
¢ Tutti sono richiesti per migliorare
porzioni di codice cattivo.
¢ Ognuno è responsabile allo stesso
modo del sistema.
¢ Padronanza individuale del codice
tende a creare esperti … e questo è
male 
Pratiche: Collective
ownership
¢ Chiunque veda un’opportunità per
semplificare, facendo refactoring, non deve
esitare a farlo.
¢ Classi e/o metodi possono essere modificati
indipendentemente dal fatto che sia uno o
un altro il proprietario del metodo o della
classe.

¢ … l’uso di standard di codifica ed il

testing… aiutano
 Pratiche: Continuous
integration
¢ Ogni poche ore il sistema completo è integrato.
¢ Per questo scopo c’è la macchina di integrazione,
alla quale andrà ogni coppia di programmatori
quando essi avranno una classe che ha superato i
test di unità.
¢ Se dopo aver aggiunto la nuova classe insieme ai
suoi test di unità il sistema completo continuerà a
funzionare, l’attività è considerata completa.
Altrimenti il sistema sarà riportato in uno stato in cui
tutto funzionava.
¢ Se dopo un certo periodo di tempo il problema non è
individuato il loro codice sarà cestinato e dovranno
ricominciare da capo.
 Pratiche: 40 hour week

¢ Lo sviluppo funziona bene solo con persone

ben riposate.
¢ Lavorare in una postazione angusta per due
o più settimane e fare continuamente
straordinari è una bad practice.
¢ Fare straordinari aiuta solo la prima
settimana
l provoca danni le successive settimane.
¢ An XP programmers’ day può essere
estenuante:
l è possibile ottenere più risultati con 40 ore di
lavoro piuttosto che con 60.
Pratiche: Coding standards

¢ Il team deve adottare una codifica standard.

¢ Cercare di rendere il proprio codice quanto
più semplice possibile.
¢ Evitare di cambiare il codice in
conseguenza a preferenze sintattiche dei
singoli.
¢ Bisogna cercare di fare il minore lavoro
possibile: il codice dovrebbe esistere una
ed una sola volta.
XP Roles

¢ Developer
¢ Customer

¢ Tester

¢ Coach

¢ Consultant

¢ Program Manager

¢ Evangelist
 Further considerations

¢ Dopo appena un anno dalla pubblicazione del

primo libro sull’XP un grande furore si è
sollevato all’interno della comunità scientifica e
non dell’ingegneria del software.
¢ L’IBM ha commissionato uno studio con la
finalità di evidenziare i differenti pareri
sull’argomento.
 Risultato dello studio

Indagine IBM (Ottobre 2000): Che cosa pensi dell’eXtreme Programming?

Il pair programming e le 40
ore settimanali
¢ Il pair programming è maggiormente colpito
da critiche
l Project manager e molti programmatori che
hanno un senso eccessivo di proprietà sul
codice sviluppato non concordano sull’utilità
di questa pratica.
¢ Il mito delle 40 ore alla settimana, molti
sostengono che: “tutta questa faccenda
riguardo ai test va benissimo se hai tempo
da vendere, ma è un lusso che non ci si può
permettere nelle attuali condizioni di
mercato”
 Pair programming perceptions
in un esempio Universitario

Strongly disagree
Strongly agree
… altre critiche e
considerazioni
¢ Ci sono anche persone che sostengono che XP
funziona solo per buoni sviluppatori, ovvero,
persone come Kent Beck, che sono in grado di
progettare bene ed in modo semplice.
¢ L’ideatore dell’XP è uno dei pionieri nell’uso dei
framwork software, ideatore dei file CRC, autore
del framework per editor grafici JHotDraw e del
framewok per testing xUnit.
¢ Le pratiche raccomandate da XP non sono un’
invenzione del metodo; esistevano tutte da prima,
il merito è stato di metterle insieme e di provare
che funzionano.
Riferimenti utili e contact
information
¢ Extreme Programming–Embrace Change,
Addison-Wesley, 2000
¢ http://www.extremeprogramming.org/
¢ http://agilealliance.org/home
¢ http://www.refactoring.com/
¢ http://www.xprogramming.com/