✦ Struttura del processo XP ✦ User stories e engineering tasks ✦ Stima dei tempi e project velocity ✦ Spike Solution ✦ Pair Programming

1. Lezione 16: Pianificazione
in Extreme Programming
Corso di Ingegneria del Software
Laurea Magistrale in Ing. Informatica
Università degli Studi di Salerno
1

2. Outline
✦ Struttura del processo XP
✦ User stories e engineering tasks
✦ Stima dei tempi e project velocity
✦ Spike Solution
✦ Pair Programming
2

3. Struttura del processo XP
✦ Il processo di XP è iterativo, con più livelli
di iterazione
• Release Plan, pianificazione a medio-lungo
termine
• Iteration Plan, pianificazione a breve termine
3

4. Release Plan
Definizione dei
requisiti (User
Stories) e della
loro priorità
Stima dei rischi e
Cliente dei tempi
Ordinamento delle
User Stories
Iterazioni di
Sviluppatori sviluppo
Valutazione e
aggiustamenti del
piano
4

5. Release Plan
✦ Il Release Plan viene preparato all’inizio
del progetto, con la consapevolezza che
(almeno nelle prime versioni) sarà poco
accurato e che verrà aggiornato più volte
durante lo svolgimento del progetto
✦ Gli aggiornamenti del Release Plan
avvengono con periodicità fissa
(tipicamente ogni 2-4 iterazioni di
sviluppo) indipendentemente dal lavoro
svolto (time boxing).
5

6. Release Plan
✦ Il Cliente può cambiare le User Stories e
la loro priorità in qualunque momento
✦ Nella definizione delle User Stories gli
sviluppatori (Programmatori e Tester)
interagiscono con il Cliente finché i
requisiti non sono sufficientemente chiari
• è possibile chiedere al Cliente di suddividere User
Stories che sono troppo complesse da stimare o
da realizzare in una singola iterazione
6

7. Release Plan
✦ La scelta dell’ordine in cui implementare
le User Stories è fatta tenendo conto di:
• priorità per il cliente (Business Value)
• rischio (si cerca di implementare subito le User
Stories più rischiose)
• interdipendenze tra User Stories
✦ La valutazione della priorità spetta
esclusivamente al Cliente; la valutazione
del rischio e del tempo di realizzazione
spetta esclusivamente agli Sviluppatori
7

8. Iterazioni di sviluppo
✦ Lo sviluppo vero e proprio è suddiviso in
iterazioni di durata fissa scelta all’inizio
del progetto (tipicamente da 1 a 4
settimane)
✦ Ogni iterazione implementa una o più
User Stories scelte all’inizio dell’iterazione
nell’Iteration Plan
✦ Al termine di ogni iterazione viene
rilasciata una nuova versione del software
che il cliente può provare
8

9. Iteration Plan
Divisione delle prossime User Stories
in Engineering Tasks
Assegnazione a un programmatore e
stima dei tempi di ogni Task
Scelta delle User Stories da Implementazione dei test di
inserire nell’iterazione corrente accettazione delle User Stories
Progetto, implementazione, Esecuzione dei test di
Unit Test, Integration Test accettazione
Programmatori Tester
9

10. Iteration Plan
✦ I Programmatori e i Tester scelgono
autonomamente su quali task lavorare
(tra quelli previsti all’interno
dell’iterazione corrente)
✦ Se la stima dei tempi si rivela non
accurata, si modifica l’Iteration Plan e
NON la durata dell’iterazione
✦ alla fine dell’iterazione vengono incluse
nella release tutte e sole le User Stories
che hanno superato tutti i test
10

11. Stand-up Meeting
✦ Durante un’iterazione, ogni giorno si
svolge uno “Stand-up meeting” (incontro
in piedi)
• tutti i membri del team si riuniscono per parlare
brevemente di come procede il lavoro, dei
problemi riscontrati, di scoperte o idee
interessanti
• l’incontro si svolge in piedi per garantire la breve
durata
11

12. Integrazione continua
✦ L’integrazione del sistema viene fatta
almeno una volta al giorno
• spesso si usano strumenti automatici che
producono i “nightly builds”
• nessuno sviluppatore deve lasciare il codice a fine
giornata in uno stato che non si compila/collega
✦ Idealmente, l’integrazione viene fatta ad
ogni modifica (integrazione continua),
ovviamente se la modifica supera tutti i
test
12

13. User Stories
✦ Descrizioni di come si desidera che il
sistema risolva un particolare problema o
supporti un’attività del Cliente
✦ Vengono redatte dal Cliente usando il
linguaggio (naturale) a cui il Cliente è
abituato
✦ Fanno parte della documentazione
mantenuta e tracciata nel progetto
13

14. User Stories
✦ Le User Stories devono essere concise
• Tradizionalmente in XP ogni User Story è scritta
su una singola scheda per classificatori (es.
10x14cm)
• È possibile mantenerle in formato elettronico
(specialmente se il team di lavoro è distribuito su
più sedi)
✦ Le User Stories devono essere accessibili
a tutti i membri del team
14

15. User Stories
✦ Le User Stories devono essere:
• testabili (preferibilmente in maniera automatica;
in ogni caso in maniera ripetibile)
• riconosciute dal Cliente come avanzamenti
• completabili in una iterazione
• stimabili da parte del team di sviluppo
15

16. User Stories
✦ Esempio:
• L’utente può cercare i nominativi presenti
nell’archivio in base al cognome, o alla parte
iniziale del cognome. Inserendo il testo da cercare
viene presentato un elenco delle persone
corrispondenti, e l’utente può cliccare su un rigo
dell’elenco per vedere le informazioni di dettaglio.
16

17. User Stories vs Use Cases
✦ Le User Stories sono scritte dal Cliente
✦ Perché il Cliente accetti la responsabilità
di scrivere le User Stories è necessario
che:
• non usino un formalismo rigoroso
• siano ragionevolmente brevi
• il cliente non abbia la sensazione di essere
vincolato in maniera irreversibile a quello che
scrive
17

18. Engineering Tasks
✦ Gli sviluppatori suddividono ogni User
Story in Engineering Tasks
✦ Gli Engineering Tasks:
• rappresentano attività da svolgere per realizzare
le User Stories
• sono abbastanza piccoli da essere semplici da
stimare (un task non dovrebbe richiedere più di
3-4 giorni di lavoro di una persona)
• sono rappresentati da una descrizione molto
sintetica
18

19. Engineering Tasks
✦ Gli Engineering Task per la User Story
vista precedentemente come esempio:
• aggiunta del comando di ricerca nella pagina
principale
• aggiunta dell’indice al DB
• creazione della servlet per eseguire la ricerca
• creazione della pagina JSP per presentare i
risultati
19

20. Engineering Tasks
✦ La stima dei tempi di un Engineering Task
viene fatta dal Programmatore che si
candida a realizzare il task
✦ Il testing non è indicato esplicitamente
tra i task perché ogni task deve essere
testato (unit e integration testing), e il
tempo per il testing va conteggiato nel
tempo totale del task
✦ Se la stima di un task supera i 3-4 giorni,
il task viene suddiviso in task più piccoli
20

21. Stima dei tempi in XP
✦ Il tempo stimato per un Engineering Task
deve essere interpretato come una
previsione, non un impegno vincolante
• lo sviluppatore non deve a tutti i costi terminare il
task nel tempo stimato; specialmente se questo
significa derogare sulla qualità
✦ Nel valutare i tempi, gli sviluppatori
usano come unità di misura “giorni ideali”
o “ore ideali”
21

22. Project Velocity
✦ Al termine di ogni iterazione il tracker
valuta il rapporto tra il numero di ore
ideali dei task completati e il numero di
ore effettive di lavoro (Project Velocity)
✦ La Project Velocity viene presa in
considerazione nella scelta di quanti
Engineering Tasks inserire nell’iterazione
successiva
22

23. Esempio
✦ Supponiamo di avere:
• durata iterazione = 1 settimana
• 3 programmatori che lavorano 40 ore/settimana
• quindi, ore disponibili per iterazione = 120
✦ Misurando il lavoro prodotto vediamo
che:
• numero di ore ideali dei task completati per
iterazione = 90
• project velocity = 90/120 = 0.75 ore ideali/ore
reali
23

24. Esempio (cont.)
✦ Supponendo che nella prossima
settimana ci siano solo 4 giorni lavorativi:
• ore effettive della prossima iterazione = 120*4/5
= 96
• ore ideali realizzabili = 96*0.75 = 72
✦ Quindi inseriamo nell’Iteration Plan della
prossima iterazione un insieme di task la
cui somma dei tempi stimati sia 72 ore
24

25. Project Velocity
✦ La Project Velocity si mantiene
generalmente pressoché costante
• dopo le prime iterazioni, gli Iteration Plan
diventano accurati, e migliora anche l’accuratezza
dei Release Plan
• cambiamenti nella Project Velocity possono essere
indicatori del fatto che ci sono problemi (es.
perdita di motivazione, altre preoccupazioni ecc.)
25

26. Story Points
✦ In alcuni team che seguono XP, si
preferisce utilizzare per la stima una unità
di misura più astratta delle ore e dei
giorni ideali: gli Story Points
✦ Il numero di Story Points assegnati a un
task rappresenta l’impegno necessario
per realizzare il task in maniera relativa,
non assoluta
• se un task viene stimato in 10 story points, si
ritiene che richiederà il doppio del tempo di un
altro task stimato in 5 story points
26

27. Story Points
✦ Vantaggi degli Story Points
• gli esseri umani sono in genere più precisi nelle
valutazioni relative che in quelle assolute
• gli Story Points aiutano a evitare di confondere il
tempo ideale con il tempo reale, e le stime con
impegni vincolanti
✦ La Project Velocity viene espressa in story
points/ore effettive
27

28. Spike Solution
✦ Nelle fasi iniziali del progetto occorre
definire l’architettura
✦ La filosofia di XP richiede che
l’architettura sia validata
sperimentalmente prima di investire una
significativa quantità di lavoro in essa
✦ La validazione di un’architettura si
effettua realizzando una Spike Solution
28

29. Spike Solution
✦ Una Spike Solution è un sottoinsieme
funzionante del programma che realizza il
numero minimo di funzionalità necessario
per “attraversare” tutti i livelli
dell’applicazione
✦ Esempio:
• per una web application, una Spike solution
potrebbe consistere di una singola servlet che
effettua una singola query nel database e produce
una singola pagina di output tramite JSP
29

30. Spike Solution
✦ Una Spike Solution è sufficientemente
piccola da poter essere realizzata in pochi
giorni (idealmente non più di 2 giorni)
✦ I dubbi sulle scelte architetturali possono
essere risolti implementando più Spike
Solutions e confrontandole
✦ La Spike Solution rappresenta il punto di
partenza a cui aggiungere nuove
funzionalità nel corso del progetto
30

31. Spike Solution
✦ Le Spike Solutions possono essere usate
per consentire al team di familiarizzare
con tecnologie nuove
✦ Oltre che nella fase iniziale, è possibile
ricorrere a Spike Solutions ogni volta che
sia necessario confrontare più soluzioni
alternative (es. durante il refactoring)
✦ Le Spike Solutions possono essere usate
per verificare in anticipo i requisiti non
funzionali
31

32. Spike vs Prototipo
✦ Una Spike Solution serve al team di
sviluppo per comprendere e validare
un’architettura
• un prototipo serve all’utente per chiarire i requisiti
✦ Una Spike Solution è realizzata seguendo
i criteri di qualità dell’intero progetto
• un prototipo è realizzato come programma “usa e
getta”, quindi senza attenzione alla qualità
32

33. Pair Programming
✦ Tra le pratiche di XP, la più difficile da
accettare è il Pair Programming:
• due sviluppatori lavorano insieme allo stesso
Engineering Task sulla stessa postazione
• uno dei due “guida”: progetta e realizza la
soluzione del task
• l’altro esamina in tempo reale il lavoro prodotto
dal guidatore, segnala eventuali errori, chiede
spiegazioni se l’intento non è chiaro
• durante la sessione di lavoro i due membri della
coppia possono scambiarsi i ruoli; inoltre non
devono esserci “coppie fisse” per la durata del
progetto
33

34. Pair Programming
✦ Benefici
• riduzione del numero degli errori (ogni linea di
codice è stata vista da almeno due persone)
• aumento della chiarezza del programma (chi
guida deve progettare/scrivere in modo che l’altro
membro della coppia comprenda)
• la conoscenza della struttura del programma non
è confinata nella testa di una singola persona
• gli sviluppatori meno esperti possono imparare
lavorando in coppia con sviluppatori più esperti
• aumento della motivazione
34

35. Pair Programming
✦ Per i sostenitori, il Pair Programming
comporta una piccola perdita di
produttività (non lineare) compensata da
un aumento della qualità
• es. uno studio dell’università di Salt Lake City ha
misurato una perdita di produttività del 15% (e
non del 50%), e una riduzione del numero di bug/
problemi del 15%
35