Mais conteúdo relacionado
Semelhante a 20060703 XP Values and Principles @Essap2006 Varese-IT [ITA] (20)
Mais de Francesco Cirillo (10)
20060703 XP Values and Principles @Essap2006 Varese-IT [ITA]
- 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.
- 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.