1. XP: Values, Principles and Practices
Francesco Cirillo
Director, XPLabs - S.R.L.
francesco.cirillo@xplabs.com

2. 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
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

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?
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

4. 4
 Il problema
 “Why Do Projects Fail?”
 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
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

5. 5
 La risposta XP
Massimizzare le opportunità di business
Minimizzare il costo del cambiamento
Impiegare al meglio le risorse umane
Sapere come lavoriamo/stiamo lavorando
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

6. 6
 La risposta XP (continua)
 Per essere efficace oggi, il processo di sviluppo deve
consentire al cliente di massimizzare le opportunità di
business:
 dandogli la possibilità di identificarne di nuove
 assicurandogli un ritorno sugli investimenti più rapido e frequente
possibile
 consentendogli di cambiare quando ne senta la necessità
 In questo scenario, la funzione di produzione implicita nel
lavoro del team di sviluppo deve rendere possibile la
minimizzazione del costo del cambiamento
 A questo fine XP propone una serie di valori da condividere:
comunicazione, semplicità, feedback, coraggio
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

7. 7
 Massimizzare le opportunità di business
“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
 In XP il processo di esplorazione dell’area del problema è
molto dinamico ed è basato su una comunicazione intensa tra
il committente e il team di sviluppo
 Questo è essenziale per ridurre la complessità del
requirements engineering
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

8. 8
La natura delle user story
 Le user story possono essere spezzate in altre storie -splitting
- quando:
 diventa difficile stimarne il relativo sforzo
 diventa difficile scrivere il test d’accettazione
 non c’è più spazio sulla carta
 Lo splitting favorisce una più coesa e ortogonale
organizzazione del business
 Le user story splittate non rappresentano più valore da
consegnare agli attori del sistema, ma utilità da consegnare al
committente
 “related actions” di Jacobson...
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

9. 9
Legoland di utilità
 Splittando le user story il sistema del business è scomposto in
pezzetti di utilità che sono sempre più atomici, coesi,
ortogonali e comunicativi. Allo stesso tempo la complessità
dell’area del problema si riduce
 Il risultato è un insieme di piccoli pezzi di utilità nella forma di
carte disposte a caso su un tavolo
 Il semplice accostamento e confronto delle carte consente di
eliminare duplicazioni e fa sì che nuove opportunità di
business emergano spontaneamente
 In questa Legoland, ogni mattoncino - user story - rappresenta
un piccolo pezzo di utilità mobile e sostituibile
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

10. 10
Il Planning Game
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

11. 11
Ordine “gratuito”
 Attraverso la pratica delle user story si realizza un processo
spontaneo di auto-organizzazione
 Il sistema si muove da una serie di user story inizialmente
molto simili a use case, caratterizzate da una struttura del
valore ordinata e spesso complessa, a una situazione al limite
del caos, creata scomponendo il business in piccoli pezzi di
utilità, “mischiandoli” e quindi riassemblandoli in nuove
configurazioni di valore
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

12. 12
Vantaggi
 Release più piccole
 flussi di cassa immediati e continui
 Maggiore accuratezza nelle stime
 Tracking più efficace
 Maggiore probabilità di scoprire nuove opportunità di business
all’aumentare delle storie
 Maggiore conoscenza del sistema
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

13. 13
 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...
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

14. 14
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
Complessità del sistema
Tempo
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

15. 15
Ridurre la complessità marginale
 Come?
Mantenere bassa la complessità del sistema
Mantenere bassa la complessità intrinseca del problema
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

16. 16
 Mantenere bassa la complessità del sistema
 Il refactoring è il principale strumento per ridurre la
complessità del sistema. Senza cambiare il comportamento
esterno del sistema, il refactoring lavora su due direttrici:
 aumentare la capacità del codice di rivelare le intenzioni di 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 (…)
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
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

17.  Mantenere bassa la complessità del sistema 17
(continua)
 La malleabilità è la capacità di rimpastare le strutture di design
necessarie ieri, per plasmare quelle necessarie oggi per
accogliere le vecchie e le nuove funzionalità, mantenendo
bassa la complessità del sistema
 Il processo di ridurre la complessità marginale necessita la
continua applicazione di sforzo da parte dei membri del team
che hanno bisogno di cambiare il codice per riflettere la
sempre migliore comprensione del sistema
 La continua osservazione del codice consente al team di sviluppo di
identificare possibilità di refactoring.
 Attraverso il refactoring il team assicura continuamente che le
strutture dipendono dalle funzionalità; quando le funzionalità sono
cambiate, le strutture devono anche cambiare al fine di minimizzare
la complessità del sistema
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

18. 18
Perché rifattorizzare continuamente?!
 Perché rifattorizzare continuamente?
 Viaggio alla ricerca di un ordine “gratuito” (Kauffman)
 Ordine e complessità
 Design anticipatorio
 managing complexity with complexity
 Obiettivo del refactoring
 L’obiettivo del refactoring quindi, non sta in una spasmodica ricerca di
ordine ed equilibrio, ma nel riconoscimento di un ordine in grado di
sorgere spontaneamente al confine con il caos in cui il sistema
presenta caratteri di versatilità e proprietà omeostatiche che
rappresentano condizioni ottimali per l’evoluzione
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

19.  Mantenere bassa la complessità intrinseca 19
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
 Test-First
 incrementalità
 no gold plating
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
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

20. 20
La complessità può aumentare...
 Il processo non è deterministico
 Il “maialino” fa aumentare la complessità
 I due cappelli
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

21. 21
 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
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

22. 22
 Sapere come lavoriamo/stiamo lavorando
 Perché
 Per sapere come lavora la mia organizzazione
 Per misurare l’efficacia nella produzione di software
 Per accertare il progresso del progetto
 Ritmo
 Cosa
Functional
 Efficacia
Oriented
 Progresso
 Come
 Quando
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

23. 23
 Avvertenze per l’uso
 Cosa è XP?
 Cosa non è XP?
 Come arrivare a XP?
 Quando fallisce XP?
 Quando non serve XP?
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

24. 24
Cosa è XP?!
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

25. 25
Cosa è XP?!
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

26. 26
Cosa non è XP?!
 Non è hacking
 Non è NO analisi
 Non è NO design
 Non è NO pianificazione
 Non è caos
 Non è un silver bullet
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

27. 27
Come arrivare a XP?!
 Al fine di sfruttare i vantaggi di XP, i membri del team devono
realizzare l’importanza di:
 Principi - comunicazione, semplicità, feedback e coraggio
 Problem Solving - una serie di semplici pratiche per regolare
continuamente la complessità in un sistema in costante evoluzione.
Specificamente il team deve essere in grado di scomporre un
problema nei suoi aspetti ortogonali e affrontarli uno alla volta usando
il tool appropriato per ognuno
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

28. 28
Quando fallisce XP?!
 Mancanza di
 Presenza continua del cliente
 Una adeguata suite di test
 Rifattorizzazione continua
 Alto costo rifattorizzazione
 Tool
 XP fallisce se mancano i valori
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

29. 29
Quando non serve XP?!
Progetti non troppo complessi…
+
non soggetti al cambiamento...
+
senza scadenza
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

30. 30
 Conclusioni
 Improving Software Productivity
 Get the Best From People
 Make Steps More Efficient
 Eliminate Steps
 Eliminate Rework
 Build Simpler Products
 Reuse Components
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

31. 31
 Referenze bibliografiche
 Kent Beck, Extreme Programming Explained: Embrace the Change,
Addison-Wesley, 2000.
 Barry Boehm, Improving Software Productivity, Computer, September, 1987
 Francesco Cirillo, XP: Delivering the Competitive Edge in the Post-Internet
Era, http://www.xplabs.it/201010.html/
 Tom Demarco, Controlling Software Projects, Yourdon Press, 1982
 Michael Fagan, Advances in Software Inspection, IEEE Transactions on
Software Engineering, Vol SE-12, Number 7, July 1986
 Ivar Jacobson, Object-Oriented Software Engineering: A Use Case Driven
Approach, Addison-Wesley, 1992
 Stuart Kauffman, At Home in the Universe : The Search for Laws of Self-
Organization and Complexity, Oxford Univ Pr, 1996
 Steve McConnell, Rapid Development, Microsoft Press, 1996
 Dave Thomas e Andrew Hunt, Programming Ruby: A Pragmatic
Programmer's Guide, Addison-Wesley, 2000
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.

32. 32
Risorse – Da dove iniziare?
© 2006 Francesco Cirillo XP: Valori, Principi e Pratiche XPLabs - S.R.L.