2006 Talk di sera ERLUG (Emilia Romagna Linux User Group) Realizzati insieme ad Ilias Bartolini . 5a e ultima parte Presentazione di XP vers. 2.0 come descritta dal secondo libro bianco [nota: all'epoca era stato appena pubblicato ... riferimenti non precisi :-) ]

1. Parte 5
eXtreme Programming
05/04/07
59

2. eXtreme Programming
eXtreme Programming
Descritta nel secondo libro bianco
Beck, K and Andres,
Extreme Programming Explained:
Embrace Change (2nd Edition),
Addison-Wesley,
2005
05/04/07
60

3. eXtreme Programming
La metodologia XP
descritta nel primo libro bianco
Ken Beck,
Extreme Programming Explained,
Addison-Wesley,
1999
Verrà specificata come la 'prima XP'
05/04/07
61

4. eXtreme Programming
Per questa presentazione abbiamo preso
spunto, oltre che dalla 'letteratura ufficiale',
dall'articolo di presentazione del secondo libro
bianco scritto dal Prof. Michele Marchesi
www.agilexp.org/downloads/NuovoXP.pdf
Otto pagine consigliate
05/04/07
62

5. eXtreme Programming
Valori
Sono la base
filosofica della
metodologia.
I valori XP sono
mappabili nei
valori dell'Agile
Manifesto.
05/04/07
●
Comunicazione
●
Semplicità
●
Feedback
●
Coraggio
●
Rispetto
63

6. eXtreme Programming
Le pratiche
come sviluppare il software.
05/04/07
64

7. eXtreme Programming
Le pratiche XP
13 pratiche primarie
11 pratiche corollarie
Primarie:
possono essere applicate singolarmente.
Corollarie:
richiedono l'applicazione di una o più pratiche primarie
05/04/07
65

8. Pratiche Primarie XP 1/3
Analisi e pianificazione
Storie
(stories)
Ciclo settimanale
(weekly cycle)
Ciclo trimestrale
(quarterly cycle)
Margine di sicurezza
(slack)
05/04/07
sono brevi descrizioni di una funzionalità del sistema, la
cui implementazione ne guida lo sviluppo.
lo sviluppo avviene per cicli di una settimana, con una
riunione di inizio in cui si decide quali storie
implementare.
ogni tre mesi si pianifica lo sviluppo su scala più larga,
riflettendo anche sul processo usato, sul team,
sull’allineamento con gli obiettivi aziendali.
evitate di promettere cose che non si possono mantenere,
ed anzi abbiate sempre ad ogni iterazione delle storie che
si possono differire alla successiva, per mantenere un
margine di sicurezza in casi di problemi imprevisti.
66

9. Pratiche Primarie XP 2/3
Gruppo di sviluppo e fattori umani
il team di sviluppo deve lavorare in un ambiente aperto
Sedere insieme
capace di ospitarlo tutto, per massimizzare la comunicazione.
(sit together)
Team completo
(whole team)
il team deve essere composto di membri con competenze
diversificate e complementari, che abbiamo forte senso di
appartenenza e si aiutino a vicenda.
Ambiente di lavoro informativo
(informative workspace)
Energia sul lavoro
(energized work)
gli sviluppatori devono essere freschi e riposati, per poter
concentrarsi sul lavoro e rendere al massimo; quindi, occorre
limitare gli straordinari e ciascuno deve avere il tempo per
una vita privata.
Programmazione a coppie
(pair programming)
05/04/07
l’ambiente di lavoro deve essere fornito
di cartelli indicanti lo stato del progetto
ed il lavoro da svolgere.
il codice deve essere sempre scritto da
una coppia di programmatori, seduti ad
un unico terminale.
67

10. Pratiche Primarie XP 3/3
Progettazione
l'XP rifugge dal “big design upfront”, e cerca di scrivere il
Progetto
prima
possibile
del
codice
per
ottenere
feedback,
incrementale
migliorandone poi la struttura in continuazione. L'XP
(incremental design)
suggerisce di progettare incrementalmente durante tutto lo
sviluppo.
Programmazione
guidata dai test
(test-first programming)
Build di dieci
(ten-minute build)
prima di modificare o aggiungere del codice, scrivete dei test
per verificare lo stesso codice. Ciò risolve quattro problemi:
cowboy coding; basso accoppiamento ed alta coesione del
codice; fiducia dei propri compagni; buon ritmo di lavoro.
Codifica e rilascio del software
il “build” del sistema, inclusa l’esecuzione dei test
minuti
automatici, deve durare non più di dieci minuti, per
poter essere eseguito spesso ed ottenere il necessario
feedback.
Integrazione continua
(continuous integration)
05/04/07
i cambiamenti e le aggiunte al codice vanno integrati
nel sistema ogni due ore, per avere un feedback
immediato sui possibili problemi di integrazione
68

11. Pratiche Corollarie XP 1/3
Analisi e pianificazione:
le persone la cui vita sarà influenzata dal vostro sistema
Coinvolgimento
devono diventare parte del team, contribuendo alla
reale del cliente
pianificazione trimestrale e settimanale.
(real customer involvement)
Rilasci
incrementali
(incremental deployment)
nel caso di rimpiazzo di un sistema “legacy”, iniziate da subito
a sostituirne delle funzionalità, e procedete gradualmente a
rimpiazzarlo tutto. Evitate un approcccio “tutto o niente”.
Contratti con
funzionalità negoziate
(negotiated scope contract)
Pay-per-use
(pay-per-use)
05/04/07
i contratti dovrebbero avere tempo, costi e livello di
qualità fissi, ma le funzionalità da realizzare
dovrebbero essere negoziate durante la realizzazione
stessa. É meglio una serie di brevi contratti in
successione, per ridurre il rischio.
se possibile stipulate contratti in cui il cliente paga chi
produce il software proporzionalmente all'uso dello stesso da
parte degli utenti: collegare il flusso di denaro allo sviluppo
del sistema fornisce informazioni tempestive ed accurate.
69

12. Pratiche Corollarie XP 2/3
Continuità del
(team continuity)
Gruppo di sviluppo e fattori umani
i gruppi di sviluppo devono rimanere per quanto
team
possibile gli stessi, anche attraverso progetti diversi.
Le relazioni che si formano in un gruppo efficace
sono preziose: è sbagliato trattare le risorse umane
come “caselle” da riempire, senza tenere conto delle
persone e delle relazioni esistenti tra di esse.
Team che si restringono
(shrinking teams)
man mano che il team diventa più capace e
produttivo, mantenete il suo carico di lavoro costante,
ma
riducetene
gradualmente
la
dimensione,
mandando i membri in più a formare altri team.
Questo principio contraddice in parte la “Continuità
del team”.
Progettazione
tutte le volte che trovate un errore, eliminatelo ed
Analisi delle cause
eliminatene anche le cause. In tal modo non solo
prime
correggerete l'errore, ma impedirete anche il
(root-cause analysis)
ripetersi di errori simili.
05/04/07
70

13. Pratiche Corollarie XP 3/3
Codifica e rilascio del software
Codice e test
(code and tests)
Codice condiviso
(shared code)
Una singola base di
codice
(single code base)
Rilasci giornalieri
(daily deployment)
05/04/07
solo il codice e i test sono i manufatti permanenti da
mantenere nel tempo. Gli altri documenti necessari si
possono generare a partire dal codice e dai test.
ogni membro del gruppo di sviluppo deve poter
intervenire in ogni momento su qualsiasi parte del
sistema.
ci deve essere una sola versione “ufficiale” del
sistema. Si può crearne un ramo temporaneo, ma non
deve durare più di poche ore. Le diverse versioni
commerciali del prodotto (branch commerciali) non
rientrano in questo caso.
ogni notte, bisogna rilasciare in produzione il
software. Avere sul PC del software diverso dalla
versione ufficiale rilasciata è rischioso e costoso.
71

14. Confronto con le pratiche del primo XP
Eliminata:
- Metafora
Ridotta:
- Cliente sul posto
Date per acquisite:
- Standard di
codifica
- Refactoring
Fonte dell'immagine (poi evidenziata):
www.agilexp.org/downloads/NuovoXP.pdf
05/04/07
72

15. eXtreme Programming
I principi
Sono il ponte tra i valori, sintetici ed astratti,
e le pratiche, che dicono come
effettivamente sviluppare il software.
Fonte: www.agilexp.org/downloads/NuovoXP.pdf
05/04/07
73

16. eXtreme Programming
Principi XP
●
●
●
●
●
●
●
05/04/07
Umanità
Economia
Mutuo beneficio
Auto-similarità
Miglioramento
Diversità
Riflessione
●
●
●
●
●
●
●
Flusso
Opportunità
Ridondanza
Fallimento
Qualità
Piccoli Passi
Accettare la responsabilità
74

17. eXtreme Programming
Domande ?
05/04/07
75

18. Saluti e Riferimenti
05/04/07
76

19. Riferimenti
Libri:
●
Extreme Programming Explained [2nded] – Kent Beck
●
Refactoring – Martin Fowler
●
Test Driven Development – Kent Beck
●
Lean Software Development – M.&T. Poppendieck
●
Agile Software Development with SCRUM – K.
Schwaber, M. Beedle
●
Agile Software Development – A. Cockburn
●
Pair Programming Illuminated – L. Williams, R. Kessler
05/04/07
Agile @ ERLUG
77

20. Riferimenti
Su internet:
●
http://www.extremeprogramming.org/
●
http://www.testdriven.com/
●
http://martinfowler.com/articles.html
– New
Metodology – M. Fowler
– ...
●
http://alistair.cockburn.us/index.php -> Articles
●
The Cathederal And The Bazaar – E. Raymond
●
...
05/04/07
Agile @ ERLUG
78