Extreme programming

Extreme programming (XP) è un processo di sviluppo del software di recente formulazione e in continua evoluzione, incentrato sulla fase di codifica e portato alla ribalta da Kent Beck. Per progetti in cui i cicli di consegna sono molto compressi e con fattori di rischio tecnologico molto elevati piuttosto che seguire un processo di sviluppo “canonico” si segue un processo più “leggero”, “intuitivo” e quindi molto operativo. Si può affermare che XP è “code-centric”: tutte le fasi del ciclo di vita del software vengono compresse a favore dell’attività di codifica. L’XP si basa su dodici pratiche fondamentali (più altre introdotte successivamente) nessuna delle quali è un’invenzione del metodo. XP infatti propone pratiche già usate e consolidate e consiglia di applicarle tutte al massimo delle loro potenzialità: da qui il termine “estrema”. Le principali pratiche indicate da XP sono pair programming, test driver developement, refactoring, Continuous integration, standard e proprietà collettiva.

Il ciclo di vita prevede un’iniziale fase di “esplorazione” (Exploration Phase) dove si iniziano a raccogliere le user story, una versione “leggera” (e informale) degli Use Case previste dai modelli tradizionale di sviluppo software. Successivamente segue la fase di pianificazione (Planning Phase) dove il cliente scrive le “storie” su delle schede assegnando la relativa priorità e definisce i relativi test di accettazione. Le user story devono essere capite dal programmatore che deve stimarle e classificarle in base alla difficoltà (rischio) di realizzazione. Questo evidenzia come XP si spinga nella direzione della responsabilizzazione dei programmatori e della loro capacità di fare tesoro dell’esperienza delle passate iterazioni ed esperienza. Una volta prodotte le user story il cliente sceglie le storie da implementare compatibilmente con tempo e stime per la specifica iterazione. Il metodo suggerito dall’XP per passare dalle storie (descrizione funzionale) alla struttura ad oggetti del sistema è l’analisi con le schede CRC (Classe, Responsabilità, Collaborazione: una tecnica di OOA introdotta da Beck e Cunningham nel 1989). Le schede CRC hanno lo scopo di individuare in modo informale le caratteristiche fondamentali delle classi candidate esplicitandone il nome, la gerarchia e la relativa responsabilità [CRC]. Per user story particolarmente complesse o potenzialmente rischiose è consigliato lo sviluppo di un Architectural Spike. Un’ Architectural Spike è un programma scritto per sperimentare una soluzione, una sorta di prototipo, quasi sempre “usa e getta” per permettere una stima più accurata di una particolare user story.

Definite le User Story d’interesse si passa alla pianificazione dello sviluppo ossia alla assegnazione delle user story da implementare alle varie coppie di sviluppatori (Iterations to Release Phase). Mentre le iterazioni sono della durata fissa di una settimana, la durata di un rilascio varia a secondo che sia deciso per data (generalmente 2/3 mesi di durata) o per funzionalità (quante user story devono essere realizzate per lo specifico rilascio). L’importante è che ogni rilascio produca un sistema funzionante che permetta di ottenere feedback dal cliente. Gli sviluppatori devono sviluppare in modo semplice e concentrandosi sullo stretto richiesto (“il miglior modo per avere meno errori è avere meno codice!”). L’applicazione diventa quindi “il minimo insieme di codice che soddisfa i requisiti emersi” (“keep it simple”). Una riunione al giorno (in piedi!) permette di fare il punto della situazione e evidenziare eventuali problemi. Se l’iterazione è in ritardo, il cliente sceglie che storie differire alla successiva. La possibilità di tracciare il ritardo/anticipo permette di stimare la velocità di sviluppo del gruppo ed eventualmente rivedere la pianificazione del progetto. Terminata la codifica si inizia la fase di test di accettazione mediante sia test automatici al fine di certificare sia la qualità del codice prodotto sia per decidere l’eventuale rilascio (Productionizing Phase).

 

Come si può notare in questo ciclo di sviluppo appena descritto non è prevista esplicitamente né la fase di analisi né la fase di design. Queste fasi nei processi tradizionali (in questo contesto sono chiamate discipline) producono documentazione per il team stesso e per le fasi successive del progetto. In questo processo di sviluppo le fasi di analisi, design e sviluppo sono concentrate in un’unica fase e sulle medesime persone e questo fa sì che non vi sia una necessità immediata di produrre documentazione; in Xp il progetto evolve insieme al codice.

La documentazione del sistema in Xp è descritta mediante una System Methapor, una metafora del sistema che per Kent Beck è uno dei punti chiave dell’Xp. La metafora è una visione del sistema coerente e comprensibile sia dal cliente che dai programmatori. In molti casi la metafora può rispecchiare le entità nel mondo reale gestite dal sistema stesso e serve anche a dare nomi coerenti a classi, variabili e metodi del sistema, in modo che siano comprensibili a tutti i membri del gruppo di sviluppo. Le variabili in gioco in XP sono quattro: costo, tempo, qualità e portata. Generalmente tutte e quattro queste variabili sono fissate dal Management o dal client stesso. Xp dice che solo tre di queste variabili sono fissate a priori, mentre la quarta è il grado di libertà che sarà stabilita dal gruppo di lavoro in base al valore delle altre. In questo modo ad esempio a parità di costo e portata, se il management richiede una maggiore qualità, il tempo viene definito dal gruppo di sviluppo, committente permettendo. Tirando un po’ le somme, Xp si focalizza su gruppi di sviluppo piccoli (sull’ordine della dozzina di persone) per progetti di piccole medie dimensioni dove la stesura/modifica dei requisiti sono all’ordine del giorno. Il processo è semplice, snello e poco burocratico, ma deve essere comunque seguito con molta disciplina. E’ bene sottolineare che per applicare Xp il cliente ha un ruolo molto importante perché deve partecipare sia al progetto che alla sua evoluzione. Il Customer Xp è in ruolo chiave (e quindi anche critico) deve essere un esperto di dominio e quindi conoscere bene il business del cliente. Deve stabilire le priorità delle user story da implementare e specificare i relativi test di accettazione fino a tendere a condividere il successo/insuccesso del progetto. La critica più forte che viene mossa dagli oppositori di XP è che la disciplina funziona solo per buoni programmatori e che è inadatta a contesti progettuali in cui sia richiesta una tracciatura sistematica dei requisiti. Da un punto di vista organizzativo Xp prevede oltre alla figura di programmatore (stima le storie, definisce i task dalle storie, scrive il codice ed i relativi test), il Tester (esegue i test di accettazione e avverte il gruppo di sviluppo in caso di regressioni), il Tracker (tiene traccia della metrica e della storia del processo) ed il Coach; quest’ ultimo più che un Project Manager deve essere il Project Leader che segue/traccia il processo di sviluppo del progetto e aiuta in modo traversale nei casi di bisogno.