Il metodo extreme Programming in sintesi

Transcript

1 extreme Programming Approach Il metodo extreme Programming in sintesi Piergiuliano Bossi Coach Marina Morgagni Engagement Manager Quinary SpA

2 Copyright Quinary SpA Tutti i diritti sono riservati. Questo documento non può essere copiato o riprodotto in alcuna forma, ivi inclusi supporti magnetici o altri media elettronici, e le informazioni in esso contenute non possono essere utilizzate, distribuite o rese pubbliche, né interamente né in parte, senza il preventivo consenso scritto di Quinary SpA.

3 Cos è il metodo 1 XP I metodi Agili, di cui XP fa parte, sono classificati come metodi lightweight, questo termine nasce in contrapposizione a heavyweight, con cui si denotano i metodi predittivi o anticipazionisti. Per questa ragione e per potere descrivere il contesto in cui i metodi agili si sviluppano, una breve digressione sui metodi predittivi. I metodi predittivi o anticipazionisti (heavyweight) cercano di prevedere tutti i possibili requirement di progetto, allo scopo di pianificare e stimare l impegno dei team di sviluppo. Lo sforzo predittivo comporta un approccio fortemente document-oriented e si svolge in fasi da eseguire in sequenza rigida. È un approccio allo sviluppo del software metodico e strutturato, che prevede che ogni aspetto del progetto sia discusso, pianificato, documentato accuratamente prima che lo sviluppo vero e proprio inizi. L approccio waterfall è probabilmente il più conosciuto tra i metodi predittivi, chiamato in questo modo perché ogni passo è correlato al precedente, o meglio l output di una fase costituisce l input di quella successiva (all'inizio di ciascuna fase si verifica la qualità del lavoro effettuato nella fase precedente, con possibilità di ricicli per migliorare i contenuti). Il processo di sviluppo di un progetto waterfall è facilmente intuibile, perché segue il modello della catena di montaggio, tipico della produzione industriale. Il suo iter è: passo1: requirements elicitation passo2: software design passo3: coding passo4: testing passo5: deployment. Perché un progetto waterfall abbia una ragionevole percentuale di successo occorre che i requisiti siano congelati dopo il passo 1. Per questa ragione si può dire che l approccio waterfall prevede una scarsa tolleranza per i cambiamenti in corso d opera. Questo, si sa, può essere applicabile a progetti di breve durata, ma è molto difficile da realizzare per progetti di complessità media o elevata. Inoltre i metodi heavyweight, nella fase iniziale del progetto, impongono al team un grosso onere: è molto difficile documentare in maniera adeguata ciò che il cliente vuole finchè non si ha una buona conoscenza del problema di business da risolvere. L esperienza mostra che una percentuale di progetti, condotti seguendo i metodi predittivi, fallisce perché ciò che il team produce non si conforma ai desideri del cliente, ossia, i sistemi realizzati non corrispondono ai requisiti espliciti, ma più spesso impliciti del cliente. Purtroppo, seguendo un metodo preditivo, le prime verifiche concrete, in termini di risultati visibili e compresibili da committenti e utenti, arrivano solo verso la fine del progetto, nel passo finale di testing: per questa ragione non è possibile adottare in tempo le eventuali possibili operazioni correttive. Questi metodi risultano poco adatti anche per i progetti che utilizzano nuove tecnologie, poiché assumono il corretto funzionamento di ogni componente prima di avere una qualunque forma di riscontro. In questo modo qualsiasi malfunzionamento, durante la fase di test, è potenzialmente causa di ritardi considerevoli, oltre che di un aumento dei costi complessivi. 1 L insieme di regole e pratiche che vengono applicate nella fase di progettazione e stesura del codice definisce un metodo di sviluppo software. 1

4 I metodi agili (lightweight) sono tipicamente di natura iterativa. Un progetto è costituito da più iterazioni, dove ogni iterazione comporta l'effettuazione di una serie di attività: requirements elicitation software design coding testing deployment. Come appare evidente, durante ogni iterazione si svolgono le stesse tipologie di attività di un metodo heavyweight, ma, a differenza di un metodo heavyweight, non si segue una sequenza rigida. Ogni iterazione ha lo scopo di chiarire le incertezze dei requisiti e semplificare la complessità del sistema, grazie a cui si ottiene una riduzione dei rischi di progetto. Ad ogni iterazione si codificano nuove porzioni del sistema, in modo progressivo, integrandole via via con le precedenti, si verificano con il committente e con le altre parti interessate. Una differenza significativa rispetto a un metodo incrementale è che il processo iterativo prevede il cambiamento di requisiti in corso d'opera. In particolare, prevede lo scaturire di nuovi requisiti espressi dagli utenti, come effetto dell'utilizzo del sistema stesso. Aspetto fondamentale e peculiare dei metodi agili è infatti la capacità di gestire i cambiamenti in ogni momento (metodi adattivi o evolutivi). La criticità per il successo di un progetto iterativo è la collaborazione sistematica tra committenti (utenti) e il team di progetto. Se non esiste una fattiva collaborazione tra committenti e team di sviluppo, la progressiva riduzione dei rischi non ha luogo. Il metodo extreme Programming (in seguito definito XP) è il metodo agile più noto, diffuso e consolidato. Progettato per team di piccole dimensioni, chiamati a sviluppare progetti velocemente, in un ambiente in cui i requisiti mutano costantemente, il metodo XP si basa su alcuni valori fondamentali: Semplicità: questo concetto si riassume nella massima viaggiare leggeri. Il codice (inclusi i test) deve realizzare le funzionalità adottando la soluzione più semplice (nel senso di privo di artifici), senza porsi il problema di anticipare i futuri cambiamenti. Per garantire un architettura e un design semplice, il codice è sottoposto a continue revisioni e miglioramenti (refactoring). La semplicità garantisce che il costo del cambiamento si mantenga costantemente basso e che sia facilmente calcolabile. Comunicazione: team di sviluppo e committente interagiscono e si confrontano continuamente, condividendo, nell ipotesi ottimale, il medesimo spazio lavorativo. Rapid feedback: la congruenza di tutto il sistema e l aderenza alle richieste del cliente sono testate ad ogni integrazione; ogni volta che una componente viene realizzata, è subito verificata con il cliente. Lavorando così, ogni malfunzionamento e/o cattiva interpretazione delle richieste del cliente emerge subito e può essere corretta. Coraggio: il team, verificando in ogni momento il proprio operato, non teme il cambiamento, implementa le modifiche per migliorare la qualità del proprio codice e/o rispondere meglio alle esigenze espresse dal cliente. Le Pratiche XP, riconosciute come best practices da diversi anni, traducono questo insieme di valori nel quotidiano dello sviluppatore. Il termine extreme deriva dall aver adottato estremamente, ossia al massimo grado, le pratiche di sviluppo riconosciute ottimali e nell averle combinate in un insieme coerente, il cui valore è superiore a quello della somma delle parti. 2

5 1. Planning game Il metodo XP assume che, all inizio di un progetto, sia difficile avere una visione completa delle esigenze e dei requisiti e che sia il cliente che il team imparino nel corso del progetto a riconoscere ciò di cui necessitano veramente. D altra parte qualsiasi progetto software necessita di una pianificazione. Esistono due livelli di pianificazione: Release Plan e Iteration Plan. Il Release Plan consiste nel definire un piano di massima sugli obiettivi da raggiungere, le modalità con cui organizzarsi, e le tempistiche, suddividendo il progetto in una serie di rilasci incrementali. Mano a mano che il progetto prosegue ogni release è a sua volta divisa in iterazioni dettagliate nel corrispondente Iteration Plan, il quale consiste in una accurata definizione dei requisiti e delle esigenze che devono essere realizzate, associando a ciascuna di esse le priorità del cliente. Le pianificazioni sono condivise da team e cliente attraverso il cosiddetto Planning Game. Determinante, nella collaborazione tra cliente e team, è che il primo prenda tutte le decisioni a livello di business ed il secondo le decisioni a livello tecnico. Più in particolare, il cliente decide: cosa deve fare il sistema; quali funzionalità sono più importanti, quali servono subito, a quali si può rinunciare; le user story 2 che compongono ogni release e le user story incluse in ciascuna iterazione; quando la release deve essere disponibile. Il team decide: quanto tempo richiede lo sviluppo di una user story; l ordine di sviluppo di una funzionalità all interno di una iterazione; l organizzazione del team stesso. Naturalmente queste decisioni non possono essere avulse dalla realtà, cliente e team devono concordare il planning game, eventualmente mediare tra tempi e/o requisiti individuati e la reale fattibilità delle funzionalità alla data stabilita. In questo senso il planning game è uno strumento potentissimo, l arte del possibile che si fa reale con soddisfazione di tutte le parti coinvolte. le decisioni di design, coinvolgendo almeno due sviluppatori, producono risultati migliori; il rischio connesso a ciascuna user story (una decisione tecnica sui tool da utilizzare o sull hardware spesso implica delle conseguenze); 2. Pair programming 3 Il metodo XP prevede la programmazione a coppie. Il driver ha il controllo di mouse e tastiera mentre il partner osserva e aiuta. Contrariamente all impressione di inefficienza che questo approccio potrebbe destare, la combinazione di due software engineer e la rotazione delle coppie apporta molti benefici complessivi: il codice presenta meno bachi 4, infatti mentre il driver è occupato a scrivere codice e test, a integrare ed a eseguire refactoring, il partner si focalizza sugli obiettivi, coglie eventuali errori di ortografia e sintassi. Il driver è immerso nel piccolo cosmo su cui lavora, il partner può astrarsi, vedere il sistema nell insieme; almeno due persone, in ogni momento, hanno conoscenza dell intero sistema; 2 Le user story descrivono, a livello macroscopico, le funzionalità dell applicazione da realizzare, e ciascuna di esse è completata con l informazione relativa all importanza / priorità e ai test funzionali, necessari per verificarne l idoneità rispetto ai desideri del cliente. 3 Alistair Cockburn, Laurie Williams, The Costs and Benefits of Pair Programming < 4 Marin Fowler, VeryLowDefectProject < 3

6 garantisce che si segua il rigore e la disciplina del metodo, cioè è meno probabile che entrambi i componenti della coppia evitino di eseguire test o non aderiscano agli standard nello scrivere il codice; la rotazione delle coppie di programmazione favorisce il passaggio di conoscenza all interno del team e diminuisce il rischio che una componente sia conosciuta da una sola persona. 3. Testing XP pone il testing come fondamento dello sviluppo. Il software engineer scrive i test (unit test per verificare l assenza di bachi e test funzionali per le user story) parallelamente al codice. I test vengono integrati ed eseguiti continuamente sull intero sistema. Questa pratica assicura che la piattaforma risulti altamente stabile e che sia più facile individuare eventuali conflitti dovuti alle successive integrazioni. L attività di specifica dei test funzionali utili a validare una user story è di competenza del cliente, opportunamente coadiuvato dal team. 4. Refactoring E la pratica che viene applicata continuamente e che consente di migliorare e semplificare il codice senza modificarne le funzionalità e garantendone contemporaneamente la correttezza (l esecuzione dei test ne è la prova). È il processo di design evolutivo che si focalizza su ogni iterazione, senza anticipare nuove funzionalità. Questa pratica garantisce al sistema realizzato durante l iterazione una architettura rigorosa, capace di adeguarsi a nuovi sviluppi. 5. Simple design Adottare un design semplice rende possibile l evoluzione del sistema. Il design più semplice è quello che: passa tutti i test, non contiene codice duplicato, esprime con chiarezza gli obiettivi del software engineer, contiene il numero minimo indispensabile di classi e metodi. 6. Collective code ownership Ogni componente del team è non solo autorizzato ad apportare miglioramenti a qualunque parte del codice ma è responsabile personalmente dell intero sistema. 7. Continuous integration Il team XP integra il codice diverse volte al giorno, ed è sempre un codice di qualità, ovvero privo di errori. Ad ogni integrazione si eseguono tutti gli unit e functional test; il fallimento di uno o più test permette che vengano immediatamente riconosciute e risolte le cause di errore di ogni specifica integrazione. 8. On-site customer Come è già stato ampiamente espresso, pagando lo scotto di sembrare pedanti, si ribadisce che la collaborazione tra team e cliente è fondamentale per il successo del progetto. Il cliente deve approfondire e chiarire le user story e prendere le decisioni a livello di business, perciò la condizione ottimale di lavoro sarebbe che il cliente condividesse gli stessi spazi con il team. Qualora questa condizione non si possa realizzare, possono essere attuati tutti i meccanismi atti a superare tale mancanza ( , videoconferenza, telefono,...), naturalmente a condizione che il cliente si renda disponibile tempestivamente ed efficacemente per rispondere alle possibili domande, fornire direttive sugli aspetti di business, ecc. 9. Small releases Le release dovrebbero essere il più snelle possibile, pur realizzando un sufficiente valore di business. È importante rilasciare il sistema ogni qualvolta si ritiene importante a livello di business e per fornire un feedback concreto al team. 10. Coding standard Avere uno standard per scrivere il codice accelera i tempi complessivi, aiuta il refactoring, consente la rotazione delle coppie di software engineer e, in generale, supporta le altre pratiche XP. 11. System metaphor- Vi è un analogia tra la metafora di sistema del metodo XP e quella che viene correntemente definita architettura. Grazie ad essa il team ha 4

7 un idea complessiva delle varie componenti del sistema, di come interagiscono, e di come e dove intervenire per aggiungere nuove componenti. XP non è totale garanzia di successo ( il progetto C3 della Crysler, a cui Kent Beck partecipò, e da cui trasse spunto per teorizzare il metodo XP, venne interrotto), però risulta essere un processo molto efficiente, in grado di fronteggiare il cambiamento dei requisiti; consegna a breve termine le funzionalità dell iterazione in corso, dotando il committente degli strumenti decisionali, necessari per misurare la bontà del progetto; fornisce un risultato migliore rispetto ad altri metodi, in termini di qualità del prodotto finale, per le pratiche sistematiche e quotidiane di testing e continuous integration; favorisce la coesione e l assunzione di responsabilità del team. Come contropartita XP richiede che: si modifichino ruoli che sono già consolidati, una trasformazione radicale nel rapporto cliente fornitore e nell assetto organizzativo; si abbia la volontà di affrontare le novità; le persone siano capaci di lavorare in gruppo; si utilizzino tool evoluti per programmare, testare ed eseguire refactoring. Questo sintetico elenco di pro e contro, anche se incompleto, vuole provocare chi deve risolvere un problema a chiedersi se, adottando XP, potrebbe ottenere risultati migliori, ed ad incitare chi è sul procinto di affrontare lo sviluppo di un nuovo sistema ad abbracciare il cambiamento. Riferimenti - Manifesto of Agile Methods; < - Kent Beck, Extreme Programming Explained: Embrace Change (Addison Wesley); - W. Farrell e M.R. Fisher, extreme programming: deceptively simple innovation; < - extreme Programming entry point at Cunningham's Wiki; < - Cio Magazine, The secret to software success, July 1, 2001 Issue; < - The Standish Group International, Extreme Chaos; < - Martin Fowler, The New Methodology; < - James Bullock, The Top 10 Ways Software Projects are Different; < - Bryan Morgan, Wireless Week Bringing A Method To The Madness < 5

8 Quinary SpA via Pietrasanta Milano Italia t f v. L. Robecchi Brichetti Roma Italia t f