Metodologie Agile

I limiti del modello a cascata

L’approccio agile al lavoro è una metodologia che nasce per fare fronte ai limiti del modello a cascata, il Waterfall.

Come visto sopra il modello Waterfall, di fatto il principale modello di sviluppo fino alla fine del XX secolo, mostrava come le aziende più grandi avevano definito un processo di sviluppo del software strutturato come quello di una catena di montaggio. Il cliente, grande o piccolo, doveva adeguarsi al prodotto ed al processo, e non il software alle sue necessità. In pratica le aziende software sviluppavano progetti software che rispondevano a un insieme di requisiti generali validi per molti clienti diversi, molto rigidi perchè legati ai vincoli della progettazione, e che imponevano quindi ai clienti, anche in progetti “chiavi in mano”, la necessità di seguire sua rigide procedure di sviluppo (tempi contingentati) e quindi prodotti strutturati secondo le esigenze del fornitore del software e non del committente. 

Non solo i clienti ma tutti i team coinvolti (quindi progettisti, programmatori, designers, testers, ecc.) dovevano quindi adeguarsi alle modalità previste dall’azienda, adeguandosi ad essa e non viceversa. Questa modalità permette di far raggiungere alla azienda software i suoi obiettivi economici, ma questo significa anche avere software generico, al quale l’utente si deve adeguare, nei casi peggiori dovendo fare corsi, adeguando i propri flussi di lavoro, adattandosi alle sue evoluzioni. Allo stesso modo la qualità del software è strettamente legata al processo: il tempo per fare bugfix, migliorie, refactoring è dipendente dal tempo assegnato a quella fase, col risultato che il software può non avere una qualità adeguata, perchè è sottostimato il tempo di correzione dei difetti.

Grazie all’avvento del web, che da una parte costituisce una nuova forma tecnologica del prodotto software e delle applicazioni “connesse” e dall’altra rende più semplice la comunicazione tra comunità di programmatori fino ad allora distanti, questo modello viene messo in discussione e si cominciano a proporre modelli alternativi.

Agile Manifesto

Tra questi il più importante è l'”agile manifesto”. E’ un documento scritto nel 2000 da un gruppo di informatici ingegneri e ricercatori. In questo documento gli autori evidenziano i problema sopra esposti ovvero che la rigidità della pianificazione dei cicli di sviluppo software Waterfall aveva fatto perdere di vista l’obiettivo principale del software, ovvero soddisfare necessità e bisogni.  L’agile manifesto più che proporre un modello alternativo va piuttosto a definire quattro principi generali nello sviluppo software.

– puntare agli individui e alle loro relazioni e mettere in secondo piano i processi;

– dare priorità al software funzionante più che a specifiche corrette;

– mettere al centro la collaborazione col committente, più che una contrattazione scritta;

– dare priorità al cambiamento anzichè al piano iniziale di progetto.

In altri termini, un processo agile non è rigido nè ha una pianificazione predeterminata ma si basa prima di tutto sulla negoziazione col cliente del prodotto da realizzare. Questo significa suddividere il progetto non in task ma in unità di tempo (“time-boxed“) nelle quali si produce un risultato. In quella unità di tempo il team di sviluppo analizza, l’attività da svolgere, la progetta, la realizza e la consegna al cliente che ne valuta il risultato. Viene quindi eliminato quello che è considerato uno “spreco di risorse” nelle fasi di analisi e documentazione, in virtù invece di un software funzionante e testato che “documenta se stesso”.

Nel team inoltre, nell’ambito delle proprie competenze, ciascun soggetto ha una propria autonomia: il programmatore non riceve una specifica dettagliata, ma un perimetro di lavoro, l’analista riceve una specifica generica, il cliente stesso ha un ruolo nella verifica della qualità. in un processo agile tendenzialmente si riduce di molto la documentazione, e si tende invece ad automatizzare ed informatizzare le attività da svolgere, sotto forma di checklist o strutture analoghe. La collaborazione è infine in real time ed in generale la responsabilità del codice è collettiva (e non del solo responsabile tecnico verso il PM).

Nello schema tipico agile il software stesso è un semilavorato dove si procede in uno sviluppo a cicli che non viene pianificato in base agli obiettivi da raggiungere (es. “ci vuole una settimana per fare questo task”) ma sono gli obiettivi che vengono scomposti in modo da essere realizzati in unità di tempo (es. “in una settimana possiamo fare il task a, b e c”). 

Il modello Agile è è stato prima adottato dalle piccole aziende di software e sebbene sia considerato “alternativo” si adatta meglio a progetti software “tailor made” dove il client anzichè comprare un progetto compra del tempo da parte della società di software, tempo che viene messo a disposizione per produrre insieme al cliente il prodotto finale. Anche le grandi aziende hanno introdotto l’Agile (senza eliminare Waterfall), perché permette di semplificare in molti casi le strutture organizzative e le rigidità di Waterfall, inoltre garantisce una collaborazione con team esterni per un software più modulare. 

La grande limitazione di Agile è che richiede competenza, mentalità ed una fase di allenamento: questo significa che richiede una formazione maggiore rispetto al modello Waterfall. Non è un modello senza rigidità, semplicemente sono spostate e suddivise in modo diverso.

In ogni caso Waterfall non è stato abbandonato, anzi è e resta il modello più affidabile per determinati tipi di software, come i prodotti chiavi in mano.

Scrum

Scrum (“pacchetto di mischia” termine preso in prestito dal rugby) è il modello più famoso di sviluppo agile, o come dicono gli autori è un “framework”.

All’interno di Scrum esistono tre figure: Product Owner, Scrum Master e i Developer (e analisti, tester, sistemisti). Tutti insieme formano lo Scrum Team.

Scrum è strutturato in cicli chiamati Sprint che durano da una a quattro settimane. I cicli sono timeboxed, il che significa che hanno durata fissa nel tempo, non possono essere estesi e terminano anche se il lavoro non è stato ultimato, questo implica che la pianificazione deve essere molto attenta su questo aspetto. Entro il termine dello Sprint il team rilascia un Increment, che deve sempre essere completo (Done) e rilasciabile all’utente finale.

Per esempio, nel caso di una normale applicazione software potrebbe voler dire una funzionalità interamente integrata, funzionante e testata.

Il team produce tre artefatti (deliverable). Essi sono: Product Backlog, Sprint Backlog e il software ovvero appunto l’Increment. Ogni artefatto include un “commitment”, ovvero un obiettivo finale. Questi commitment sono:

• Product Goal, che fa parte del Product Backlog e descrive uno stato futuro (possibilmente finale) del prodotto. Il Product Goal serve come obiettivo a lungo termine ma può essere cambiato nel singolo Sprint. Esso è descritto dal Product Backlog ed è formato da unità temporali dette Sprint (time boxed).
• Sprint Goal, che è parte dello Sprint Backlog; descrive l’obiettivo da raggiungere nel singolo Sprint e definisce perchè aggiunge valore al prodotto finale. Un Product Goal è quindi il risultato di più Sprint.
• Definiton of Done, che descrive quando un Increment (ovvero un incremento di software) raggiunge uno standard qualitativo adeguato a consentire il rilascio all’utente finale. 

Il fine ultimo non è quindi completare il maggior numero di attività possibile, ma produrre incrementi di software completamente funzionanti e utilizzabili, attraverso il raggiungimento dello Sprint Goal. Questo obiettivo è concordato all’interno di tutto lo Scrum Team e non è stabilito a priori dal Product Owner.

Altro aspetto fondamentale sono le riunioni, che sono le seguenti:

• Sprint Planning, che avviene all’inizio dello Sprint (o iterazione), qui si esegue la pianificazione.
• Daily Scrum, una riunione giornaliera di 10-15 minuti in cui gli sviluppatori condividono le attività del giorno. Spesso per rendere la riunione più veloce si fa in piedi (“Standup meeting”).
• Sprint Review, che chiude uno Sprint e dà l’occasione di ispezionare il lavoro svolto
• Sprint Retrospective, ha la funzione di ispezionare i processi, le pratiche e altri aspetti legati alla collaborazione per migliorarli nello Sprint successivo.

Nel framework Scrum, l’intero team è auto organizzato e il team di sviluppo è cross funzionale, cioè tutti i dev possono mettere le mani su tutto il codice.

Non esiste la figura del Project Manager al suo posto c’è lo Scrum Matser, che ha il compito di rimuovere ostacoli e impedimenti che esulano dai compiti del team, e in via eccezionale ha la facoltà di influenzare e cambiare i piani qualora si rendesse necessario.
È importante sottolineare come tutto ciò che viene pianificato all’inizio dell’iterazione può essere cambiato, ovvero si rivedono le specifiche ed il codice.Le uniche condizioni sono che i cambiamenti non vadano a influire negativamente sui livelli di qualità del prodotto o sullo Sprint Goal – che è fisso per tutta la durata del ciclo.

Lo Sprint Review è invece un incontro informale in cui il team mostra il lavoro svolto al Product Owner. La Retrospective è un incontro successivo al termine del Review dove invece il team fa una analisi dello Sprint per migliorare i propri processi.

Lo Scrum mostra quindi un approccio fortemente empirico: anzichè partire da una idea di sviluppare completamente prima di scrivere la prima riga di codice, si parte da un prodotto iniziale che viene effettivamente realizzato, e poi si costruiscono sia l’idea che il prodotto strada facendo, attraverso un processo di analisi ed adattamento alle esigenze che nel frattempo possono cambiare.