Post on 25-May-2020
1
Metodi Agili 1
Lezione 4- Sviluppo Agile del Software
Metodi Agili 2
Riferimenti bibliografici
• I. Sommerville – Ingegneria del Software – 8a edizione –Cap. 17
• R. Pressman- Principi di Ingegneria del Software- 4 edizione- Cap. 4
2
Metodi Agili 3
Argomenti
1. Introduzione allo Sviluppo Agile
2. eXtreme Programming (XP)
Metodi Agili 4
Premessa-Molti progetti software falliscono!
CHAOS Report, StandishGroup
• 66% de progetti falliti, o contestati nel 2002
• Progetti grandi falliscono più spesso dei piccoli
• Solo il 52% delle featuresrichieste vengono prodotte
I dati peggiorano anche nel report del 2009!!
3
Metodi Agili 5
Principali cause del fallimento dei progetti (v. Chaos)
• Mancanza di coinvolgimento utente• Requisiti e specifiche vaghe e incomplete e/o mutevoli• Aspettative poco realistiche• Obiettivi poco chiari• Incompetenza tecnologica• Inefficace pianificazione
• Fattori di successo:– Coinvolgimento utente– Supporto alla gestione – Chiari requisiti– Piccoli e frequenti rilasci– Adeguata pianificazione
Metodi Agili 6
Metodi Agili
• L’insoddisfazione per l’eccessivo overhead richiesto daitradizionali approcci allo sviluppo software ha portatonegli anni ’90 alla proposta dei metodi agili.
• Tali metodi: – Si concentrano sul codice, piuttosto che sulla progettazione;– Sono basati su un approccio iterativo allo sviluppo software; – Sono pensati per rilasciare software funzionante
rapidamente, e per farlo evolvere rapidamente per soddisfarenuove esigenze.
• Il movimento dell’Agile Software Development nasce nel febbraio 2001 in Utah
4
Metodi Agili 7
““We are uncovering better ways of developing We are uncovering better ways of developing software by doing it and helping others do it. software by doing it and helping others do it. Through this work we have come to value: Through this work we have come to value:
••Individuals and interactionsIndividuals and interactions over processes over processes and tools and tools ••Working softwareWorking software over comprehensive over comprehensive documentation documentation ••Customer collaborationCustomer collaboration over contract over contract negotiation negotiation ••Responding to changeResponding to change over following a over following a planplan
Kent Beck et alKent Beck et al
Il Manifesto dello Sviluppo Agile
Metodi Agili 8
Cos’è l’ “Agilità”?
• Efficace risposta (rapida e flessibile) ai cambiamenti• Efficace comunicazione fra tutti gli stakeholders• Portare il cliente nel team di lavoro• Organizzare un team in modo da controllare il lavoro
svolto
Consente di avere …• Rapida, incrementale consegna del software
5
Metodi Agili 9
Un Processo Agile
• E’ guidato dalle descrizioni dei clienti di quanto sirichiede al software (scenari)
• Riconosce che I piani hanno vita breve• Sviluppa il software iterativamente dando enfasi alle
attività di costruzione• Rilascia multipli ‘incrementi software’• Si adatta a fronte dei cambiamenti
• Esistono diverse proposte di Metodi Agili
Metodi Agili 10
6
Metodi Agili 11
Alcuni Metodi Agili
• Extreme Programming (Kent Beck 1999)• SCRUM (Sutherland)• Feature Driven Development (De Luca & Coad)• Crystal (Cockburn )• DSDM (Dynamic System Development Method)• Lean Software Development (Poppendieck)
• Ogni metodo propone un diverso processo, ma tutti condividono gli stessi principi
Metodi Agili 12
Principi dei Metodi Agili (1)
• Coinvolgimento del cliente– Il cliente dovrebbe partecipare attivamente allo sviluppo. Il suo
ruolo consiste nel definire i requisiti e assegnarvi le priorità, e nel valutare le iterazioni del sistema.
• Consegna Incrementale– Il software è sviluppato in incrementi, ed il cliente stabilisce i
requisiti da includere in ciascun incremento.
• Persone, non processi– Le capacità del team di sviluppo devono essere riconosciute e
sfruttate. Le persone devono poter liberaremente sviluppare con i propri metodi, senza imposizioni di processi prescrittivi
7
Metodi Agili 13
Principi dei Metodi Agili (2)
• Accettare i cambiamenti– Prevedere i requisiti che cambieranno e progettare il sistema in
modo da accettare i cambiamenti
• Mantenere la semplicità– Semplicità sia nel software che si sviluppa, che nel processo
adottato.
Metodi Agili 14
Agile Modeling
• Adottare un metodo agile non vuol dire evitare di fare modellazione; anche XP accetta la modellazione, purché agile;
• lo scopo dei modelli e della modellazione è supportare la comprensione e la comunicazione;
• non modellare tutto;• usare gli strumenti più semplici possibili;• non modellare da soli;• creare modelli in parallelo;• sapere che tutti i modelli sono incompleti e imprecisi.
8
Metodi Agili 15
Tipico Sviluppo Agile (1/2)
• Le Applicazioni evolvono attraverso multiple brevi iterazioni
• Le Iterazioni hanno durata costante, variabile fra 2-13 settimane
• Si rilascia una applicazione funzionante al termine di ogni iterazione
• Con ogni nuova release si aggiungono quante più caratteristiche è possibile tra quelle con la più alta priorità richieste dal cliente
• Per ogni release vengono elaborati solo i requisiti ed il progetto necessari a supportare le caratteristiche di quella release.
Metodi Agili 16
Tipico Sviluppo Agile (2/2)
• Si testano in maniera intensiva le caratteristiche in ogni iterazione
• Il cliente rivede ogni nuova release— e può ridefinire le priorità per la prossima iterazione.
• Si tiene sotto controllo il progresso del progetto attraverso le caratteristiche completate.
• Non si fallisce mai una data di consegna, piuttosto si rimanda lo sviluppo di qualche feature.
10
Metodi Agili 19
Un tradizionale processo Waterfall
Metodi Agili 20
Potenziali Vantaggi dell’Agile
• Consegne più predicibili• Veloce ritorno dell’investimento; il software viene
consegnato e va in uso più rapidamente• Rapida risposta ai cambiamenti dei bisogni utente• Rischi attenuati grazie a cicli di consegna più brevi
– Più opportunità di scoprire errori– Convalida dei requisiti– Conferme sull’approccio tecnico adottato– Verifica realistica dei progressi del lavoro
• Alta produttività e qualità• Clienti soddisfatti, successo dei progetti
11
Metodi Agili 21
eXtreme Programming (XP)
Metodi Agili 22
eXtreme Programming (di Kent Beck)
• Forse è il metodo agile più noto ed usato.• Obiettivi espliciti:
– Evitare la produzione di semilavorati diversi da quellistrettamente necessari alla realizzazione dell’applicazione.• dettagliate specifiche formali, approfondite analisi e puntigliosa
documentazione sono considerate attività troppo costose rispettoai benefici apportati
– Evitare di fare piani a lungo termine che non potranno essere attesi• lo sviluppo di un’applicazione è un’attività troppo complessa per
poter essere pianificata a priori• Richiede aggiustamenti continui degli obiettivi
12
Metodi Agili 23
eXtreme Programming
• Extreme Programming (XP) adotta un approccioestremo allo sviluppo software. – L’approccio si basa su requisiti espressi come scenari (storie
utente) che sono implementati direttamente;– Nuove versioni possono esser prodotte più volte al giorno;– Gli incrementi sono rilasciati al cliente frequentemente, in genere
ogni 2-4 settimane;– Ogni nuova versione viene completamente testata, e viene
accettata solo se supera tutti I test.
Metodi Agili 24
eXtreme Programming
• Il lavoro di sviluppo si basa su 4 attività fondamentali che si ripetono iterativamente durante il progetto:– Scrittura del codice (Coding)– Verifica delle funzionalità (Testing)– Osservazione dell’ambiente (ossia desideri del
committente, opportunità tecnologiche,sviluppi di mercato) (Listening)
– Progetto dell’applicazione (Design)
13
Metodi Agili 25
Extreme Programming (XP)
unit t est cont inuous integrat ion
acceptance test ing
pair programming
Release
user stories values acceptance test crit eria i t erat ion plan
simple design CRC cards
spike solut ions protot ypes
refactoring
sof tware incrementpro ject ve locity computed
Metodi Agili 27
Pratiche dell’Extreme Programming1. The Planning Process (o Planning Game).
– Lo sviluppo dell’applicazione è accompagnato dalla stesura di un piano di lavoro che viene continuamente aggiornato, a intervallibrevi e regolari dai responsabili del progetto, secondo le prioritàaziendali e le stime dei programmatori
– Planning Game:• Gli utenti finali dell’applicazione presentano gli obiettivi da
raggiungere descrivendo una serie di scenari (storie) che il sistemadeve soddisfare.
• Gli sviluppatori stimano il tempo necessario per la realizzazione diogni storia: qualora ciò non sia possibile, la storia viene suddivisa in storie più semplici. Le storie vengono ordinate da utenti e responsabili secondo la loro priorità di realizzazione e sforzorichiesto
• I responsabili pianificano le attività (come insieme di user stories darealizzare per il prossimo rilascio)
14
Metodi Agili 28
Pratiche dell’Extreme Programming
2. Small Releases.
• La vita e lo sviluppo dell’applicazione sono scanditi dai rilasci di versioni del prodotto funzionanti. Ogni rilascio rappresenta il punto conclusivo di un’iterazione di sviluppo e l’inizio di una nuova pianificazione.
• Per poter tener conto di cambi di prospettiva, errori di valutazione, nuovi requisiti, restrizioni di bilancio, ogni iterazione dovrebbe durare non più di qualche settimana (in genere, da due a quattro).
Metodi Agili 29
Pratiche dell’Extreme Programming
3. Metaphor.– I team di lavoro XP condividono un “sistema dei nomi”, nel quale siano
compresi I concetti fondamentali relativi al software sotto sviluppo (in pratica il dominio dei dati).• System Metaphor: è un documento informale e concisoche descrive la
struttura del sistema e I concetti fondamentali4. Simple Design.
– Un programma costruito con XP dovrebbe essere il programma piùsemplice in grado di soddisfare i requisiti, comprensibile da tutte le persone coinvolte nel progetto.
– Non devono esserci parti superflue o duplicazioni. Le parti checompongono il sistema devono essere,soltanto, quelle strettamentenecessarie alle esigenze correnti.
– Solo quando nuove circostanze lo richiederanno, verranno progettatinuovi componenti, eventualmente riprogettando anche quelli giàesistenti (refactoring).
15
Metodi Agili 30
Pratiche dell’Extreme Programming
5. Testing.– Ogni funzionalità deve essere verificata (sia a livello di sistema
che di singola unità). I test di sistema sono costruiti sulla base delle storie concordate con il committente (che dice l’ultimaparola sulla convalida del sistema). I test di unità devono poteressere rieseguiti automaticamente (dopo ogni modifica), con tempi dell’ordine dei minuti:allo scopo è utile avvalersi distrumenti automatici (v. XUnit). I programmatori devonoscrivere I test prima della scrittura del programma stesso(TDD)
6. Refactoring.– Durante le fasi di integrazione del codice appena prodotto con
il resto del sistema, bisogna operare in maniera da tenere altala qualità della progettazione, evitando ridondanze dei dati e duplicazioni del codice. Fondamentale rimane ancora la comunicazione tra I vari gruppi
Metodi Agili 31
Pratiche dell’Extreme Programming
7. Pair Programming.I programmatori XP lavorano in coppia: due programmatori sulla stessa
macchina. Uno dei programmatori é addetto alla scrittura fisica del codice, mentre l’altro ne controlla la correttezza, salvo scambiarsi I ruolidi tanto in tanto. Esperimenti dimostrano come la produttività siasuperiore rispetto a quella di due programmatori separati.
8. Collective Ownership.Ogni programmatore deve essere in grado di avere un’idea generale del
progetto e di poter toccare qualunque punto del codice, anche di quelloche non ha scritto lui personalmente. Questo obiettivo può essereraggiunto adottando il principio di Simple Design
9. Continuous Integration.Il processo di integrazione del sofware con i nuovi moduli avviene più volte
al giorno. Ciò aiuta I programmatori ad essere sempre aggiornati sullostato del progetto e riduce la maggior parte dei gravi problemi diintegrazione che si verificano quando questa fase non é eseguita cosìspesso.
16
Metodi Agili 32
Pratiche dell’Extreme Programming
10. 40-hour Week.– I programmatori stanchi commettono più errori. Essi non
dovrebbero fare troppo straordinario, in modo da essere freschi, in salute e produttivi
11. On-site Customer.– Il committente deve essere coinvolto nello sviluppo perché è
l’unica fondamentale fonte di convalida del sistema. Partecipa perciò alla stesura dei test di sistema e verifica, periodicamente, che il sistema realizzato corrisponda effettivamente alle proprie esigenze.Inoltre, è la principale fonte di informazione per la conoscenza sul dominio di applicazione.
12. Coding Standard.– I programmatori dovrebbero condividere uno stessostile di
scrittura del codice, in modo da rendere più semplice la comunicazione
Metodi Agili 33
XP e i principi agili
• Lo sviluppo incrementale è realizzato attraverso release piccole e frequenti.
• Il coinvolgimento del cliente nel processo di sviluppo deveessere a tempo pieno.
• Si da’ attenzione alle persone (e non al processo) attraversola programmazione a coppie, il possesso collettivo del codice e con tempi di lavoro non eccessivo.
• Le modifiche sono supportate da release costanti del sistema.
• Il mantenimento della semplicità è raggiunto attraversopratiche continue di refactoring.
17
Metodi Agili 34
Coinvolgimento del cliente
• Il coinvolgimento del cliente è essenziale in XP.• Il ruolo del cliente è molteplice:
– Aiuta a sviluppare storie che corrispondono airequisiti
– Aiuta a definire le caratteristiche da includere in ogni release
– Aiuta a sviluppare I test di accettazione per controllare che il sistema soddisfi I suoi requisiti.
Metodi Agili 35
Scenari dei requisiti
• In XP, I requisiti sono espressi come scenari, le cosiddette storie utente.
• Gli scenari sono scritti su schede (Story Card) e il team di sviluppo le suddivide in task da implementare. Talitask sono la base per la stima dei costi e la schedulazione del lavoro.
• Il cliente sceglie le storie da includere nella prossimarelease sulla base della loro priorità e del costostimato.
18
Metodi Agili 36
Esempio di Story Cardper la generazione di un ordine
Il cliente inserisce il proprio codice cliente e richiede la visualizzazione del catalogo degli articoli disponibili.Il cliente sceglie gli articoli da ordinare, specifica le quantità richieste, e conclude l’ordineIl sistema calcola l’importo totale dell’ordineIl cliente conferma l’ordine e inserisce la modalità di pagamento (carta di credito o conto pre - autorizzato)
Il sistema verifica i dati inseriti, acquisisce l’ordine e visualizza il numero di giorni previsti per la consegnaIl sistema genera una copia dell’ordine in PDF e la invia all’indirizzo del cliente
Metodi Agili 37
Task cards per la creazione dell’ordine
Task 1: Visualizzazione Catalogo
Task 2: Composizione Ordine
Task 3: Verifica dati Pagamento
Il pagamento può essere fatto in due modi: attraverso carta credito, oppure specificando un numero di conto pre-registrato. Nel primo caso, il cliente inserisce un numero di 16 cifre ed una data di scadenza ed il sistema verifica la validità della carta, mentre nel secondo caso il cliente fornisce il numero del conto ed il sistema ne controlla la esistenza.
19
Metodi Agili 38
XP e le modifiche software
• Un principio basilare dell’ingegneria del software è diprogettare pensando al cambiamento . Si dovrebberospendere risorse e tempo per anticipare le possibilemodifiche, riducendo così I costi di manutenzionefutura.
• Invece in XP si rinuncia a gestire in anticipo I cambiamenti, perchè si ritiene che le modifiche non sipossano prevedere con certezza.
• In alternativa, XP propone un continuo miglioramentodel codice (refactoring) per rendere più semplicel’implementazione delle modifiche.
Metodi Agili 39
Refactoring
• Refactoring è un processo di miglioramento del codiceche viene riorganizzato e riscritto per renderlo piùefficiente,comprensibile, etc.
• Il Refactoring è necessario perchè con I rilasci frequentiil codice (sviluppato incrementalmente) tende a deteriorarsi .
• Il Refactoring non dovrebbe cambiare la funzionalità del sistema.
• Il testing automatico semplifica il refactoring perchèconsente di verificare che il codice modificato superiancora i test con successo.
20
Metodi Agili 40
Testing in XP
• Negli approcci rapidi è difficile che il software possaessere testato da un team esterno (manca la necessaria documentazione)!
• XP dedica invece molta attenzione al testing e richiededi progettare I test prima di scrivere il codice.
• Lo sviluppo dei test avviene in modo incrementale a partire dagli scenari.
• Coinvolge l’utente nello sviluppo dei test e nellavalidazione.
• Si automatizza l’esecuzione dei test in modo da testaretutte le unità ogni volta che viene prodotta una nuovarelease.
Metodi Agili 41
Task cards per la creazione dell’ordine
Task 1: Visualizzazione Catalogo
Task 2: Composizione Ordine
Task 3: Verifica dati Pagamento
Il pagamento può essere fatto in due modi: attraverso carta credito, oppure specificando un numero di conto pre-registrato. Nel primo caso, il cliente inserisce un numero di 16 cifre ed una data di scadenza ed il sistema verifica la validità della carta, mentre nel secondo caso il cliente fornisce il numero del conto ed il sistema ne controlla la esistenza.
21
Metodi Agili 42
Descrizione dei Test case
Test 3: Test per il controllo validità della carta di credito
Input: una stringa di 16 cifre e due interi (per mese e anno di scadenza)
Test: • Controllare che tutti i caratteri della stringa siano cifre • Controllare che il mese sia compreso fra 1 e 12 e l’anno sia maggiore o uguale di quello corrente
• Controllare la validità della carta facendone richiesta algestore della carta
Output: OK, oppure un messaggio di errore per carta non valida
Metodi Agili 43
Sviluppo preceduto dai Test (TDD)
• Scrivere I test prima del codice chiarisce I requisiti daimplementare.
• I test sono scritti come programmi, per essere eseguitiautomaticamente. Ogni test simula l’invio degli input e controlla l’output.
• Sia i test preesistenti che i nuovi test vengono eseguitiquando una nuova funzionalità viene aggiunta. Ciòpermette di verificare che la nuova funzionalità non abbia introdotto errori.
22
Metodi Agili 44
Pair programming- Programmazione a coppie
• In XP, I programmatori lavorano in coppie, condividendo la postazione di lavoro, e le coppievariano continuamente .
• Aiuta a sviluppare il senso di proprietà del codice e a diffondere la conoscenza nell’ambito del team.
• Permette un processo di revisione informale, perchèogni linea di codice è controllata da più di 1 persona.
• Il refactoring viene incoraggiato, perchè è più facile chel’intero team ne benefici.
• Le misure eseguite mostrano che il pair programming richiede uno sforzo simile a quello di 2 persone chelavorano indipendentemente .
Metodi Agili 45
Confronto dei Tempi di sviluppo, Correttezza e Compattezza Programma Senza e con Pair Programming
Da CockburnA, Williams L: The costsand benefits of pair programming. In ExtremeProgramming Examined. Addison Wesley, 2001.
23
Metodi Agili 46
Problemi dell’XP
• Coinvolgimento del cliente– É forse il problema maggiore. Può essere difficile
trovare un cliente rappresentativo di tutti glistakeholder e che possa lasciare il normale lavoroper far parte del team di XP.
– Per sviluppare prodotti generici, non esiste unospecifico cliente, rappresentativo degli utenti finali.
Metodi Agili 47
Problemi dell’XP
• Progetto architetturale– Lo stile incrementale di sviluppo comporta che possano farsi
scelte architetturali inadeguate nelle prime fasi del processo.– I problemi conseguenti potrebbero diventare evidenti solo
dopo l’implementazione di molte funzionalità, quandoeseguire il refactoring dell’architettura può essere costoso.
• Compiacimento per i Test– Può sembrare scontato al team pensare che essendoci molti
test il sistema sia stato testato adeguatamente (invece..).– A causa del testing automatico, c’è la tendenza a sviluppare
test facili da automatizzare, piuttosto che test realmente validi(ma difficili da automatizzare).