Manuale Agile - Stelnet




    Manuale Agile Stelnet




                          Autori: Alberto Buschettu




        ...
Manuale Agile - Stelnet




Indice
Indice....................................................................................
Manuale Agile - Stelnet


1. Manuale aziendale Agile Stelnet
  In tale capitolo, verrà illustrato il manuale agile che tut...
Manuale Agile - Stelnet

   tipologie di metodologie agili, abbiamo scelto l’XP programming istituzionalizzandone
   la pr...
Manuale Agile - Stelnet




                          Figura 2 Ruoli nell'XP programming a Stelnet



Per identificare le ...
Manuale Agile - Stelnet

                               commissiona il              obbiettivi che intendere
             ...
Manuale Agile - Stelnet

Tabella 1 Story Card
DATE:___________            TYPE OF ACTIVITY: NEW:____ FIX:____ ENHANCE:____...
Manuale Agile - Stelnet

Su RISK, lo sviluppatore inserirà un valore di priorità da 1 a 3 seguendo la scala
illustrata poc...
Manuale Agile - Stelnet

la data, il tipo di attività, il numero della storia, la priorità, la descrizione ed
eventuali no...
Manuale Agile - Stelnet

       3. Per ogni user story, gli sviluppatori, individuano una serie di compiti, o “task”
     ...
Manuale Agile - Stelnet


SOFTW ENGINEER'S NOTES:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _...
Manuale Agile - Stelnet

   1. Si scrive l’unit test;
   2. Si scrive una porzione di codice;
   3. Si fa partire l’unit t...
Manuale Agile - Stelnet




                       Tabella 5 Diagramma da seguire per scrivere codice




1.8. Sviluppator...
Manuale Agile - Stelnet

Collective Code Ownership: tutto il codice è di proprietà di tutti gli sviluppatori.
Chiunque può...
Manuale Agile - Stelnet

development, il codice viene re fattorizzato per rimuovere duplicazioni.
Simple Design: la filoso...
Upcoming SlideShare
Loading in …5
×

Manuale Agile Stelnet

843 views
763 views

Published on

Manuale per applicare le metodologie agili in ambiti aziendali

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
843
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Manuale Agile Stelnet

  1. 1. Manuale Agile - Stelnet Manuale Agile Stelnet Autori: Alberto Buschettu 1 Stelnet.com
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×