Sviluppo Agile I processi (di sviluppo) del software

Sviluppo Agile
Prof. Filippo Lanubile
I processi (di sviluppo)
del software
bisogni
nuovi o modificati
Processo software
Prodotto software
nuovo o modificato
• Un processo software descrive quali sono le attività
che concorrono a sviluppare un prodotto software e
come le attività sono collegate tra loro
• Assunzione: la qualità del processo implica la
qualità del prodotto
Prof. Filippo Lanubile
1
Attività tipiche nello sviluppo
ed evoluzione del software
• Attività tecniche
– Analisi dei requisiti
(requirements analysis)
– Progettazione
(design)
– Realizzazione
(implementation)
– Collaudo
(testing)
– Messa in esercizio
(deployment)
– Conduzione operativa
(operation)
– Manutenzione
(maintenance)
• Attività organizzative
– Gestione del progetto
(project management)
– Gestione della
configurazione
(configuration
management)
– Assicurazione della
qualità
(quality assurance)
Prof. Filippo Lanubile
Stile di processo a
cascata (waterfall)
•
Suddivide il progetto in base alle attività tecniche
– Le fasi coincidono con le attività
•
Si passa a una fase successiva solo se si completa l’attività e si
supera il punto di controllo
– Tornare indietro è possibile ma come eccezione
Problemi
• Rischio elevato: difficile
stabilire che tutto procede
Analysis
veramente bene
• Difficile da applicare se i
Design
requisiti sono poco noti o
volatili
Implemen•
Time to market ritardato
tation
Testing
Prof. Filippo Lanubile
2
Stile di processo iterativo
•
•
Anche conosciuto come
incrementale, a spirale,
evolutivo
Suddivide il progetto in base a
sottoinsiemi di funzionalità
(iterazioni)
– L’inizio delle iterazioni è
preceduto da una fase
esplorativa
– Ogni iterazione produce
codice (build) testato e
integrato nel sistema
complessivo
– Le iterazioni messe in
produzione sono dette
release
Implementation
Analysis
Testing
Design
Implementation
Analysis
Testing
Design
Iterazione 1
Iterazione 2
• Time boxing: le release
sono rilasciate a intervalli
di tempo regolari
Iterazione 3
Prof. Filippo Lanubile
Non esiste un modo unico per
strutturare lo sviluppo del software
• Sviluppo hoc (build and fix)
– Conoscenza tacita
– Documentazione inesistente o quasi
– Approccio non ripetibile e trasferibile solo con apprendistato
• Sviluppo pianificato (plan-driven)
–
–
–
–
Piano dettagliato delle attività creato a monte
Molta documentazione come forma di comunicazione indiretta
Stile di processo a cascata
Adatto per progetti con requisiti noti a priori e stabili nel tempo
• Sviluppo agile
– Fortemente adattivo rispetto ai cambiamenti in corso d’opera
– Poca documentazione: enfasi sulla comunicazione diretta tra
persone
– Stile di processo iterativo: iterazioni corte e di durata costante
(time-boxed)
– Esempio: Scrum
Prof. Filippo Lanubile
3
http://agilemanifesto.org
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck - Mike Beedle - Arie van Bennekum - Alistair Cockburn - Ward Cunningham - Martin Fowler James Grenning - Jim Highsmith - Andrew Hunt
Ron Jeffries
Prof.- Filippo
Lanubile- Jon Kern - Brian Marick - Robert C. Martin
- Steve Mellor - Ken Schwaber - Jeff Sutherland - Dave Thomas
Un processo tipico di sviluppo
agile del sw
Incremento del prodotto
Selezione
Product Backlog
Iterazione
(Time-boxed)
Modifica backlog
Raccolta del feedback
Prof. Filippo Lanubile
4
Metodi agili
•
•
•
•
Extreme Programming (XP)
Scrum
Kanban
Prof. Filippo Lanubile
Extreme Programming (XP)
http://www.xprogramming.com/xpmag/whatisxp.htm
Prof. Filippo Lanubile
5
Kanban
• Visualizzazione del flusso di lavoro
• Limitazione del Work in Progress (WIP)
• Rilascio continuo
Prof. Filippo Lanubile
Scrum
Prof. Filippo Lanubile
6
Sprint
• I progetti Scrum fanno progressi in una serie di
iterazioni dette sprint
– Il prodotto è progettato, realizzato e testato durante
lo sprint
• La durata tipica è in genere di 2–4 settimane o
un mese di calendario
– Una durata costante permette una migliore cadenza
• Durante uno Sprint non sono accettate richieste
di modifiche ai requisiti
Prof. Filippo Lanubile
Scrum framework *
Ruoli
• Product owner
• ScrumMaster
• Team
Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifact
* Questa parte riadatta materiale tratto da
- Mike Cohn, Introduction to Scrum
- Ken Schwaber and Jeff Sutherland,
The Scrum Guide
• Product backlog
• Sprint backlog
• Burndown charts
Prof. Filippo Lanubile
7
Scrum framework
Ruoli
• Product owner
• ScrumMaster
• Team
Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifact
• Product backlog
• Sprint backlog
• Burndown charts
Prof. Filippo Lanubile
Product Owner
• È responsabile del valore del prodotto
• Ha la responsabilità esclusiva di gestione del
Product Backlog
– Definisce le caratteristiche funzionali e non funzionali
(feature) del prodotto
– Assegna le priorità alle feature in base al valore di
mercato
– Adatta le feature e le priorità a ogni iterazione
• Accetta o rifiuta i risultati del lavoro del Team di
Sviluppo
– In base a una definizione di “Done” (lavoro completo)
compresa da tutto il Team di Sviluppo
Prof. Filippo Lanubile
8
Scrum Master
• È una guida al servizio del Team di Sviluppo e
del Product Owner
– Aiuta a creare gli elementi del Product Backlog in
modo chiaro e conciso
– Aiuta a ordinare gli elementi del Product Backlog per
massimizzare il valore
– Facilita gli eventi Scrum
– Rende trasparente il processo di sviluppo mediante
visualizzazione delle informazioni chiave
Prof. Filippo Lanubile
Team di Sviluppo
• Soltanto i membri del Team di Sviluppo creano
l’incremento da rilasciare alla fine di ogni Sprint
• Dimensione: da 3 a 8
– regola delle 2 pizze (americane)
• Autogestione all’interno di uno Sprint
• I singoli membri possono avere competenze
specialistiche e aree di interesse
ma è il Team di Sviluppo nel suo complesso ad
avere la responsabilità finale
Prof. Filippo Lanubile
9
Scrum framework
Ruoli
• Product owner
• ScrumMaster
• Team
Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifact
Prof. Filippo Lanubile
• Product backlog
• Sprint backlog
• Burndown charts
Sprint planning
•
•
•
•
Valutazione delle priorità nel Product Backlog
Scelta dello Sprint Goal
Selezione degli item da completare nello Sprint
Creazione dello Sprint Backlog
– Identificazione dei Task e stima (1-16 ore)
– Anche il design di alto livello è considerato
Come pianificatore
di vacanze, voglio
vedere le foto
degli alberghi.
Scrivere lo strato business (8 ore)
Scrivere l’interfaccia utente (4)
Scrivere le test fixtures (4)
Scrivere la classe pippo(6)
Aggiornare i performance tests (4)
Prof. Filippo Lanubile
10
Daily scrum meeting
• Parametri
– Tutti i giorni
– 15-minuti
– In piedi
• Tre domande:
– Cosa hai fatto ieri?
– Cosa farai oggi?
– Ci sono problemi?
• Sono tutti invitati ma solo i membri del team, lo
Scrum Master e il Product owner hanno diritto di
parola
Prof. Filippo Lanubile
Sprint review
• Il team presenta i risultati
raggiunti durante lo Sprint
• Demo delle nuove funzionalità
o dell’architettura sottostante
• Informale
– Regola: 2 ore di preparazione
– Niente slide
• Riunione aperta
– Tutto il team partecipa
– Esterni benvenuti
Prof. Filippo Lanubile
11
Sprint retrospective
• Periodicamente si analizza cosa sta
funzionando e cosa no
• Si discute
– cosa introdurre
– cosa evitare
– cosa continuare
nel prossimo sprint
• Tipicamente da 15 a 30 minuti
• Fatta al termine di ogni sprint
• Partecipa tutto il team
– Possibilmente anche i clienti ed altri ruoli coinvolti
Prof. Filippo Lanubile
Scrum framework
Ruoli
• Product owner
• ScrumMaster
• Team
Eventi
• Sprint planning
• Sprint review
• Sprint retrospective
• Daily scrum meeting
Artifact
• Product backlog
• Sprint backlog
• Burndown charts
Prof. Filippo Lanubile
12
Product Backlog
• Una lista di tutto il lavoro richiesto sul progetto
– L’unica fonte di requisiti per le modifiche da
apportare al prodotto
• È dinamico e cambia continuamente
– Nella prima stesura contiene solo i requisiti
inizialmente conosciuti e meglio compresi
• Le priorità sono stabilite dal Product Owner e
aggiornate all’inizio di ogni sprint
• Le stime degli item pronti per uno Sprint sono
stabilite dal Team di Sviluppo
Prof. Filippo Lanubile
Esempio di product
backlog
Backlog item
Permettere ad un ospite di effettuare una
prenotazione
Come ospite, voglio cancellare una prenotazione.
Come ospite, voglio cambiare le date di una
prenotazione.
Stima
3
5
3
Come impiegato dell’hotel, posso lanciare i report
RevPAR (Revenue Per Available Room =
Fatturato per camera disponibile)
8
Migliorare la gestione delle eccezioni
...
Prof. Filippo Lanubile
...
8
30
50
13
Requisiti funzionali nello
sviluppo agile
Prof. Filippo Lanubile
Descrizione di una
user story
Template
Esempio
In qualità di <ruolo utente>,
In qualità di cliente
occasionale,
voglio visualizzare le foto
dell'albergo selezionato
in modo tale da decidere se
effettuare la prenotazione
voglio <obiettivo>
[in modo tale da <motivo>]
Prof. Filippo Lanubile
14
Prof. Filippo Lanubile
Sprint goal
• Una breve indicazione dell’obiettivo principale
dello Sprint
Cambio Database
B
Fare girare l’applicazione
anche su SQL Server oltre
che su Oracle.
Servizi finanziari
Supportare più indicatori
tecnici di quanto faccia ABC
con dati in tempo reale.
Prof. Filippo Lanubile
15
Sprint backlog
• L'insieme degli elementi del Product Backlog
selezionati per lo Sprint
più un piano per fornire l'Incremento del prodotto
e realizzare lo Sprint Goal
• La gestione è di esclusiva pertinenza del Team di
Sviluppo
– Il lavoro non è assegnato da un project manager
– Quando del nuovo lavoro risulta necessario, il Team di
Sviluppo lo aggiunge allo Sprint Backlog
– Se alcuni elementi del piano non sono più ritenuti utili,
sono rimossi
– La stima del lavoro rimanente è aggiornata nel daily
meeting
Prof. Filippo Lanubile
Uno sprint backlog
Tasks
Lun Mar Mer Gio Ven
8
4
8
16
12
10
4
Testare il middle tier
8
16
16
11
8
Scrivere l’help online
12
8
8
8
8
8
4
Codificare la UI
Codificare il middle tier
Codificare la classe foo
8
Logging degli errori
Prof. Filippo Lanubile
16
Scrum board
Prof. Filippo Lanubile
Una Scrum board fisica
Prof. Filippo Lanubile
17
Una Scrum board digitale
Prof. Filippo Lanubile
Hours
Uno sprint burndown
chart
Prof. Filippo Lanubile
18
Tasks
Lun Mar Mer Gio Ven
Codificare la UI
8
4
8
16
12
10
7
Testare il middle tier
8
16
16
11
Scrivere l’help online
12
Codificare il middle tier
8
50
Hours
40
30
20
10
0
Lun
Mar
Mer
Gio
Ven
Prof. Filippo Lanubile
Riepilogo
Prof. Filippo Lanubile
19
Adattare un processo a
un progetto
• I progetti software differiscono al variare di molti fattori
– tipo di sistema software, natura dei rischi, tecnologie usate,
numero e competenze dei partecipanti, distribuzione
geografica del gruppo, ,
• Non ci sono processi che siano adatti per tutti i progetti
– Scelto un processo base è necessario modificarlo per farlo
funzionare al meglio
• Valutazione retrospettiva (di progetto o di iterazione)
– Cose da tenere
• ciò che ha funzionato bene e che si intende ripetere in futuro
– Problemi
• aree in cui qualcosa non va come dovrebbe
– Cose da provare
• cambiamenti che potrebbero migliorare il processo
Prof. Filippo Lanubile
20