Sviluppo Agile. Prof. Filippo Lanubile. Processo software

Transcript

1 Sviluppo Agile 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 1

2 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) 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 Analysis Design Implementation Testing stabilire che tutto procede veramente bene Difficile da applicare se i requisiti sono poco noti o volatili Time to market ritardato 2

3 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 Time boxing: le release sono rilasciate a intervalli di tempo regolari Iterazione 1 Iterazione 2 Iterazione 3 Testing Implementation Implementation Testing Analysis Design Analysis Design 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 3

4 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 Prof. - Filippo Ron Jeffries Lanubile- Jon Kern - Brian Marick - Robert C. Martin - Steve Mellor - Ken Schwaber - Jeff Sutherland - Dave Thomas Un processo tipico di sviluppo agile del sw Selezione Incremento del prodotto Product Backlog Iterazione (Time-boxed) Modifica backlog Raccolta del feedback 4

5 Metodi agili Extreme Programming (XP) Scrum Kanban Extreme Programming (XP) 5

6 Kanban Visualizzazione del flusso di lavoro Limitazione del Work in Progress (WIP) Rilascio continuo Scrum 6

7 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 Scrum framework * Ruoli Product owner ScrumMaster Team Eventi Sprint planning Sprint review Sprint retrospective Daily scrum meeting * Questa parte riadatta materiale tratto da - Mike Cohn, Introduction to Scrum - Ken Schwaber and Jeff Sutherland, The Scrum Guide Artifact Product backlog Sprint backlog Burndown charts 7

8 Scrum framework Ruoli Product owner ScrumMaster Team Eventi Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifact Product backlog Sprint backlog Burndown charts 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

9 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 Team di Sviluppo Soltanto i membri del Team di Sviluppo creano l incremento da rilasciare alla fine di ogni Sprint Dimensione: da 3 a 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 9

10 Scrum framework Ruoli Product owner ScrumMaster Team Eventi Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifact 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 ( ore) Scrivere l interfaccia utente (4) Scrivere le test fixtures (4) Scrivere la classe pippo(6) Aggiornare i performance tests (4) 10

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

12 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 Scrum framework Ruoli Product owner ScrumMaster Team Eventi Sprint planning Sprint review Sprint retrospective Daily scrum meeting Artifact Product backlog Sprint backlog Burndown charts 12

13 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 Esempio di product backlog Backlog item Stima Permettere ad un ospite di effettuare una prenotazione Come ospite, voglio cancellare una prenotazione. 5 Come ospite, voglio cambiare le date di una prenotazione. Come impiegato dell hotel, posso lanciare i report RevPAR (Revenue Per Available Room = Fatturato per camera disponibile) Migliorare la gestione delle eccezioni

14 Requisiti funzionali nello sviluppo agile Descrizione di una user story Template Esempio In qualità di <ruolo utente>, voglio <obiettivo> [in modo tale da <motivo>] In qualità di cliente occasionale, voglio visualizzare le foto dell'albergo selezionato in modo tale da decidere se effettuare la prenotazione 14

15 Sprint goal Una breve indicazione dell obiettivo principale dello Sprint Cambio Database Fare girare l applicazione anche su SQL Server oltre che su Oracle. B Servizi finanziari Supportare più indicatori tecnici di quanto faccia ABC con dati in tempo reale. 15

16 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 Uno sprint backlog Tasks Lun Mar Mer Gio Ven Codificare la UI 4 Codificare il middle tier Testare il middle tier Scrivere l help online 12 Codificare la classe foo Logging degli errori 4 16

17 Scrum board Una Scrum board fisica 17

18 Una Scrum board digitale Uno sprint burndown chart Hours 1

19 Tasks Codificare la UI Codificare il middle tier Testare il middle tier Scrivere l help online Lun Mar Mer Gio Ven Hours Lun Mar Mer Gio Ven Riepilogo 19

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