• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Lezione 2: Pianificazione in Extreme Programming
 

Lezione 2: Pianificazione in Extreme Programming

on

  • 1,704 views

✦ Struttura del processo XP

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

Statistics

Views

Total Views
1,704
Views on SlideShare
1,688
Embed Views
16

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 16

http://bizarro.iobloggo.com 12
http://www.slideshare.net 2
http://webcache.googleusercontent.com 1
http://www.slashdocs.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Lezione 2: Pianificazione in Extreme Programming Lezione 2: Pianificazione in Extreme Programming Presentation Transcript

    • Lezione 16: Pianificazione in Extreme Programming Corso di Ingegneria del Software Laurea Magistrale in Ing. Informatica Università degli Studi di Salerno 1
    • Outline ✦ Struttura del processo XP ✦ User stories e engineering tasks ✦ Stima dei tempi e project velocity ✦ Spike Solution ✦ Pair Programming 2
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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