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 iniziando  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 che nel 2001 crearono il cosiddetto Manifesto Agile), 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.

Si inizia con la fase di analisi dei requisiti, con la quale si chiede ai clienti del software cosa vogliono ottenere dallo stesso. Tra i problemi che sono emersi sul processo a cascata, c’è da annoverare 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 Inventu, essendoci varie 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, riteniamo utile evidenziare 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 fondamentali:

• 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.

Operazioni preliminari per un progetto

Quando un cliente richiede un software a Inventu.it, 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. Le discussioni al telefono o meglio gli incontri, rappresentano delle situazioni ideali in cui apprendere caratteristiche e necessità di un cliente. Qualora il dominio oggetto dell’applicazione richiesta, sia nuovo per Inventu.it, 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 Inventu.it 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 Inventu.it, per ogni progetto dovremo avere la seguente organizzazione del personale in ruoli:

Per identificare le persone a cui affidare i ruoli, attenersi al seguente schema:

Ruolo	Cosa fa	Competenze richieste
Coach	E’ il responsabile dell’intero processo: deve guidare il gruppo se questo devia dal regolare funzionamento	Deve conoscere ogni aspetto delle metodologie Agili ed avere esperienza nella gestione dei team di lavoro
Manager	Si occupa di visionare l’andamento del progetto. Tiene traccia delle riunioni e comunica con il tracker.	Capacità interpersonali avanzate e gestione delle risorse finanziarie.
Tracker	Il tracker è colui che segue il team e controlla la velocity, cioè la velocità con cui gli sviluppatori riescono a programmare.	Deve avere buone competenze in termini di organizzazione dei team di sviluppo e nelle metriche di processo e di prodotto
Developer	il suo valore principale è la comunicazione: non basta che il codice funzioni correttamente, deve anche seguire gli standard di codifica, riorganizzare il codice, scrivere i test, ecc.	Competenze con vari linguaggi di programmazione, progettazione con uml e svariati tools di progettazione e sviluppo.
Customer proxy	Deve imparare a scrivere delle buone storie e scrivere test funzionali. E’ una persona specializzata nel dominio dell’applicazione e può essere anche personale stelnet. Può sostituire il customer.	Conoscenze avanzate sugli argomenti riguardanti il software da sviluppare (conoscenze del dominio).
Customer	E’ il cliente che commissiona il software. Deve imparare a scrivere buone storie deve prende decisioni deve imparare a scrivere test funzionali.	Deve conoscere gli obbiettivi che intendere raggiungere con l’utilizzo del software e le funzionalità che saranno necessarie.
Tester	Deve avere la capacità di aiutare i customer a scrivere i test di accettazione. Grafica i risultati ed avvisa tutto il team sui risultati dei test.	deve essere capace eventualmente di eseguire dei test automatici e di rappresentare attraverso grafici l’andamento dei test di accettazione.

Tabella 1 Schema assegnazione ruoli

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:

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.

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 Inventu.it, 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.

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.

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 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:

1. Riscrivere la storia;
2. 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
..	..	..

Tabella 3 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);
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: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ SOFTW ENGINEER’S NOTES: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Tabella 4 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.

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 deve poter fare la classe	Nomi delle classi che vengono utilizzate

Tabella 5 Una 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:

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.

Sviluppatori: Programmazione a coppie

Gli sviluppatori dovrebbero lavorare a coppie. Ciascun programmatore ha un suo ruolo:

1. Il Driver, che scrive il codice;
2. Il Navigatore guarda sullo schermo quello che scrive il Driver e ne commenta l’operato.

I ruoli tra i due vengono scambiati ogni giorno.

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:

Diagramma da seguire per scrivere codice

Sviluppatori: Best practice per la progettazione

Utilizzare le crc cards. Cosa sono? Sono dei pezzi di carta, di dimensione 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”.

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.

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 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.