Scrum

Scrum è un approccio allo sviluppo del software che prevede la suddivisione del progetto in iterazioni del progetto dette Sprints. Ad inizio progetto vengono definite le funzionalità che si dovranno implementare chiamate Backlog con le relative priorità. Tali priorità vengono assegnate da un’unica persona, il Product Manager, responsabile del prodotto e della sua visione; senza la sua autorizzazione non è possibile modificare la priorità del Product Backlog. Prima dell’inizio di ogni sprint, il gruppo di lavoro si riunisce con il responsabile del prodotto e insieme concordano gli elementi prioritari del Backlog che si dovranno implementare durante lo sprint. Ogni sprint ha una durata predefinita di 30 giorni ed una volta decisi gli obiettivi, questi non possono essere cambiati (se non dagli sviluppatori stessi) sino alla fine dello Sprint stesso. Al termine di ogni Sprint deve esserci il rilascio del software prodotto che deve essere un qualcosa di tangibile e utilizzabile dal cliente.
Durante lo sprint ogni giorno il team tiene un breve incontro di una quindicina di minuti chiamato Daily Scrum (Scrum è un termine che deriva dal Rugby e indica il “pacchetto di mischia”) dove il capo progetto (Scrum Master) annota i backlog completati e quelli che rimangono ed ogni sviluppatore racconta cosa ha fatto quel giorno e cosa dovrà fare il successivo.
In generale gli Scrum Meeting si tengono generalmente sempre allo stesso posto e alla stessa ora per dare un ben preciso “ritmo” al progetto. Con lo Scrum si ha un ciclo di controllo molto fine che permette capire lo stato quotidiano di avanzamento dei lavori e di scoprire quanto prima eventuali problemi progetto. Da un punto di vista organizzativo Scrum prevede un Product Owner (analogo al Customer in XP) che come committente del lavoro definisce le cose da fare (Product Backlog) e le relative priorità con scadenza mensile. Lo Scrum Master (analogo al Coach di Xp) è invece responsabile di gestire gli allineamenti giornalieri e mensili tenendo quindi traccia dello stato di avanzamento dei lavori e della situazione dei Backlog. Ogni mese (Sprint Review) definisce il lavoro per il mese successivo (Sprint Planning) in base alla priorità evidenziate dal Product Owner e sulle stime di impegno da parte del gruppo di sviluppo. Il gruppo di sviluppo (Scrum Team) crea un elenco (Sprint Backlog) di task (sotto attività del Backlog) da effettuare per raggiungere gli obiettivi del mese, segnala eventuali criticità allo Scrum Master negli allineamenti giornalieri e mensilmente presenta i risultati ottenuti durante lo Sprint. E’ bene precisare, prima di concludere questa breve descrizione, che SCRUM è una metodologia che definisce pratiche per pianificare e gestire i progetti, cioè di Project Management, ma non indirizza la modalità di sviluppo del prodotto (raccolta requisiti, analisi, disegno, sviluppo, test, …) e che quindi occorre integrarlo con altri approcci (XP, FDD, …) per indirizzare il processo di sviluppo.

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.

Metodologie agili

La nascita delle metodologie agili si può inquadrare nel periodo del boom “Internet” degli ultimi anni 90 dove la produzione di software ha visto riduzioni drastiche dei tempi di sviluppo e di rilascio dei prodotto software passando dall’ordine degli anni all’ordine di mesi. Le metodologie agili vengono anche dette “leggere” (lightweight) e si contrappongono alle metodologie pesanti (heavyweight) come quella waterfall o a certe ‘istanziazioni’ RUP che prevedono un consistente “formalismo”.

L’idea alla base delle metodologie agili è che non sono predittive, cioè non cercano di prevedere come evolverà il sistema software, bensì sono adattive, cioè cercano di capire le pratiche migliori per meglio adattarsi all’evoluzione dei requisiti dell’utente più che del sistema software.

Lo scopo delle metodologie agili è quindi quello di gestire progetti dove i requisiti utente non sono conosciuti a priori o sono “volatili” e quindi il processo non è completamente prevedibile a priori e di conseguenza un approccio predittivo potrebbe risultare poco efficace. Le metodologie agili quindi si concentrano sul facilitare il più possibile le modifiche al sistema basandosi su un processo iterativo composto da fasi di progettazione, sviluppo e test molto brevi al fine di agevolare l’adattamento in corso di sviluppo orientandosi fortemente ai risultati.

Le caratteristiche comuni di una metodologia di sviluppo agile sono:

• La capacità di gestire i requisiti “instabili”: nei progetti in cui si è costretti a “rincorrere” l’evoluzione dei requisiti utente quasi in tempo reale l’adozione di discipline agili è particolarmente indicato
• Adattabilità: adattare piuttosto che pianificare
• Iteratività e incrementalità: fasi ridotte per concentrarsi su piccoli obiettivi in modo ciclico
• Rilasci frequenti: grazie al ciclo di sviluppo concentrato, i rilasci sono più frequenti
• Test: il codice deve essere testato in modo automatico e continuo
• Orientamento alle persone: privilegiare le persone rispetto ai processi
• Collaborazione con il cliente piuttosto che negoziazione del contratto

Il manifesto

La formalizzazione dei principi su cui si basano le metodologie leggere è stata oggetto del lavoro di un gruppo di progettisti software e guru dell’informatica che si sono spontaneamente riuniti nell’Agile Alliance. Il documento finale di questo lavoro, detto Agile Manifesto [Manifesto], è stato poi sottoscritto da un nutrito gruppo di questi professionisti, molti dei quali hanno anche sviluppato alcune delle metodologie leggere più famose. Sono nate diverse metodologie agili come ad esempio XP, Agile Modeling, Agile Data, Scrum, FDD, DSDM, Crystal. Nel seguito di questo paragrafo verranno trattate alcune di queste metodologie.

I Principi

I principi su cui si basa una metodologia leggera che segua i punti indicati dall’Agile Manifesto, sono solo quattro:

• le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto);
• è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile);
• bisogna collaborare con i clienti al di là del contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali);
• bisogna essere pronti a rispondere ai cambiamenti più che aderire al progetto (quindi il team di sviluppo dovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento).

Pratiche

Le singole pratiche applicabili all’interno di una metodologia leggera sono decine e dipendono essenzialmente dalle necessità dell’azienda e dall’approccio del project manager. Nella scelta però bisogna tenere conto delle caratteristiche di ogni pratica per i benefici che apporta e le conseguenze che comporta. Ad esempio, in Extreme Programming, si supplisce alla mancanza assoluta di qualsiasi forma di progettazione e documentazione con lo strettissimo coinvolgimento del cliente nello sviluppo e con la progettazione in coppia. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possono essere raggruppate in categorie:

 

• Automation – Se l’obiettivo delle metodologie leggere è concentrarsi sulla programmazione senza dedicarsi alle attività collaterali, allora possono essere eliminate o automatizzate; la seconda soluzione è migliore perché si può, ad esempio, eliminare la documentazione aumentando il testing, ma non si possono eliminare entrambe; quindi si sceglie che strada si vuole percorrere e si fa in modo da utilizzare strumenti per automatizzare il maggior numero di attività;
• Close Communication – Secondo Alistar Cockburn, probabilmente il primo teorico delle metodologie leggere, questo è l’unico vero aspetto nodale che renda leggera una metodologia. Per comunicazione diretta si intende la comunicazione interpersonale, fra tutti gli attori del progetto, cliente compreso. Ciò serve ad avere una buona analisi dei requisiti ed una proficua collaborazione fra programmatori anche in un ambito di quasi totale assenza di documentazione;
• Customer Involvement – Il coinvolgimento del cliente è qui indicato singolarmente perché ci sono differenti gradi di coinvolgimento possibili; ad esempio in Extreme Programming il coinvolgimento è totale, il cliente partecipa persino alle riunioni settimanali dei programmatori; in altri casi, il cliente è coinvolto in una prima fase di progettazione e poi non più; in altri ancora il cliente partecipa indirettamente e viene usato come test della versione rilasciata;
• Design & Documentation – Pensare che le metodologie leggere eliminino la progettazione e la documentazione è un errore; in effetti non è così, le metodologie leggere introducono un’iterazione nel ciclo di vita del progetto. Quanta progettazione fare e quanta documentazione produrre, escludendo i casi estremi, è una scelta lasciata a chi gestisce il progetto e spesso i teorici dell’Agile Alliance avvisano che è un errore trascurare o addirittura omettere queste due fasi;
• Frequent Delivery – Effettuare rilasci frequenti di versioni intermedie del software permette di ottenere più risultati contemporaneamente: si ricomincia l’iterazione avendo già a disposizione un blocco di codice funzionante in tutti i suoi aspetti, si offre al cliente “qualcosa con cui lavorare” e lo si distrae così da eventuali ritardi nella consegna del progetto completo, si usa il cliente come se fosse un test visto che utilizzerà il software e riscontrerà eventuali anomalie, si ottengono dal cliente informazioni più precise sui requisiti che probabilmente non sarebbe riuscito ad esprimere senza avere a disposizione utilità e carenze del progetto;
• Hierarchy – La scelta di creare una struttura gerarchica all’interno del team di sviluppo dipende molto dall’approccio del project manager, in ogni caso si ha una conseguenza non secondaria facendo questa scelta. Se si decide per una struttura gerarchica ad albero e frammentata si ottiene la possibilità di gestire un numero molto alto di programmatori e di lavorare a diversi aspetti del progetto parallelamente; se si decide per una totale assenza di gerarchia si avrà un team di sviluppo molto compatto e motivato, ma necessariamente piccolo in termini di numero di programmatori;
• Pair Programming - Programmare in coppia, ossia: due programmatori, due sedie, una scrivania, un computer, una tastiera ed un mouse; uno dei due scrive, l’altro verifica, entrambi scelgono la soluzione costruttiva migliore. E’ stato dimostrato che i costi di questa scelta sono inferiori ai benefici che apporta, ma ci sono esempi pratici che indicano come questa pratica possa essere insopportabile per alcuni programmatori e quindi controproducente;
• Refactoring – Ossia la riscrittura completa di parti di codice mantenendone invariato l’aspetto esterno. Nel caso di una funzione ciò significa riscriverne completamente il core mantenendone invariato header ed ovviamente sintassi, trattandola cioè come una black box. L’intervento sul codice può avvenire “con coraggio”, perché si hanno test unitari e funzionali che garantiscono la non regressione dell’intervento. E’ una delle pratiche più diffuse e suggerite, ma anche questa, come il Pair Programming, ha differenti studi che ne attestano l’inutilità ed in alcuni casi la dannosità;
• Reflective Improvement – Nata con l’avvento della programmazione Object-Oriented, non è altro che la presa di coscienza della produzione di conoscenza che si fa in un un’azienda man mano che si produce codice. Questa conoscenza prodotta non deve andare perduta ed è per far ciò che si sfruttano spesso le altre pratiche, come la comunicazione stretta o la condivisione della proprietà del codice;
• Reverse Engineering – Ossia ottenere, spesso in maniera automatica, la documentazione a partire dal codice già prodotto. E’ una delle pratiche più diffuse e più controverse, diffusa perché permette un guadagno enorme in termini di tempo, ma controversa perché spesso la documentazione prodotta è inutilizzabile oppure è prodotta solo per una richiesta burocratica del cliente e non verrà mai realmente utilizzata;
• Simplicity – Uno dei punti chiave delle metodologie leggere, direttamente mutuato dalla programmazione Object-Oriented, è la semplicità. Semplicità nel codice, semplicità nella documentazione, semplicità nella progettazione, semplicità nella modellazione. I risultati così ottenuti sono una migliore leggibilità dell’interno progetto ed una conseguente facilitazione nelle fasi di correzione e modifica;
• Team forming & Code property – La formazione del team di sviluppo è condizionata dalla scelta sulla gerarchia interna, ma segue regole precise che permettono di ottenere un team produttivo nell’ambito della metodologia scelta. Il codice in particolare segue standard precisi al fine di permettere a chiunque di sentirsi a proprio agio con il codice scritto da altri membri del gruppo, visto che si ha una proprietà collettiva del codice. La scelta dei membri del team è condizionata anche alla scelta della proprietà del codice, che può essere individuale o collettiva; nel primo caso la responsabilità sullo sviluppo è individuale, nel secondo dipende da tutto il team e quindi dal project manager;
• Testing – Pratica diffusissima anche prima della nascita delle metodologie leggere, ha prodotto una letteratura vastissima ed una serie di approcci differenti come il Rapid Testing o il Pair Testing. Nell’ambito delle metodologie leggere vengono spesso utilizzati insieme tre tipi di test differenti: i test funzionali, utilizzati per verificare che il software faccia effettivamente ciò che è previsto debba fare, i test unitari, utilizzati per verificare che ogni pezzo di codice funzioni correttamente, e i test indiretti effettuati inconsciamente dal cliente ogni volta che gli si consegna una versione;
• Version Control – Una delle conseguenze dirette dell’iterazione nella produzione è la necessità di introdurre un modello, un metodo, uno strumento, per il controllo delle versioni del software prodotto e rilasciato; uno degli strumenti più diffusi e maggiormente suggeriti per ottemperare automaticamente a questa pratica è CVS [Wiki].
• Continuous integration – Con il termine Continuous Integration si indica una pratica di sviluppo software in cui i membri di un team integrano il loro lavoro frequentemente, tipicamente ogni persona integra al meno una volta al giorno, fino ad arrivare a integrazioni multiple per giorno. Ogni integrazione è verificata da una build automatica (inclusi i test) per scoprire errori di integrazione più velocemente possibile. Molti team trovano che questo approccio porta a un numero significativamente ridotto di problemi di integrazione e permette ad un team di sviluppare software coeso più velocemente. Le pratiche di Continuous integration sono:

• Mantenere un solo repository dei sorgenti.
• Automatizzare la build del progetto.
• Rendere i test sulla build automatici.
• Ogni sviluppatore deve committare almeno una volta al giorno.
• I commit non devono rompere la build sulla macchina di integrazione.
• Mantenere la build veloce.
• Testare in un clone dell’ambiente di produzione.
• Rendere semplice a chiunque di recuperare l’ultima versione del software eseguibile.
• Permettere a tutti di vedere cosa sta succedendo.
• Automatizzare il deploy negli ambienti di test.