Corso di Ingegneria del Software

Corso di Ingegneria del Software Paolo Bottoni Lezione 3: Sviluppo rapido e metodi agili Lucidi tradotti e adattati a partire dalla versione in inglese presente a http://iansommerville.com/software-engineering-book/slides/

Obiettivi Discutere approcci prototipali e di sviluppo rapido Discutere essenza di metodi di sviluppo agili Discutere metodi di gestione di processi agili Spiegare ruolo prototipazione in processo software 2

Sviluppo rapido di software Ambienti in rapido cambiamento, organizzazioni di fronte a nuove opportunità e concorrenza Richiesta nuovo software Sviluppo e consegna rapidi spesso requisito critico Qualità inferiore accettabile se possibile consegna rapida di funzionalità essenziale Ingegneria del Software Lezione3Agile 3

Requisiti Ambiente in cambiamento Impossibile arrivare a insieme di requisiti di sistema stabile e coerente Modello a cascata non praticabile Approccio basato su specifica e consegna iterative solo modo per consegna rapida Ingegneria del Software Lezione3Agile 4

Metodi agili Insoddisfazione con sovraccarico connesso a metodi di progetto Focalizzazione su codice e non su progetto Approccio iterativo a sviluppo software Consegna rapida software funzionante Evoluzione software in base a evoluzione requisiti Meglio adattati a sistemi organizzativi mediopiccoli o a prodotti per PC Ingegneria del Software Lezione3Agile 5

Sviluppo guidato da piano o agile I 6

Sviluppo guidato da piano o agile II Sviluppo guidato da piano Identifica diversi stadi di sviluppo. Identifica in anticipo prodotti dei diversi stadi Non necessariamente modello a cascata. Possibile sviluppo incrementale guidato da piano Iterazione entro specifiche attività Sviluppo agile Specifica, progetto, implementazione e validazione interfogliate. Prodotti processo di sviluppo negoziati durante processo stesso 7

Agile manifesto 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 8

Principi di metodi agili Principio Coinvolgimento cliente Consegna incrementale Persone, non processi Abbracciare il cambiamento Mantenere la semplicità Descrizione Il cliente dovrebbe essere strettamente coinvolto lungo tutto il processo di sviluppo. Il suo ruolo è di fornire e prioritizzare nuovi requisiti di sistema e valuatare le iterazioni del sistema. Il software è sviluppato in incrementi, con il cliente che specifica quali requisiti includere in ogni incremento. Le capacità del gruppo di sviluppo dovrebbero essere riconosciute e sfruttate. Il gruppo dovrebbe essere libero di sviluppare i propri metodi di lavoro senza processi prescrittivi. Attendersi che i requisiti di sistema cambieranno e progettare il sistema così che li possa includere. Focalizzarsi sulla semplicità sia del software da sviluppare sia del processo di sviluppo usato. Dove possibile, lavorare attivamente per eliminare complessità dal sistema. Ingegneria del Software Lezione3Agile 9

Problemi con metodi agili Difficoltà mantenere interesse clienti in processo Coinvolgimento intenso Membri gruppo possono non essere adatti Diversi interessi in gioco Prioritizzazione cambiamenti può essere difficile Mantenimento semplicità richiede lavoro aggiuntivo Contratti possono essere problema Comune ad altri approcci a sviluppo iterativo Più adatti per sviluppo nuovo software Ma gran parte costi software legati a mantenimento Più adatti per piccole squadre localizzate Ingegneria del Software Lezione3Agile 10

Applicabilità metodi agili Sviluppo di prodotti di media-piccola grandezza per vendita Quasi tutte app sviluppate in modo agile Sviluppo di sistemi per cliente quando cliente si impegna a coinvolgimento in processo di sviluppo. Poche regole esterne che possano influenzare software 11

Programmazione estrema (XP) Approccio "estremo" a sviluppo iterativo Nuove versioni costruite più volte per giorno Incrementi consegnati a clienti ogni due settimane Suite completa di test eseguita per ogni costruzione Costruzione accettata solo se supera intera suite Selezionare storie utente per rilascio Decomporre storie in compiti Pianificare rilascio Valutare il sistema Rilasciare il software Sviluppare / integrare / provare software Ingegneria del Software Lezione3Agile 12

Pratiche di programmazione estrema 1 I ncr em en t a l p l ann i ng Sm a ll R e l eas e s Sim pl e De si gn T es t f ir s t deve l op m en t R e fa c to ri ng R e qui r e m en ts a r e r e cord e d on S t o r y C a r ds and t he St or i e s t o be i nc l uded i n a r e l e as e a r e de t er mi ned by t h e tim e a va il ab l e a nd t he ir r e l a ti ve pr i o rit y. The deve l ope r s br e ak t he s e S t o ri es i n t o deve l op m en t " t a s ks ". T he mi n im a l u s e f u l s e t o f f unc ti ona lit y t ha t prov i de s bu si nes s va l ue i s deve l oped f ir s t. R el eas e s of t he s ys t e m a r e fr equen t and i nc r e m en t a ll y a dd f unc ti ona lit y t o t h e fi r st r e l ea s e. E nough de si gn i s ca rri ed ou t to m ee t t he cu rr en t r equ ir e m en t s and no m o r e. An au t o m a t ed un it t es t f r a m ewo r k is u s ed t o w r i te t e s t s f o r a new p i ece o f f unc ti ona lit y be f o r e t ha t fun ct ion a l it y it se lf is im p l e m en t ed. A ll d e ve l ope r s a r e expe c t e d t o re f ac t o r t h e code con ti nuous l y as soon a s po s s i b l e code im p r ove m en t s a r e f ound. T h i s keeps t he code s im p l e and m a i n t a i n a bl e. Ingegneria del Software Lezione3Agile 13

Pratiche di programmazione estrema 2 Pair Programming Collective Ownership Developers work in pairs, checking each other s work and providing the support to always do a good job. The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. Continuous Integration As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Sustainable pace On-site Customer Large amounts of over-time are not considered acceptable as the net effect is often to reduce code quality and medium term productivity A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation. Ingegneria del Software Lezione3Agile 14

Scenari di requisiti XP Requisiti utente espressi come scenari o storie Storie scritte su schede, squadra di sviluppo le suddivide in compiti di implementazione Compiti base per stime schedulazione e costo Cliente sceglie storie da includere in prossimo rilascio in base a priorità e stime schedulazione Ingegneria del Software Lezione3Agile 15

Una storia da MentCare 16

Esempi di schede di compiti 17

XP e cambiamento Principio generale di SE: progettare per mutamento Razionalità spesa per anticipazione cambiamento: riduce costi successivi in ciclo di vita XP prospettiva inversa: Cambiamenti non affidabilmente anticipabili Invece: costante miglioramento codice (refactoring) Rende cambiamenti più facili quando necessari Codice non necessariamente più efficiente Ingegneria del Software Lezione3Agile 18

Test in XP Sviluppo con test come prima cosa Sviluppo incrementale di test da scenari Coinvolgimento utenti in sviluppo e validazione test Infrastrutture automatizzate di test usate per eseguire test di componente su ogni nuova release Ingegneria del Software Lezione3Agile 19

Descrizione di caso di test Ingegneria del Software Lezione3Agile 20

Sviluppo con test come prima cosa Scrivere test prima di codice Chiarifica requisiti da implementare Test scritti come programmi piuttosto che dati Possono essere eseguiti automaticamente Test include controllo di esecuzione corretta Tutti test nuovi e precedenti eseguiti automaticamente su ogni nuova funzionalità Controlla nuova funzionalità non introduca errori Ingegneria del Software Lezione3Agile 21

Problemi per testing Programmatori preferiscono programmare a testare. Prendono scorciatoie, ad esempio non scrivono test per ogni possibile eccezione Alcuni test difficili da scrivere incrementalmente. Per esempio in GUI, test unitari che seguono logica di presentazione e flusso di lavoro fra schermi Difficile valutare completezza di insieme di test, indipendentemente da loro numero Ingegneria del Software Lezione3Agile 22

Programmazione a coppie In XP, programmatori lavorano a coppie, sedendo insieme per sviluppare codice Aiuta a sviluppare proprietà comune codice e diffonde conoscenza in squadra Funziona come processo di revisione informale: ogni linea di codice è vista da più persone Incoraggia refactoring: intero gruppo può beneficiarne Misure indicano produttività simile a quella di due persone che lavorano indipendentemente Ingegneria del Software Lezione3Agile 23

Scrum Metodo agile focalizzato su gestione sviluppo iterativo piuttosto che su pratiche agili specifiche Tre fasi Pianificazione schematica: stabilisce obiettivi generali progetto e definisce architettura software Serie di cicli di sprint, ogni ciclo sviluppa incremento Chiusura, rifinisce progetto, completa documentazione (aiuti, manuali utente), valuta lezioni apprese 24

Scrum terminology (a) Scrum term Development team Potentially shippable product increment Product backlog Product owner Definition A self-organizing group of software developers, which should be no more than 7 people. They are responsible for developing the software and other essential project documents. The software increment that is delivered from a sprint. The idea is that this should be potentially shippable which means that it is in a finished state and no further work, such as testing, is needed to incorporate it into the final product. In practice, this is not always achievable. This is a list of to do items which the Scrum team must tackle. They may be feature definitions for the software, software requirements, user stories or descriptions of supplementary tasks that are needed, such as architecture definition or user documentation. An individual (or possibly a small group) whose job is to identify product features or requirements, prioritize these for development and continuously review the product backlog to ensure that the project continues to meet critical business needs. The Product Owner can be a customer but might also be a product manager in a software company or other stakeholder representative. 25

Scrum terminology (b) Scrum term Scrum Definition A daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day. Ideally, this should be a short face-to-face meeting that includes the whole team. ScrumMaster Sprint Velocity The ScrumMaster is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. He or she is responsible for interfacing with the rest of the company and for ensuring that the Scrum team is not diverted by outside interference. The Scrum developers are adamant that the ScrumMaster should not be thought of as a project manager. Others, however, may not always find it easy to see the difference. A development iteration. Sprints are usually 2-4 weeks long. An estimate of how much product backlog effort that a team can cover in a single sprint. Understanding a team s velocity helps them estimate what can be covered in a sprint and provides a basis for measuring improving performance. 26

Ciclo di sprint Scrum 27

Ciclo di sprint in Scrum I Lunghezza fissata, normalmente 2-4 settimane Punto di partenza è backlog di prodotto Fase di selezione coinvolge intera squadra, si lavora con cliente per selezionare caratteristiche e funzionalità da backlog da sviluppare durante sprint 28

Ciclo di sprint in Scrum II Raggiunto accordo, auto-organizzazione squadra per sviluppo software A questo stadio squadra isolata da cliente e organizzazione, comunicazioni tramite Scrum master Suo ruolo proteggere la squadra da distrazioni esterne Finito sprint, lavoro rivisto e presentato a stakeholder 29

Lavoro di squadra Scrum master facilitatore, organizza incontri giornalieri, mantiene backlog lavoro da svolgere, registra decisioni, misura progresso, comunica con clienti e direzione Scrum, brevi incontri quotidiani, team condivide informazione, descrive progresso da incontro precedente, problemi riscontrati, piano per giorno Ogni membro ha visione complessiva, se ci sono problemi può ripianificare lavoro a breve scadenza 30

Benefici Prodotto decomposto in insieme di pezzi Gestibili e comprensibili Requisiti instabili non frenano progresso Squadra ha visibilità totale, migliora comunicazione Clienti vedono consegna puntuale incrementi, ottengono informazione su funzionamento Si stabilisce fiduce fra clienti e sviluppatori, creazione cultura positiva verso successo progetto 31

Scrum distribuito 32

Aumento di scala per metodi agili Scaling up, uso di metodi agili per sviluppo di grandi sistemi, non adatti a piccola squadra Scaling out, introduzione di metodi agili in grande organizzazione con anni di esperienza Fondamentali da mantenere: Pianificazione flessibile, rilasci frequenti, integrazione continua, sviluppo guidato da test, buona comunicazione 33

Aspetti contrattuali Contratti per sistemi custom in genere basati su specifica di cosa deve essere implementato Questo impedisce alternanza di specifica e sviluppo tipica di sviluppo agile Occorre contratto che paga in base a tempo sviluppatore e non in base a funzionalità Visto come rischio da dipartimenti legali, non è garantito quanto verrà consegnato 34

Manutenzione software Due questioni fondamentali Sistemi sviluppati con approccio agile sono manutenibili, vista che documentazione è minima? Metodi agili possono essere usati efficacemente per far evolvere sistema in risposta a richieste cliente? Problemi se squadra originale dispersa 35

Manutenzione agile Problemi Mancanza documentazione su prodotto Mantenimento impegno clienti Mantenimento continuità squadra sviluppo Squadra conosce e capisce cosa va fatto Problema per sistemi di lunga durata 36

Metodi agili e metodi basati su piano Molti processi includono elementi di entrambi. Equilibrio dipende da: Specifica di dettaglio e progetto prima di implementazione necessari? Strategia di consegna incrementale con valutazione reazioni eventi realistica? Quanto è grande sistema da sviluppare? 37

Fattori di valutazione 38