Università degli Studi dell Insubria

Transcript

1 Università degli Studi dell Insubria FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI Corso di Laurea in Informatica Studio e applicazione di metodi agili nello sviluppo di prodotti Software Open Source Tesi di Laurea di: Relatore: Prof. Luigi Lavazza MARCO BINDA Prof. Sandro Morasca Matricola: Correlatore: Davide Taibi Anno Accademico

2 Riassunto Nello studio dell ingegneria del software si possono dividere i processi di sviluppo in due categorie: processi di sviluppo classici e processi di sviluppo agili. Quando si prende in considerazione un processo di sviluppo classico ci si riferisce a modelli come quello a cascata o a spirale, in cui la modalità di lavoro è fortemente orientata all esecuzione di passi sequenziali dove si pianifica, si progetta e si sviluppa l intero sistema software, con a volte la presunzione di implementare oltre alle funzionalità richieste quelle future. Questo modo di operare, ben si orienta allo sviluppo di progetti Closed Source Software (CSS). I processi di sviluppo Agili, come ad esempio Extreme Programming (XP) o SCRUM, si contrappongono a quelli classici. Questi modelli sono composti da una serie di fasi iterative, dove viene presa in considerazione una parte di progetto alla volta, piccola e ben definita. I processi di sviluppo Agili propongono un modo di lavorare fortemente orientato al risultato che ben si adatta allo sviluppo di progetto Open Source Software. In questo lavoro di tesi si è applicato un processo di sviluppo Agile, in particolare una versione modificata di SCRUM, ad uno strumento OSS contenuto all interno del progetto Qualipso, in dettaglio allo strumento MACXIM. Gli obiettivi che ci siamo proposti all inizio di questo lavoro sono quelli di valutare se sia possibile inserire il processo di sviluppo SCRUM in un progetto OSS già in fase di sviluppo, se sia possibile far cooperare un team di programmatori geograficamente distribuiti e se SCRUM ha contribuito effettivamente a migliorare la qualità del prodotto e la produttività del processo. SCRUM è stato studiato, modificato e adattato per poter essere applicato allo sviluppo di MACXIM. Sono state raccolte una serie di misure quantitative e qualitative prima e dopo l introduzione di SCRUM nel processo di sviluppo, che hanno permesso una valutazione oggettiva ed empirica dell applicazione di SCRUM a progetti OSS. ii

3 Sommario 1 INTRODUZIONE OBIETTIVI DELLA TESI STRUTTURA DELLA TESI I PROCESSI DI SVILUPPO PROCESSI DI SVILUPO CLASSICI IL PROCESSO DI SVILUPPO A CASCATA IL PROCESSO DI SVILUPPO ITERATIVO: A SPIRALE IL PROCESSO DI SVILUPPO UNIFIED PROCESS I PROCESSI DI SVILUPPO AGILI EXTREME PROGRAMMING SCRUM FEATURE DRIVEN DEVELOPMENT DYNAMIC SYSTEM DEVELOPMENT METHOD APPLICAZIONE DI SCRUM A PROGETTI OSS LIGHT SCRUM CASO DI STUDIO MACXIM PROCESSO DI SVILUPPO APPLICAZIONE DI LIGHT SCRUM A MACXIM RISULTATI CONCLUSIONI E SVILUPPI FUTURI BIBLIOGRAFIA Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILE Appendice B - PRATICHE iii

4 1 INTRODUZIONE Nel corso degli anni 90 si sono concretizzate ed hanno avuto modo di evolvere una serie di metodologie per lo sviluppo software denominato Agile. Queste discipline si focalizzano sul conseguimento di un obiettivo alla volta, breve e ben definito, realizzando con un processo iterativo l intero sistema. Talvolta queste metodologie possono essere impiegate per sviluppare prodotti software Open Source (OSS)[13]. Normalmente lo sviluppo di prodotti OSS avviene con criteri molto elastici, in cui gli sviluppatori sono distribuiti geograficamente, decidono il proprio lavoro e come distribuirlo alla comunità. Questa tipologia di sviluppo è in aperto contrasto con le metodologie Closed Source Software (CSS), dove vi sono dei paradigmi molto rigidi, come ad esempio quelli implementati nel modello Waterfall [14], in cui i programmatori devono seguire schemi di sviluppo rigorosi e ben impostati. Questo lavoro di tesi prende in esame due considerazioni principali: 1. Il processo di sviluppo dei prodotti OSS è molto simile al processo di sviluppo adottato nelle metodologie Agili 2. I prodotti CSS sviluppati con processi classici non hanno avuto modo in questi anni di abbracciare le metodologie Agili emergenti, mantenendo paradigmi di sviluppo rigidi. 1

5 Presa visione di queste due considerazioni, ho sviluppato il mio lavoro di tesi applicando una metodologia Agile ad uno strumento OSS nel progetto Qualipso [18], effettuando delle misurazioni prima e dopo l impiego di tale processo di sviluppo, per valutare se sia possibile ottimizzare la produttività del team di sviluppo ed aumentare la qualità dei prodotti OSS, attraverso un ambito più inquadrato rispetto a quello completamente non strutturato che caratterizza i progetti OSS. Dopo aver preso visione delle diverse metodologie Agili, valutando pregi e difetti di ciascuna, abbiamo applicato il processo di sviluppo SCRUM [1] per lo sviluppo di MACXIM (Model And Code Xml-based Integrated Meter), uno strumento OSS che estrae misure quantitative e oggettive da codice sorgente Java. Terminata questa esperienza abbiamo confrontato i dati raccolti prima e dopo l introduzione di SCRUM e ne abbiamo ricavato delle osservazioni su come applicare SCRUM ai prodotti OSS. Dai risultati ottenuti è emerso che SCRUM non ha alterato significativamente la produttività del nostro team di sviluppo e la qualità del nostro prodotto. Tuttavia è stato possibile controllare meglio il processo di sviluppo rispetto al periodo di non sviluppo con la metodologia SCRUM. 2

6 1.1 OBIETTIVI DELLA TESI In questo progetto di tesi si è applicata una metodologia si sviluppo Agile allo strumento MACXIM. MACXIM è sviluppato nel contesto delle attività del progetto Qualipso [18] che è dedicato alla valutazione della qualità di progetti OSS, insieme a una serie di altri strumenti. Considerando che il nostro interesse è rivolto alla qualità dei prodotti OSS, è stato quindi naturale includere MACXIM nella serie di prodotti OSS da valutare. Come conseguenza la qualità di ciascuna emissione di MACXIM è stata accuratamente misurata. Gli obiettivi che ci siamo prefissati prima di procedere all applicazione del processo di sviluppo SCRUM allo strumento OSS MACXIM sono convogliati nello rispondere ai seguenti quesiti: 1. È possibile passare con successo da SCRUM a un processo OSS in fase di sviluppo? 2. È possibile applicare SCRUM a una serie di sviluppatori geograficamente distribuiti? 3. Può SCRUM contribuire a migliorare la qualità del prodotto e la produttività del processo? Per poter rispondere alle tre domande precedenti, abbiamo individuato una serie di misure e confrontato i dati ottenuti prima e dopo l introduzione di SCRUM nel processo di sviluppo dello strumento MACXIM. I dati raccolti dopo essere stati analizzati e confrontati hanno permesso una valutazione quantitativa e qualitativa dell applicazione si SCRUM a dei progetti OSS. 3

7 1.2 STRUTTURA DELLA TESI In questo capitolo è stata presentata un introduzione al lavoro di tesi svolto. Nel secondo capitolo vengono presentate i principali processi di sviluppo classici, andando ad evidenziare le principali caratteristiche legate ad ogni modello analizzato. Nel terzo capitolo vengono presentati i principali modelli di sviluppo Agili, presi in considerazione per poter portare a termine con successo gli obiettivi prefissati. Nel quarto capitolo viene spiegato come il processo di sviluppo SCRUM è stato scelto e adattato allo sviluppo dello strumento MACXIM. Nel quinto capitolo viene descritto lo strumento MACXIM, il processo di sviluppo adottato, come è stato applicato LIGHT SCRUM allo strumento MACXIM ed i risultati ottenuti a fine lavoro. 4

8 2 I PROCESSI DI SVILUPPO Nell ingegneria del software esistono vari processi di sviluppo. Possiamo suddividere i processi di sviluppo in due categorie: i processi classici ed i processi agili. 2.1 PROCESSI DI SVILUPO CLASSICI Nel corso degli anni sono stati sviluppati diversi processi di sviluppo del software. In questo capitolo ne verranno presentati alcuni tra i più noti. A cascata. A spirale. Unified Process IL PROCESSO DI SVILUPPO A CASCATA Il processo di sviluppo a cascata (waterfall) è stato il primo processo di sviluppo studiato nell ingegneria del software (Fig. 1). Il processo di sviluppo a cascata è strutturato secondo una serie di fasi. Le fasi di questo processo di sviluppo sono lo studio di fattibilità, descrizione del problema, progettazione della soluzione, sviluppo e test di unità, integrazione e test del sistema, deployment e manutenzione. Vengono svolte in forma sequenziale: ogni fase per poter iniziare, deve attendere la conclusione di quella precedente. 5

9 Fig. 1 Modello a cascata Vi sono dei problemi evidenti in questo processo di sviluppo: pur avendo una struttura semplice che permette di semplificare il lavoro degli sviluppatori, accade spesso che in una di queste fasi ci si rende conto che sarebbe necessario tornare a quella precedente. Ad esempio, come spesso accade in fase di sviluppo, emergono alcuni aspetti del sistema non noti in una prima fase di analisi, che rendono quindi necessario tornare alla fase precedente per poter chiarire questi nuovi aspetti. Un ulteriore problema del processo di sviluppo a cascata è di non sposarsi bene con progetti dove i requisiti utente cambiano con una frequenza alta. 6

10 Questo processo di sviluppo è più adatto allo sviluppo di grossi progetti software, come ad esempio i primi sistemi operativi IL PROCESSO DI SVILUPPO ITERATIVO: A SPIRALE Nel corso degli anni sono stati ideati altri processi di sviluppo con l intenzione di affrontare e risolvere gli aspetti problematici di quello a cascata. È nato cosi il processo di sviluppo iterativo, ancora oggi ampiamente usato. Il processo di sviluppo iterativo è composto da una serie di iterazioni al termine delle quali è sempre prodotto un particolare deliverable. Le iterazioni sono mini-progetti formati da una ripetizione di fasi: le attività e i deliverable prodotti cambiano in funzione dello stato di avanzamento del progetto. Il più famoso processo di sviluppo iterativo è quello a spirale (Fig. 2). Fig. 2 Modello a spirale 7

11 Il processo di sviluppo a spirale conserva gli aspetti sistematici di quello a cascata, ma cerca di ridurre la possibilità di errori. Per far questo, il processo di sviluppo a spirale prevede la realizzazione del prodotto software attraverso più rilasci incrementali. Le attività che portano alla creazione di un rilascio, sono ciclicamente ripetute per ogni versione successiva, secondo una spirale. Il processo di sviluppo a spirale è caratterizzato da una struttura composta da task region. Ogni task region è costituita da un insieme di attività. Uno dei vantaggi principali di questo modello è l introduzione dell analisi del rischio a ogni livello di iterazione. La presenza dell analisi del rischio influenza in modo significativo le decisioni prese nel progetto IL PROCESSO DI SVILUPPO UNIFIED PROCESS Uno dei modelli iterativi più significativi è lo Unified Process (UP) e il suo esempio più famoso, il Rational Unified Process (RUP). UP è un modello che definisce una struttura generica di processo: tale struttura è poi specializzata per un ampia classe di sistemi software. UP è iterativo e incrementale: è scomposto in progetti di dimensione e complessità minori da svolgere in singole iterazioni. Al termine di ogni iterazione è necessario un momento di verifica e, se l esito è positivo, il progetto passa all iterazione successiva. Inoltre viene mantenuto un feedback di quanto fatto nel 8

12 corso dell iterazione, in modo da assecondare eventuali cambiamenti occorsi durante il progetto. Il modello UP è strutturato secondo due diverse dimensioni: 1. una dimensione temporale suddivisa in fasi che determina la vita e la maturità del progetto (è la sequenza di iterazioni citate in precedenza); 2. una dimensione di workflow del processo, articolata in attività ripetute in ogni iterazione di ciascuna fase (definisce la struttura di ogni singola iterazione). Le fasi del modello UP vengono illustrate in Fig. 3 e sono inception, elaboration, construction e transition. Mentre le attività individuate a ogni iterazione sono requirements, analysis, design, implementation, test. Fig. 3 Fasi del modello Unified Process A volte queste fasi assumono un peso ritenuto fin troppo rilevante. Per questo motivo negli ultimi anni 9

13 sono stati definiti nuovi processi di sviluppo, identificati con l espressione Agile Software Development. 10

14 3 I PROCESSI DI SVILUPPO AGILI L Agile Software Development è un approccio che punta l attenzione verso la capacità di rispondere in modo veloce ed efficace ai cambiamenti che caratterizzano il processo di sviluppo del software. Nel 2001 è stato pubblicato un manifesto dell Agile Software Development che ne descrive i principi fondanti e i valori. Il termine agile fa riferimento, in generale, alla capacità di reazione al cambiamento, come ad esempio la capacità di adattare la soluzione software in base ai cambiamenti dei requisiti richiesti dall utente, e alla flessibilità del lavoro del team durante l intero progetto. In Appendice A - I PRINCIPI FONDANTI DEL MANIFESTO AGILEvengono riportati i dodici principi che stanno dietro la stesura del manifesto mentre in [2] i firmatari del documento. Nel manifesto sono indicati quattro aspetti che differenziano il processo di sviluppo agile rispetto ai modelli esistenti: Lo sviluppo agile si focalizza sulle persone e sull interazione piuttosto che sul processo e i tool. L enfasi è sulla realizzazione del software piuttosto che sulla redazione di una documentazione esaustiva. L aspetto essenziale è la collaborazione con l utente e non la negoziazione del contratto. 11

15 È essenziale rispondere al cambiamento piuttosto che seguire in modo rigido un piano di progetto preordinato. Sulla base di questi principi e dei dodici punti del Manifesto Agile, sono nate un insieme di metodologie agili, all interno delle quali è possibile applicare una o più pratiche in base all esigenza del committente del progetto. Con il termine pratica si indica un modo di operare associato alla metodologia. Le singole pratiche applicabili alle metodologie agili sono decine e nella loro scelta si deve tener conto delle caratteristiche di ogni pratica, per i benefici che apporta e le conseguenze che comporta. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie come riportato in Appendice B - PRATICHE. Qui di seguito verranno descritte le metodologie agili più significative: Extreme Programming. SCRUM. Feature Driven Development. DSDM. Lean Software Development. Tutte le metodologie agili condividono una serie di caratteristiche comuni e fondamentali come adattabilità, iteratività, rilasci frequenti, testing, orientamento alle persone e applicabilità a progetti dove i requisiti utente cambiano in continuazione. Operativamente, quindi, le metodologie agili 12

16 ridimensionano l importanza e lo sforzo impiegato nelle attività preliminari del progetto, come ad esempio la raccolta dei requisiti, la progettazione della soluzione e in particolare dell architettura di base. Ciò non significa che queste attività non siano eseguite, ma che il tempo e lo sforzo dedicati sono minori rispetto ai processi di sviluppo software classici. 13

17 3.1.1 EXTREME PROGRAMMING Nel 1999 fu pubblicato Extreme Programming Explained nel quale l autore Kent Beck presenta un nuovo modo di sviluppare software, che permette di limitare i rischi di fallimento strettamente legati alla fase di progettazione. L Extreme Programming (XP) è una metodologia agile, come tale cerca di rispondere agli obiettivi fissati dal manifesto agile. In particolare mira alla realizzazione di un processo di sviluppo leggero e flessibile, adatto a rispondere in tempi brevi e con costi ridotti, alle mutevoli richieste del committente anche in fase avanzata del progetto. XP propone l utilizzo di dodici pratiche agili, e suggerisce di utilizzarle al massimo delle loro potenzialità, da qui il termine Extreme. Tra le pratiche consigliate troviamo progettare con il cliente, test funzionali e unitari, refactoring (riscrivere il codice senza alterarne le funzionalità esterne), progettare al minimo, descrivere il sistema con una metafora, proprietà del codice collettiva (contribuisce alla stesura chiunque sia coinvolto nel progetto), scegliere ed utilizzare un preciso standard di scrittura del codice, integrare continuamente i cambiamenti al codice, il cliente deve essere presente e disponibile a verificare (sono consigliate riunioni settimanali), open workspace, quaranta ore di lavoro settimanali, pair programming (due programmatori lavorano insieme su un solo computer). Inoltre XP è caratterizzato da quattro valori chiave: semplicità, feedback, comunicazione e coraggio. Questo approccio si focalizza su una progettazione della 14

18 soluzione il più semplice, inclusiva delle sole funzionalità che di volta in volta il team deve rilasciare al committente. L ideazione e la pianificazione della soluzione avvengono tramite user story. Una user story è la descrizione, semplice e breve, di una particolare funzionalità richiesta dal committente: il team di sviluppo analizza tutte le user story e decide in che ordine implementarle. Il feedback è ottenuto dal testing continuo eseguito sul codice: spesso i casi di test sono pensati prima dell implementazione del codice che viene quindi realizzato per rispondere al test definito. Il team, ricevendo i frequenti feedback del committente, può adattare i rilasci successivi in modo flessibile. XP riscuote molto successo nel mondo dello sviluppo e dell ingegneria del software, ma ha anche i suoi detrattori. Essi evidenziano alcuni fattori critici del metodo, sostenendo che XP funzioni solo con programmatori di alto profilo (programmatori senior), capaci di progettare applicazioni scalabili da subito o in grado di applicare un buon refactoring. Inoltre sostengono che il pair programming dimezzi il numero di task eseguibili in parallelo e individuano nel test driven development del lavoro aggiunto, in quanto costringe a scrive e mantenere altro codice. L estremismo di questo metodo non sempre è apprezzato, ma gli va riconosciuto il merito di evidenziare pratiche agili di successo, tra queste può valere la pena sperimentare in ambiente produttivo quelle che più si avvicinano alla filosofia aziendale. 15

19 3.1.2 SCRUM SCRUM è stato creato da Ken Schwaber, Jeff Sutherland e Mike Beedle. La parola SCRUM non è un acronimo, viene utilizzato cosi come si presenta dalle aziende per indicare l attuazione del processo stesso. Deriva probabilmente dai primi documenti pubblicati da Ken Schwaber che portavano nel titolo la parola in maiuscolo SCRUM. È un termine che deriva dal Rugby ed indica il pacchetto di mischia, dove ogni componente del team di sviluppo deve spingere nella stessa direzione, agendo come un entità coordinata. Di seguito in Fig. 4 viene mostrato il ciclo di vita del processo SCRUM relativo allo svolgimento di un Sprint Backlog. Fig. 4 Ciclo di vita del processo SCRUM Prima di descrivere il processo stesso, analizziamo le parti che lo compongono. SCRUM è composto da tre ruoli, tre cerimonie e tre artefatti. 16

20 I tre ruoli sono ricoperti da Product Owner, colui che commissiona, finanzia il progetto ed ha la responsabilità di definire le caratteristiche del prodotto e di decidere la data di rilascio ed il contenuto. Lo ScrumMaster deve garantire che il team di lavoro sia funzionale e produttivo, una stretta cooperazione in tutti i ruoli e le funzioni e che il processo sia eseguito in ogni sua cerimonia, inoltre deve schermare il team da interferenze esterne. L ultimo ruolo ma non meno importante è il team di sviluppo. Esso si occupa di selezionare e portare a termine l obiettivo di ogni Sprint, inoltre si organizza il proprio lavoro, mostrando i risultati ottenuti per mezzo di demo al Product Owner. La prima delle tre cerimonie è lo sprint planning meeting, un incontro della durata di circa quattro ore, in cui il Product Owner e il team di lavoro negoziano su quali caratteristiche devono essere implementate durante l iterazione (Sprint), basando questa decisione su quali caratteristiche con la massima priorità e un alto valore commerciale è possibile portare a termine in quel periodo. La seconda cerimonia è il daily scrum meeting, un incontro mattutino della durata di quindici minuti, in cui ogni componente del team di lavoro rende noto cosa ha fatto nella giornata precedente, cosa farà durante quella giornata e che problemi ha incontrato. La terza cerimonia è data dallo sprint review meeting, un incontro di quattro ore, in cui il team di lavoro presenta al Product Owner ciò che è stato implementato durante lo Sprint, inoltre viene deciso cosa implementare nello Sprint successivo, ristabilendo le priorità di ciascuna caratteristica. 17

21 I tre artefatti utilizzati in questo processo sono: il product backlog, che consiste in una lista di caratteristiche che definisco il prodotto finale. Lo sprint backlog, è la lista di caratteristiche che il team di lavoro deve implementare durante lo Sprint. La burndown chart, contiene il lavoro che non è stato svolto dal team durante lo Sprint. In una fase di pre-processo si effettua uno sprint planning meeting, tra il Product Owner e il team di lavoro, in cui viene definito il product backlog e lo sprint backlog. Dopo questa fase avviene il primo sprint della durata di quattro settimane, in cui quotidianamente avviene il daily scrum meeting, presidiato dallo ScrumMaster. Al termine di questo periodo si effettua lo sprint review meeting, in cui ciò che non è stato completato viene aggiunto alla burndown chart, mentre la parte di lavoro portata a termine viene presentata tramite una demo al Product Owner. 18

22 3.1.3 FEATURE DRIVEN DEVELOPMENT La feature driven development (FDD) è stata ideata da Jeff De Luca e Peter Coad. Questa metodologia agile basa la propria forma di sviluppo sulle funzionalità richieste dal programma. Per poter applicare FDD è necessario dividere il progetto in cinque fasi chiamate processi. Qui di seguito in Fig. 5 viene mostrato il ciclo di vita del processo FDD con le rispettive fasi Fig. 5 Ciclo di vita del processo FDD La prima fase riguarda lo sviluppo di un modello complessivo. Questa fase viene svolta da un team di modellatori, persone altamente qualificate della materia da trattare. Hanno il compito di sviluppare un modello complessivo del dominio del problema. Questo modello viene aggiornato iterativamente, sulla base dei risultati ottenuti dal quarto processo. La seconda fase consiste nella costruzione di una lista di funzionalità, dove il modello complessivo è suddiviso in aree più grandi. Ogni area ottenuta viene 19

23 a sua volta divisa in singole attività (funzionalità o features), organizzate successivamente in una lista con una struttura gerarchica. La terza fase è una pianificazione del processo di sviluppo sulla base delle funzionalità ottenute precedentemente, in cui vengono considerate le attività da svolgere e le relative priorità. Questo processo coinvolge il capo del progetto, il responsabile dello sviluppo e i capi programmatori. Nella quarta fase vengono elaborate le funzionalità. Lo svolgimento di questa parte è supervisionata dai capi programmatori, i quali identificano e coordinano i singoli programmatori per fargli sviluppare una singola funzionalità. Nella quinta fase vengono testate le funzionalità sviluppate al passo precedente utilizzando dei test di unità e successivamente revisionate dai capi programmatori. Una volta terminate queste due operazioni, il codice viene inserito nel repository del codice di progetto per poter essere condiviso da tutti gli sviluppatori e quindi pronto per il rilascio. 20

24 3.1.4 DYNAMIC SYSTEM DEVELOPMENT METHOD Il Dynamic System Development Method (DSDM) è stato sviluppato in Gran Bretagna ed ora divenuto uno standard europeo. L evoluzione del processo agile DSDM è gestito da un consorzio, che ne permette la distribuzione gratuita. Sviluppare un progetto con il processo DSDM, consiste nel dividere tale sviluppo in tre fasi: pre-project, ciclo di vita e post-project. Di seguito viene rappresentata in Fig. 6 la fase ciclo di vita. Fig. 6 Ciclo di vita del processo DSDM Il processo DSDM si compone di tre fasi sequenziali, dove nella fase di pre-project deve essere concretizzato il finanziamento al progetto e successivamente vengono individuati i candidati per portarlo a termine. Nella fase ciclo di vita, composta da cinque tappe, il progetto è realmente sviluppato. 21

25 La prima e la seconda tappa sono chiamate Studio, si dividono rispettivamente in uno studio di fattibilità, che consiste nel valutare se il processo DSDM è idoneo per poter realizzare il progetto analizzato e in uno studio businnes dove viene definito un elenco di requisiti con le rispettive priorità. La terza tappa chiamata modello funzionale d iterazione, consiste nello sviluppare un modello funzionale contenente le funzionalità ricavate dal elenco dei requisiti, accordarsi sugli orari d incontro, sviluppare un prototipo funzionale sulla base del modello e controllarne la correttezza. La quarta tappa denominata progettazione e costruzione d iterazione, è applicata per produrre una prima release funzionate da consegnare agli utenti finali per essere utilizzata come test. Nella tappa finale chiamata attuazione, vengono raccolti i feedback degli utenti, utilizzati come test, per proseguire con un successivo raffinamento del prodotto. Nella terza fase di post-progetto, viene effettuata una manutenzione del prodotto, effettuando una nuova iterazione della seconda fase. 22

26 4 APPLICAZIONE DI SCRUM A PROGETTI OSS In genere lo sviluppo di prodotti Software Open Source (OSS), non segue il tradizionale sviluppo software proveniente dai paradigmi descritti nei libri di testo dell ingegneria del software. In contrapposizione allo sviluppo OSS, vi sono i paradigmi di sviluppo classici, pensati e progettati per sviluppare Closed Source Software (CSS). L OSS ha ereditato caratteristiche che hanno reso questi paradigmi difficilmente conciliabili. Per esempio, OSS è spesso sviluppato da una comunità distribuita di sviluppatori ed è liberamente distribuito, come codice sorgente aperto e disponibile sia per gli sviluppatori che per gli utilizzatori finali, sotto specifiche licenze. Come stiamo descrivendo in questo lavoro di tesi, l analisi di alcune caratteristiche intrinseche dell OSS [13] da un lato confermano che i paradigmi rigidi di sviluppo, come ad esempio il modello Waterfall [14], non sono applicabili all OSS, mentre, da un altro lato sembra suggerire che i paradigmi Agili [15] possano aiutare gli sviluppatori OSS a migliorare la qualità dei loro prodotti. Questo è il risultato del fatto che i principi generali dietro il Manifesto Agile [1] sono riflessi nel modo in cui la maggior parte dei progetti OSS sono sviluppati e rilasciati agli utenti finali. Ciò che caratterizza molti progetti OSS è di non avere una visione commerciale a breve termine, questo implica che le attività di analisi del sistema e di progettazione, di solito non sono pre-programmate nello sviluppo OSS. Inoltre molti progetti OSS sono stati 23

27 avviati per risolvere il particolare problema di un utente, ma a volte finiscono innovando profondamente il campo del software (questo è il caso di Linux, Perl e Word Wide Web) anche se non hanno avuto una visione a lungo termine almeno alla loro nascita. La necessità di una profonda evoluzione della maggior parte dei progetti OSS è generalmente percepita dopo che sono stati utilizzati con successo da una vasta comunità di utenti. Il successo di un prodotto OSS è di solito imprevedibile. Esso è direttamente connesso al grado di attrattività e di utilità che il prodotto ha nella comunità degli utenti nel corso del tempo. È quindi molto difficile pianificare in anticipo le nuove versioni di un sistema, fatta eccezione per il breve termine. Queste osservazioni rispecchiano i primi due principi del Manifesto Agile: 1. Soddisfare il cliente attraverso la consegna rapida e continua di software di valore. 2. Consegnare frequentemente il software prodotto. Inoltre OSS è caratterizzato da un ambiente di lavoro non strutturato, dove la maggior parte degli sviluppatori OSS sono volontari, che, non si impegnano a rispettare tempi di consegna e ad avere assegnati dei compiti specifici. Nei progetti CSS, ai membri del team sono assegnati compiti specifici, mentre nei progetti OSS sono i membri del team che scelgono i propri compiti. A causa di queste libertà le attività che sono viste come fattori nocivi, quali la definizione del piano di progetto, la progettazione del sistema di valutazione e 24

28 l analisi dei requisiti, non possono essere eseguite seguendo paradigmi tradizionali nella comunità degli sviluppatori OSS. In molti contesti di sviluppo utilizzando processi Agili, i requisiti che non sono stati definiti in anticipo dagli analisti qualificati sono continuamente discussi dagli sviluppatori. I rischi vengono monitorati e gestiti nel corso del ciclo di vita del progetto, in modo naturale, come parte del normale sviluppo di lavoro. Queste caratteristiche dell OSS riflettono il principio Agile: Le architetture migliori, i requisiti e i disegni, emergono da gruppi auto-organizzati. L OSS è sviluppato in modo organizzativo e distribuito [8]. I sistemi OSS sono sviluppati in un ampio contesto di scala cooperativa, dove diverse squadre di utenti privati, nuclei di sviluppatori appassionati e comunità virtuali, creano la società non strutturata (ad esempio Rymond lo ha soprannominato il Bazaar ) contribuiscono allo sviluppo del progetto. Internet e il desktop, sono il ponteggio per queste organizzazioni virtuali di sviluppo del software, dove gli sviluppatori sono coordinati dalle politiche di licenza semplice, senza meccanismi di controllo gerarchico, altrettanto rigorosi nello sviluppo CSS. Di conseguenza gli sviluppatori OSS non seguono quasi mai metodologie di sviluppo, come ad esempio quelle definite e seguite dagli sviluppatori CSS. Inoltre lo sviluppo di progetti OSS è caratterizzato da una crescita più rapida [16] e più creativa rispetto allo sviluppo di progetti CSS [17], con l obbiettivo di soddisfare e rispondere più rapidamente alle esigenze degli utilizzatori. 25