Manuale per applicare le metodologie agili in ambiti aziendali

1. Manuale Agile - Stelnet
Manuale Agile Stelnet
Autori: Alberto Buschettu
1
Stelnet.com

2. Manuale Agile - Stelnet
Indice
Indice....................................................................................................................................................2
1. Manuale aziendale Agile Stelnet..................................................................................................3
1.1. Introduzione ..............................................................................................................................3
1.2. Per tutti: Operazioni preliminari per un progetto......................................................................4
1.3. Per tutti: Cosa è una user story..................................................................................................6
1.4. Per tutti: Come procedere .........................................................................................................8
1.5. Sviluppatori: Come si sviluppano i task di una user story...................................................... 11
1.6. Sviluppatori: Programmazione a coppie .................................................................................12
1.7. Sviluppatori: Best practice per la programmazione agile .......................................................12
1.8. Sviluppatori: Best practice per la progettazione .....................................................................13
1.9. Glossario .................................................................................................................................13
2
Stelnet.com

3. Manuale Agile - Stelnet
1. Manuale aziendale Agile Stelnet
In tale capitolo, verrà illustrato il manuale agile che tutti i componenti dell’azienda
e tutti coloro che entreranno a farne parte, dovranno conoscere. Si badi che, larga
parte dei paragrafi, è organizzata in questo modo: il titolo può contenere la dicitura
Customer o Sviluppatori o per Tutti, per indicare a quale ruolo è indirizzato il
contenuto del paragrafo.
1.1. Introduzione
Cos’è una metodologia agile? La realizzazione del software, comporta una serie di
passaggi, necessari, per poter avere un prodotto con il quale un cliente si trovi
soddisfatto nell’uso dello stesso. Non ci si improvvisa e si inizia a scrivere il codice di
un software, bensì bisogna attenersi ad un processo ovvero ad una serie di regole
consigliate dagli esperti del settore (in particolare esperti nella disciplina
dell’ingegneria del software) da seguire al fine di ottenere al meglio i risultati
sperati. Sin dai primordi dell’informatica, il tipo di processo utilizzato è stato il
cosiddetto modello a cascata. In questo,
Figura 1 Processo di sviluppo a cascata
Si inizia con la fase di analisi dei requisiti, con la quale si chiede ai clienti del
software cosa vogliono ottenere dallo stesso. Uno dei problemi che si sono via via
evidenziato sul processo a cascata, è stato la rigidità dello stesso; per cui, qualora in
una fase avanzata del processo, si ritiene necessario variare o aggiungere un
requisito, allora il costo da sostenere per tale modifica diventa molto oneroso. Le
metodologie agili, vengono incontro a questa ed altre necessità e rendono il processo
di sviluppo più produttivo e con un livello di accettazione molto più elevato da parte
del cliente. Infatti, nelle metodologie agili, il cliente è al centro dell’attenzione e
viene coinvolto in tutte le fasi del processo. Nel caso di stelnet, essendoci varie
3
Stelnet.com

4. Manuale Agile - Stelnet
tipologie di metodologie agili, abbiamo scelto l’XP programming istituzionalizzandone
la pratica. Implementare l'XP significa integrare le 12 pratiche di cui si compone, o
un suo sottoinsieme, nel processo di sviluppo aziendale.
Tra le caratteristiche più interessanti dell'XP, ritengo utile annoverare le seguenti:
- in ogni momento la squadra di sviluppo dispone di un software funzionante anche se
non completo di tutte le sue funzionalità;
- la squadra di sviluppo collabora attivamente con il committente, al fine di rilevare i
feedback sul prodotto già durante il processo di sviluppo e non quando il prodotto è
ultimato;
- è il collaudo a guidare lo sviluppo e non il contrario: in tal modo si ha una costante
consapevolezza di cosa funziona correttamente e cosa no.
Extreme programming è un processo di sviluppo basato su quattro valori fondanti:
• Comunicazione - tra cliente e team di sviluppo e all'interno dello stesso team,
come risorsa necessaria affinché tutte le informazioni siano correttamente
elaborate al fine di ottenere un sistema più aderente possibile alle esigenze del
cliente;
• Feedback - frequenti e costanti da parte del cliente, durante tutta la vita del
progetto per riuscire a governare i possibili ed inevitabili cambiamenti;
• Semplicità - per mantenere il design del sistema e il codice più puliti possibile, in
modo da favorire le modifiche e la manutenzione;
• Coraggio - nel modificare il sistema, per l'uso di pratiche di verifica del corretto
funzionamento del sistema anche dopo numerose modifiche .
1.2. Per tutti: Operazioni preliminari per un progetto
Quando un cliente richiede un software a Stelnet srl, bisogna innanzitutto iniziare a
conoscere il cliente, specie se esso è nuovo e non si hanno dati storici di riferimento
per quanto riguarda le esigenze del cliente. Delle discussioni al telefono o meglio
degli incontri con i clienti, rappresentano delle situazioni ideali in cui apprendere
caratteristiche e necessità di un cliente. Qualora il dominio oggetto dell’applicazione
richiesta, sia nuovo per stelnet, allora sarà necessaria una fase preliminare di analisi
del dominio, in cui verranno messe alla luce le informazioni più importanti e
strategiche al fine di iniziare i lavori. Qualora il dominio sia ben conosciuto dai
clienti, saranno loro stessi a fornire queste indicazioni, evitando a stelnet le
operazioni di reperimento delle informazioni.
Prima di iniziare entrare nel vivo delle attività agili, dovrà essere definito il team.
L’organizzazione da creare è la seguente, per cui a Stelnet, per ogni progetto
dovremo avere la seguente organizzazione del personale in ruoli:
4
Stelnet.com

5. Manuale Agile - Stelnet
Figura 2 Ruoli nell'XP programming a Stelnet
Per identificare le persone a cui affidare i ruoli, attenersi al seguente schema:
Ruolo Cosa fa Competenze richieste
Coach è il responsabile Deve conoscere ogni
dell'intero processo: aspetto delle
deve guidare il gruppo metodologie agili ed
se questo devia dal avere esperienza nella
regolare funzionamento gestione dei team di
lavoro
Manager Si occupa di visionare Capacità interpersonali
l’andamento del avanzate e gestione
progetto. Tiene traccia delle risorse finanziarie
delle riunioni e
comunica con il tracker
Tracker Il tracker è colui che Deve avere buone
segue il team e competenze in termini
controlla la velocity, di organizzazione dei
cioè la velocità con cui team di sviluppo e nelle
gli sviluppatori riescono metriche di processo e
a programmare di prodotto
Developer il suo valore principale è Competenze con vari
la comunicazione: non linguaggi di
basta che il codice programmazione,
funzioni correttamente, progettazione con uml e
deve anche seguire gli svariati tools di
standard di progettazione e
codifica,riorganizzare il sviluppo
codice, scrivere i test,
ecc.
Customer proxy Deve imparare a Conoscenze avanzate
scrivere delle buone sugli argomenti
storie e scrivere test riguardanti il software
funzionali. E’ una da sviluppare
persona specializzata (conoscenze del
nel dominio dominio).
dell’applicazione e può
essere anche personale
stelnet. Può sostituire il
customer
Customer E’ il cliente che Deve conoscere gli
5
Stelnet.com

6. Manuale Agile - Stelnet
commissiona il obbiettivi che intendere
software. Deve raggiungere con
imparare a scrivere l’utilizzo del software e
buone storie deve le funzionalità che
prende decisioni deve saranno necessarie
imparare a scrivere test
funzionali
Tester Deve avere la capacità deve essere capace
di aiutare i customer a eventualmente di
scrivere i test di eseguire dei test
accettazione. Grafica i automatici e di
risultati ed avvisa tutto rappresentare
il team sui risultati dei attraverso grafici
test l’andamento dei test di
accettazione.
Figura 3 Schema assegnazione ruoli
1.3. Per tutti: Cosa è una user story
Una user story è una breve descrizione di qualcosa che vuole il cliente. Il customer
(che è il cliente stesso o una persona rappresentativa del cliente) o il customer proxy
scrivono le user story. Una descrizione fatta attraverso una user story, può essere
arricchita da altre user story anche durante lo sviluppo, ovvero quando i
programmatori stanno già facendo il lavoro. Ogni user story è caratterizzata da una
priorità, che il customer/customer proxy esprime attraverso una scala ordinale di
questo tipo:
1: Questa cosa la vorrei, ma non è poi così importante;
2: Questa cosa che voglio è importante;
3: Questa cosa che ho scritto è necessaria per forza.
Lo sviluppatore, per ogni user story, inserisce il cosiddetto rischio e stima anche il
tempo per realizzare tutto il codice completo e funzionante per potere fare ciò che
viene richiesto nella storia. Il rischio viene espresso attraverso la seguente scala:
1: Conosco bene cosa è necessario fare per realizzare questa storia (ho già fatto cose
simili in passato)
2: Non ho mai fatto cose uguali in passato, ma simili, ed ho comunque capito in che
modo affrontare la realizzazione
3: Non ho capito bene la user story e sono molto confuso.
Ciascuna user story deve essere scritta a mano da parte del customer, su un foglietto
detto story card. Il formato da utilizzare per la stampa delle stesse, è il seguente:
6
Stelnet.com

7. Manuale Agile - Stelnet
Tabella 1 Story Card
DATE:___________ TYPE OF ACTIVITY: NEW:____ FIX:____ ENHANCE:____FUNC.TEST
STORY NUMBER:_________ PRIORITY: USER:_____ TECH:_____
PRIOR REFERENCE:_______
RISK:________________ TECH ESTIMATE:_______________
TASK DESCRIPTION:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _
____________________________________________________
NOTES:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
___
Tabella 2 Story Card
Su DATE il customer scrive la data corrente. Il TYPE OF ACTIVITY può essere:
• NEW, se la user story descrive una nuova caratteristica;
• FIX, se la user story descrive un’aggiustamento ad un’altra user story;
• ENHANCE, se la user story rappresenta un incremento ad una user story
precedente.
Su STORY NUMBER, andremo a porre un identificativo univoco della user story
(es.:US1.1).
Su PRIORITY: USER, il customer scriverà la priorità da 1 a 3 seguendo la scala
illustrata pocanzi.
Su PRIORITY: TECH, lo sviluppatore porrà una priorità della storia da 1 a 3 a
seconda dell’importanza che lui ritiene.
La PRIOR REFERENCE: può essere lasciata vuota.
7
Stelnet.com

8. Manuale Agile - Stelnet
Su RISK, lo sviluppatore inserirà un valore di priorità da 1 a 3 seguendo la scala
illustrata pocanzi.
Su TECH ESTIMATE, lo sviluppatore, inserirà il tempo espresso in story points, che
sarà necessario al fine di sviluppare completamente quella storia. Lo story point è
un’unità di misura scelta dagli sviluppatori. A stelnet, abbiamo deciso che 1 story
points= 1 giornata lavorativa di 8 ore di uno sviluppatore. Il valore indicato dovrà
comprendere tutto il tempo necessario per progettare, implementare, testare gli
artefatti per realizzare la user story.
Figura 4 Attività di Stelnet con XP programming
Una volta che una user story diventa una user story definitiva, ovvero è stata
eventualmente oggetto di splitting, di aggiustamenti delle stime, allora i customer
scrivono gli acceptance test.
1.4. Per tutti: Come procedere
L’XP programming, inizia con la fase di Pianificazione, ed esattamente con una delle
sue sottofasi che è la Release Planning.
La prima cosa da fare, è individuare i seguenti due elementi:
1. Il Business Goal: ovvero il perché si vuole realizzare il software e cosa si vuole
ottenere da questo;
2. gli User: chi sono i destinatari finali del software.
Dovrà quindi, essere individuato definitivamente il team, come spiegato con i ruoli
dell’XP programming. Si dà quindi avvio alla scrittura delle user story.
Man mano che i customer scrivono le storie, ciascuna su una story card, ne scrivono
8
Stelnet.com

9. Manuale Agile - Stelnet
la data, il tipo di attività, il numero della storia, la priorità, la descrizione ed
eventuali note, la passano agli sviluppatori. Questi ultimi dovranno inserire sempre
nella story card: la priorità, il rischio e la stima in story points. Se gli sviluppatori non
hanno capito bene la storia, oppure non riescono a stimarla perché è troppo
generica, possono richiedere ai customer di:
a) Riscrivere la storia;
b) Splittare (suddividere) la user story in più user story.
Fatto tutto questo, i customer stessi, devono decidere in che modo rilasciare le
releases. Infatti nell’XP programmino, una pratica è quella di rilasciare man mano
che il lavoro và avanti, una serie di versioni del software, che inizialmente
contengono poche funzionalità, che divengono via via cumulative, per arrivare al
prodotto finale che contiene tutte le funzionalità inserite nelle user story. Per cui
ogni release contiene una o più user story completamente realizzate e testate.
Come fà il customer a scegliere in che modo fare le releases? In due modi:
• Story-Driven Commitment: il customer dice: nella prima release voglio queste N
user story, mentre nella seconda le successive M. Cioè il customer sceglie quali
storie devono essere implementate nelle varie release. Inserirà nella prima
releases, le user story che riterrà sia necessario avere per prime.
• Date-Driven Commitment: Il customer dice: voglio la release 1 alla data
xx/xx/20xx. Gli sviluppatori calcolano il costo cumulativo delle storie che possono
essere inserite nella release in funzione di quella data.
Terminata la stesura delle releases, avremo una tabella di questo tipo, che è il piano
delle releases:
Release Stories Story points TOTALI
1 US1, US2, US3,US4,US5 110
2 US7,US8,US9,.. 130
.. .. ..
Figura 5 Piano delle releases
Il passo da eseguire ora, è quello della scelta delle iterazioni (iteration planning).
Infatti, l’XP programming funziona anche grazie alle iterazioni. Un’iterazione, è un
operazione, della durata di due o più settimane, in cui, gli sviluppatori
implementano una o più user story. In sostanza, si inizia facendo un primo iteration
planning meeting, ovvero una riunione in cui partecipano tutti quanti. Ecco cosa si fa
in un iteration planning meeting:
1. Si prende in esame una relase, nell’ordine scelto nella fase precedente di
release planning (ovvero release1, release2, etc…);
2. Si commenta ogni user story della release, nell’ordine in cui è stato scelto di
implementarle (in base alle priorità scelte dai customer, come fatto in
precedenza). Si analizzano un numero di user story che riesca a coprire il
tempo pattuito (generalmente due settimane a Stelnet);
9
Stelnet.com

10. Manuale Agile - Stelnet
3. Per ogni user story, gli sviluppatori, individuano una serie di compiti, o “task”
che è necessario affrontare per potere realizzare completamente la user
story;
4. In base alle stime effettuate dagli sviluppatori, si decide di comune accordo,
di suddividere la release sotto esame in “iterazioni”, ovvero in sessioni, della
durata di almeno due settimane, in cui vengono sviluppate alcune user story;
5. Ogni release viene quindi suddivisa in più iterazioni. Si decide quale user story
andranno sviluppate nella prima iterazione;
6. Terminata la prima iterazione, che corrisponde al rilascio da parte degli
sviluppatori delle user story della release sviluppate e testate, si fa un nuovo
iteration planning meeting e si continua a decidere quali storie della release
sviluppare per prime.
Cosa fà un programmatore, durante ogni iterazione? I task che vengono individuati
sulla base delle user story da sviluppare durante un’iterazione, vengono scritti,
ognuno, su una task card, ovvero un foglio, del quale riportiamo di seguito un
formato di stampa, in cui viene descritta più o meno nel dettaglio il lavoro di
sviluppo che uno sviluppatore deve affrontare per realizzare una porzione di
funzionalità della user story. Ogni giorno, verrà effettuato uno Stand Up Meeting.
DATE:___________
STORY NUMBER:_________ SOFTW ENGINEER:_________ TASK ESTIMATE:___________
TASK DESCRIPTION:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
___
10
Stelnet.com

11. Manuale Agile - Stelnet
SOFTW ENGINEER'S NOTES:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
__ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _
________________________________________________________
____________
Tabella 3 User Story Card
Una volta scritti i task, ciascun programmatore ne prende uno e si prende la
responsabilità di completarlo, stimandone il tempo di realizzazione. Attenzione, se
un task richiede più di 2 giorni di lavorazione, allora andrà splittato.
Al termine di una iterazione, sarà possibile calcolare la velocity, ovvero la velocità
con cui si riesce a sviluppare le storie. Questo valore è importante, perché se si
conosce, durante gli iteration planning meeting, è possibile stimare velocemente
quante user story inserire per ogni release.
Terminata una release, il software potrà essere rilasciato al cliente per poterlo
utilizzare. Al rilascio dell’ultima release, il software può ritenersi ultimato.
1.5. Sviluppatori: Come si sviluppano i task di una user story
Di una task card, non viene mai generato direttamente il codice, c’è una fase
preliminare di progettazione, in cui si fa uso delle crc cards. In sostanza si fa questo:
gli sviluppatori che devono realizzare i task di una user story, si riuniscono ed iniziano
a creare le crc cards:
Class Nome della classe
Responsability Collaborators
Lista della azioni che Nomi delle classi che
deve poter fare la classe vengono utilizzate
Tabella 4 CRC card
Una crc card, è un pezzo di carta, in cui viene scritto un concetto che ha una certa
autonomia nel task da realizzare, si parla in questo caso di classi. Ogni crc card è una
classe. Queste carte, via via che vengono scritte, vengono poggiate su un tavolo o
appese su una bacheca di sughero. Se due crc card sono parzialmente sovrapposte,
significa che hanno delle caratteristiche in comune, ed in questo caso si potrà
decidere se realizzare una ulteriore crc card dalla quale le crc card ereditano le
caratteristiche in comune.
Ogni crc card definitiva viene sviluppata nel linguaggio di programmazione scelto:
11
Stelnet.com

12. Manuale Agile - Stelnet
1. Si scrive l’unit test;
2. Si scrive una porzione di codice;
3. Si fa partire l’unit test;
4. Se funziona, allora si fa un po’ di refactoring e si passa a fare l’unit test di una
successiva porzione, altrimenti si corregge il codice;
5. Se inizio ad avere più porzioni testate, allora le unisco e faccio ripartire i test
sul codice unito (integrato). Se funziona riprendo dal punto 1.
6. Sviluppato tutti i task di una user story: ora si esegue il test di accettazione.
1.6. Sviluppatori: Programmazione a coppie
Gli sviluppatori dovrebbero lavorare a coppie. Ciascun programmatore ha un suo
ruolo:
A. Il Driver, che scrive il codice;
B. Il Navigatore guarda sullo schermo quello che scrive il Driver e ne commenta
l’operato.
I ruoli tra i due vengono scambiati ogni giorno.
1.7. Sviluppatori: Best practice per la programmazione agile
La programmazione agile è basata sul testing. Il testing unitario, è una porzione di
codice che viene utilizzata per vedere se una parte di codice funziona regolarmente.
A seconda del linguaggio da utilizzare per l’implementazione, è buona regola
individuare un tool che permetta di effettuare il testing unitario. Per trovare un tool
di testing, è sufficiente cercare con un motore di ricerca con le parole chiavi: unit
testing tool seguito dal linguaggio di programmazione da utilizzare.
Gli sviluppatori devo seguire il seguente approccio:
12
Stelnet.com

13. Manuale Agile - Stelnet
Tabella 5 Diagramma da seguire per scrivere codice
1.8. Sviluppatori: Best practice per la progettazione
Utilizzare le crc cards. Cosa sono? Sono dei pezzi di carta, di dimensioni
10 x 15 che contengono dei concetti da sviluppare.
Gli use case sono utili. Se utilizzati è possibile aiutare i customer a creare gli
acceptance test.
Devo inoltre tenere a mente che, è necessario:
• Semplificare il codice;
• Rimuovere il codice duplicato;
• Astrarre;
• Usare le spike se non si riesce a stimare una storia già splittata;
• Usare il sistema di versioning SVN.
Quando si ha qualche dubbio nei confronti di una user story per un cliente, è
preferibile l’incontro con lo stesso “faccia a faccia”.
1.9. Glossario
Acceptance Test: sono dei test, scritti dal customer (magari aiutati dal tester) che
indicano alcune prove da impartire sulle funzionalità realizzate per una user story, al
fine di verificare se quella parte di codice realizza quello che ci si attende.
13
Stelnet.com

14. Manuale Agile - Stelnet
Collective Code Ownership: tutto il codice è di proprietà di tutti gli sviluppatori.
Chiunque può variare il codice. Gli sviluppatori utilizzano uno stile di codifica
standard per far sì che sia più semplice fare le modifiche.
Customer: è la persona che prende le decisioni di business. Può essere il cliente
reale di un software oppure chi rappresenta il cliente (customer proxy),
Continuous Integration: il codice viene integrato e controllato diverse volte in un
giorno. Il codice viene sottoposto spesso a refactoring, dopo che è stato integrato.
Engineering Task: le storie vengono smembrate in task durante l’iteration planning.
Le storie descrivono le necessità dei customer, mentre I task descrivono quello che è
necessario fare per realizzari una storia.
Extreme Programming: è un approccio agile allo sviluppo del software che coinvolge
continuamente customer e sviluppatori. Si realizza codice di alta qualità.
First Iteration: la prima interazione, è un evento speciale, inquanto il team non ha il
tempo di predire la velocity. Una stima approssimativa, per effettuare la prima
iterazione, è più che sufficiente.
Iteration: il team raggiunge obbiettivi intermedi(milestones) al termine di ogni
iterazione. Un iterazione dura generalmente dalle due alle tre settimane ed inizia
con un iteration planning meeting. Un customer sceglie un numero di storie per ogni
iterazione in accordo allo Yesterday’s Weather.
Iteration Planning: ogni iterazione inizia con un breve planning meeting dove il
customer seleziona le storie e le descrive al team. Gli sviluppatori suddividono una
storia in più engineering tasks, stimando il tempo di sviluppo di ogni task ed
assegnandosi uno o più task.
On Site Customer: il customer dovrebbe essere disponibile in tutti i momenti per
rispondere a domande riguardanti le storie o gli acceptance tests.
Pair Programming: tutto il codice prodotto, è scritto da due programmatori, che
condividono una tastiera ed un monitor. La coppia suddivide la responsabilità
riguardo la strategia, il testing, scrive il codice e scambia i ruoli se uno dei due si
sente stanco.
Planning Game: un progetto XP inizia con il planning game. Nel planning game, il
customer scrive le storie nelle story card. Il programmatore stima ogni storia ed il
customer ordina le card per priorità. Il customer seleziona le card per la prima
iterazione. Il risultato del planning game è ditto release plan. Il planning game viene
ripetuto ripetuto dopo alcune iterazioni per incorporare nuove informazioni.
Project Velocity: è il numero di story points che vengono completati in ogni
iterazione.
Release Plan: è una collezione di storie priorizzate, raggrupate per iterazione che
risultano dal planning game. Una volta che il team ha raggiunto un certo ritmo, e la
velocity è stabilizzata e conosciuta, allora il customer può venire a conoscenza di
quante user story potranno essere completate entro una certa data.
Refactoring: significa migliorare il codice esistente. Nel contesto del test driven
14
Stelnet.com

15. Manuale Agile - Stelnet
development, il codice viene re fattorizzato per rimuovere duplicazioni.
Simple Design: la filosofia da seguire nell’XP è quella di rendere il più semplice
possibile ciò che si realizza. Il sistema deve evolvere attraverso il refactoring, per
fare in modo da assicurare che il sistema sia il più semplice possibile.
Small Releases: il team cerca di realizzare piccolo release, in maniera da ottenere
subito dei feedback. Il software potrebbe potenzialmente essere rilasciato al termine
di ogni iterazione.
Spike Solution: sono utilizzate per rispondere a perplessità riguardo il design, per
provare nuove tecnologie o per aiutarsi nella stima di una storia.
Stand Up Meeting: ogni giorno inizia con un incontro per comunicare quello che è
stato realizzato il giorno prima e quello che si intende realizzare il giorno corrente.
Ognuno stà in piedi per rendere l’incontro molto breve.
Story: è l’unità di base per potere lavorare in XP. Una storia rappresenta una
porzione di business value che deve essere testate, stimata e rilasciata all’interno di
una iterazione. Ogni storia viene scritta su una story card.
Story Cards: detta anche index card, è un pezzo di carta da compilare con la
descrizione della user story, la priorità, ed il rischio e stima dello sviluppatore.
Story Points: le storie vengono stimate in termini relative. Uno story point può
essere ad esempio una giornata di lavoro di una pair programming.
Sustainable Pace: il team deve lavorare ad un ritmo di lavoro costante, senza
straordinari.
System Metaphor: può essere utile utilizzare un vocabolario semplice e “da
fumetto” per fare il design del sistema.
Test Driven Development: in un progetto XP, quando produciamo una porzione di
codice, ne scriviamo prima il test, poi il codice e testiamo.
Unit Tests: sono test automatici scritti dagli sviluppatori per testare le funzionalità di
una porzione di codice
Whole Team: consiglia di mantenere i customer assieme in una singola stanza per
massimizzare le opportunità di comunicazione.
Yesterday's Weather: il numero di story points che sono stati completati nell’ultima
iterazione vengono usati per la predizione di quanti story points potranno essere
completati nella iterazione successiva.
15
Stelnet.com