Manifesto for Agile Software Development

Nell’ingegneria del software, l’espressione metodologia agile si riferisce a un insieme di metodi di sviluppo del software emersi a partire dai primi anni 2000 e fondati su un insieme di principi comuni, direttamente o indirettamente derivati dai princìpi del “Manifesto per lo sviluppo agile del software” (Manifesto for Agile Software Development, chiamato anche “Manifesto Agile”) pubblicato nel 2001 da Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.. I metodi agili si contrappongono al modello a cascata e altri processi software tradizionali, proponendo un approccio meno strutturato e focalizzato sull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente (early delivery/frequent delivery), software funzionante e di qualità.

Il Manifesto Agile tradotto in italiano recita:

Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti: 1. Gli individuo e le interazioni più che i processi e gli strumenti 2. Il software funzionante più che la documentazione esaustiva 3. La collaborazione col cliente più che la negoziazione dei contratti 4. Rispondere al cambiamento più che seguire un piano Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.

Andando più a fondo possiamo aggiungere che:

1. Gli individui e le interazioni più che i processi e gli strumenti: il fattore chiave sono le persone; processi e strumenti sono importanti ma non compensano persone poco competenti
2. Il software funzionante più che la documentazione esaustiva:  la documentazione è utile ed è necessaria in un progetto ma il valore reale è dato da un software funzionante. La metodologia Agile prevede il rilascio di software funzionante attraverso incrementi successivi.
3. La collaborazione col cliente più che la negoziazione dei contratti: l’approccio Agile si basa sulla “condivisione di valore” e il cliente viene visto come un collaboratore.
4. Rispondere al cambiamento più che seguire un piano: tecnologie e modelli di business sono in continuo cambiamento; è quindi essenziale un approccio allo sviluppo in grado di adattarsi alle circostanze. Una “pianificazione statica” diventa obsoleta in breve tempo.

I dodici principi del Manifesto:

1. La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito
   e in maniera continua.
2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
3. Consegnamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
5. Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
7. Il software funzionante è il principale metro di misura di progresso.
8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
10. La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Che cos’è SCRUM?

Scrum è il metodo Agile più diffuso, si tratta di un framework, un particolare insieme di pratiche, che divide il processo di gestione di un progetto in sprint. Un processo iterativo in cui gli sprint durano da 2 a 4 settimane.

La teoria alla base di questo metodo è quella del controllo empirico dei processi, secondo la quale, la conoscenza deriva dall’esperienza e le decisioni si basano su ciò che si conosce. Per questo motivo si prevede un processo iterativo con un approccio incrementale che ottimizza, passo dopo passo (sprint dopo sprint), la prevedibilità ed il controllo del rischio.

Un metodo che si basa sui principi della trasparenza, dell’ispezione e dell’adattamento.

Le componenti principali di SCRUM si dividono in: ruoli, artefatti ed eventi.

Ruoli

PRODUCT OWNER (r1): colui che conosce tutti i requisiti del prodotto è l’interfaccia tra il business, i clienti e i requisiti del prodotto da un lato e il team dall’altro.
SCRUM MASTER (r2): il responsabile del processo, colui che deve garantire che la metodologia Scrum venga compresa ed eseguita con successo.
TEAM DI SVILUPPO (r3): il gruppo di professionisti cross-funzionali ed auto-organizzato, il cui numero di solito si mantiene da 5 a 9. Si occupa dello sviluppo del prodotto e del testing delle funzionalità e ha la responsabilità di organizzare requisiti in task da completare in un determinato sprint.

Artefatti

PRODUCT BACKLOG (a1): la lista di tutti requisiti necessari per la realizzazione del progetto. Il Product Owner è responsabile del suo contenuto, della sua disponibilità e dell’ordinamento dei suoi elementi in base alla rispettiva priorità di svolgimento.
SPRINT BACKLOG (a2): definisce tutti i task da completare nei singoli sprint. È una previsione fatta dal Team di Sviluppo in relazione alle priorità indicate nel Product Backlog e al lavoro necessario per raggiungere gli obiettivi dello sprint.
INCREMENTO (a3): la somma di tutti gli elementi del Product Backlog completati durante uno sprint e durante gli sprint precedenti. Al termine dello sprint l’incremento dovrà garantire un prodotto utilizzabile.

Eventi

SPRINT PLANNING (e1): la riunione in cui il Product Owner ha stilato il Product Backlog e, in presenza del Team di Sviluppo e dello Scrum Master, descrive gli item più importanti e l’obiettivo da raggiungere nello sprint seguente. Al termine della riunione lo Scrum Master può compilare lo Sprint Backlog.
DAILY SCRUM (e2): un breve confronto giornaliero (della durata di 15 min) fra Team di Sviluppo e lo Scrum Master, il quale annota il lavoro svolto il giorno precedente e crea un piano per le prossime 24 ore (fino al prossimo Daily Scrum) per prevedere e sincronizzare le attività. Si preoccupa inoltre di rilevare eventuali impedimenti ed attuare possibili rimedi così da salvaguardare il buon esito dello sprint in corso. E’ a carico dello Scrum Master dichiarare il fallimento dello sprint in caso di impedimento critico, imprevisto e non risolvibile. Il fallimento dello sprint si traduce nella chiusura dello sprint in corso e nell’avio di un nuovo Sprint Planning.
SPRINT RETROSPECTIVE (e3): una retrospettiva effettuata con la partecipazione di tutto lo Scrum Team per valutare cosa continuare a fare, cosa smettere di fare e cosa migliorare nello sprint successivo per ottenere performance ancora più efficienti.
SPRINT REVIEW (e4): una revisione alla fine di ogni sprint per valutare se l’obiettivo prefissato è stato raggiunto e con quali risultati. Partecipa tutto lo Scrum Team e anche il committente del prodotto, al quale verrà mostrato il lavoro svolto fino a quello sprint.