0689178001

I vantaggi della metodologia Agile

I vantaggi della metodologia Agile

  • d.barbato
  • Nessun commento

Introduzione ad Agile e al metodo SCRUM

  • Nessun commento

La conduzione delle attività legate allo sviluppo software costituisce spesso il cuore dell’andamento della vita aziendale nelle realtà che operano nell’IT. Le necessità di adattare i modelli di gestione aziendale alle nuove condizioni di produzione – caratterizzate sempre più spesso da altissima competitività e tempi sempre minori che garantiscano comunque un output di elevata qualità – ha portato al superamento delle tradizionali metodologie di gestione progetti e all’avvento, già dai primi anni 2000, di metodologie e tecniche più evolute.

La nostra propensione a ragionare per obiettivi e la capacità di organizzare team di lavoro in grado di organizzarsi autonomamente tramite una pianificazione in grado di prevedere uno sviluppo di tipo incrementale e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo, sono elementi che ci hanno portato ad acquisire l’esperienza necessaria per prediligere metodi di sviluppo Agile con l’obiettivo di ridurre il rischio di fallimento e raggiungere tempi di rilascio complessivamente più brevi.

In questo primo articolo cercheremo di riassumere i principi fondanti di Agile e le sue principali caratteristiche, per concentrarci poi, tra le molteplici metodologie di sviluppo che rompono con la precedente tradizione, sul metodo SCRUM, il più diffuso, descrivendone le componenti essenziali. Illustreremo casi pratici di progetti realizzati all’interno di un contesto di introduzione della metodologia in una organizzazione consolidata da anni nell’applicazione dei processi più tradizionali.

La metodologia Agile VS metodologia a cascata - Waterfall

La metodologia Agile nasce dalla constatazione, derivata da una serie di studi in ambito metodologico, per la quale la maggior parte dei progetti intrapresi all’interno di una realtà aziendale non riuscivano a raggiungere il successo auspicato individuando, nel caso dei progetti software in particolare, nell’utilizzo della metodologia Waterfall la principale causa di fallimento.

Perché accade questo?

La metodologia Waterfall comporta l’organizzazione del lavoro in una catena di fasi progettuali strettamente sequenziale. Può esserci un limitato overlapping, ma nella sostanza la fase successiva non può iniziare se non è completata quella precedente. Tornare sui propri passi può essere nella maggior parte dei casi difficile, costoso, frustrante per il team.

La timeline di progetto (schedulazione) è pianificata all’inizio di progetto. Il prodotto/servizio realizzato dal progetto viene rilasciato solo al termine della timeline di progetto. Il ritardo di una fase determina lo slittamento delle fasi successive.

Per questo, chi applica la metodologia Waterfall cerca di anticipare il più possibile ogni aspetto di pianificazione e ogni possibilità. Ciò vuol dire definire in fase iniziale tutti i requisiti al livello di maggior dettaglio e completezza possibile. Tuttavia, all’inizio del progetto le informazioni non sono ancora consolidate e molti requisiti cambiano (o possono cambiare) in corso d’opera. Alcuni studi hanno mostrato come in progetti di grande dimensione e complessità, mediamente il 60% dei requisiti iniziali vengano modificati in corsa. Altri requisiti sono realizzati così come definito all’inizio, ma a fine corsa si scoprono non essere realmente rispondenti alle necessità dell’utente, e si constata facilmente che il tempo impiegato per risolverli avrebbe potuto essere utilizzato per implementare funzionalità di maggior valore aggiunto per l’utente.

Agile prende vita proprio per rispondere a queste criticità. Se vediamo i concetti fondamentali alla sua base, troviamo che tutto è imperniato sulla necessità di mantenere sempre la dovuta flessibilità durante lo svolgimento del progetto senza che questo ne intacchi i principi fondamentali:

“Being Agile is to possess the ability to both, create and respond to change in order to profit in a turbulent business environment”

(Jim Highsmith)

Agile tra flessibilità e stabilità: concetti fondanti e principi derivati

Agile significa adattarsi al cambiamento, non vederlo più come eccezione negativa (embrace the change).

Le metodologie Agili non sono limitate allo sviluppo software ma in generale sono applicabili a tutti i cosiddetti “knowledge projects”, dove la conoscenza rappresenta la materia prima dei deliverable prodotti. Ancora più in generale, i metodi Agili si dimostrano proficui in situazioni di variabilità, indeterminazione e innovazione, quando risulta difficile se non impossibile determinare a priori caratteristiche e requisiti di un sistema.

Qualsiasi settore industriale che debba fronteggiare rapidi cambiamenti può trovare aspetti interessanti nei metodi Agili, perché laddove sono presenti cambiamenti non solo tecnologici, ma organizzativi, sistemici e di comportamento degli utenti, che normalmente rendono l’approccio tradizionale poco efficace, questi metodi possono invece fornire alcune risposte interessanti.

Accadde così che nel 2001 un gruppo di 17 tra gli esponenti più autorevoli del mondo dello sviluppo e dell’ingegneria del software, si misero insieme ad elaborare dei nuovi principi sulla base di queste esigenze, e ciò che nacque fu il “Manifesto per lo sviluppo Agile del Software”, che sarebbe diventato l’insieme di principi guida alla base di qualsiasi metodologia Agile.

Cerchiamo di riassumerne in modo semplice i quattro concetti fondanti:

  • Individual and interactions… over processes and tools.
    • (Persone e interazioni… piuttosto che processi e strumenti)

Il fattore chiave in qualsiasi progetto sono le persone, e l’enfasi dovrebbe essere su di loro e sulle loro interazioni. Processi e strumenti sono importanti ma incidono meno (in sostanza: processi e strumenti anche raffinatissimi non compensano persone poco competenti)

  • Working software… over comprehensive documentation.
    • (Software funzionante… piuttosto che tonnellate di documentazione)

La documentazione (sia quella raccolta sia l’archiviazione di descrizioni qualitative e quantitative dei deliverable) è utile e necessaria in un progetto, ma il valore reale di un’applicazione, dal punto di vista dell’utente, è dato da un software funzionante.

Il focus di qualsiasi metodo Agile è il rilascio di software funzionante attraverso incrementi successivi durante il ciclo di vita del progetto.

  • Customer collaboration… over contract negotiation.
    • (Collaborazione con il Cliente…. Piuttosto che contrattazione)

Nella visione tradizionale il cliente è visto come un “outside player” coinvolto solo all’inizio (ingaggio e vendita) e alla fine (rilascio e collaudo) del processo produttivo, con relazioni solitamente definite in modo rigido da clausole contrattuali.

L’approccio Agile si basa invece sulla “condivisione di valore” e il cliente viene visto come un collaboratore. Team e cliente lavorano assieme per realizzare ed evolvere il prodotto. Va anche detto che esistono anche metodologie non esplicitamente Agili che partono da presupposti di questo tipo (UCD, design partecipativo, etc.), in alcuni metodi Agili però il cliente arriva addirittura ad essere esplicitamente un membro del team.

  • Responding to change… over following a plan.
    • (Rispondere ai cambiamenti… piuttosto che seguire rigidamente le pianificazioni)

In qualsiasi mercato i requisiti dei clienti, le tecnologie disponibili, i meccanismi e i modelli di business sono in continuo cambiamento. È essenziale e preferibile un approccio allo sviluppo di beni e servizi in grado di adattarsi alle circostanze recependo i cambiamenti e i cicli produttivi sempre più rapidi, piuttosto che seguire delle “pianificazioni statiche” che rischiano di divenire obsolete in breve tempo.

Su questi quattro principi, considerati un po’ come i pilastri di un palazzo, sono stati elaborati 12 principi derivati che rappresentano nella sua completezza il “Manifesto dello sviluppo Agile” (riportiamo i titoli in inglese così che siano proprio quelli derivati dal testo ufficiale):

  1. Customer satisfaction – attraverso il continuo e anticipato rilascio di software funzionante;
  2. Welcome change in requirements – approccio adattativo allo sviluppo del prodotto, i cambiamenti sono i benvenuti;
  3. Delivering working software frequently – da ogni 2 settimane a 2 mesi, con preferenza per la scala temporale più piccola;
  4. Business people and developers must work together daily throughout the project;
  5. Build projects around motivated individuals – le persone sono il fattore chiave;
  6. The most efficient and effective method to conveying information to and within a development team is face-to-face conversation – F2F;
  7. Working software is the primary measure of progress – il vero valore rilasciato ai clienti / utenti;
  8. Agile processes promote sustainable development – per migliorare nel tempo la qualità dei prodotti;
  9. Continuous attention to technical excellence and good design enhances Agility – attraverso la continuous integration, il re-factoring del codice, il Test Driven Development;
  10. Simplicity – the art of maximizing theamount of work not done – is essential – quello che non c’è non si rompe;
  11. Best architectures, requirements and design emerge from self-organizing teams -responsabilizzare significa anche motivare, cfr. Principio n. 5;
  12. At regular intervals the team reflects on how to become more effective and then tunes and adjusts its behaviour accordingly;

Attualmente, sulla base di questi principi, esistono diversi metodi agili applicati con efficacia nei campi più svariati, ed hanno nomi come SCRUM, Lean Kanban Development, Extreme Programming –XP, DSDM –Dynamic System Development Method, Adaptive Software Development.

In questa introduzione vogliamo cominciare ad accennare al primo fra questi, il metodo chiamato SCRUM. SCRUM, nel linguaggio sportivo del Rubgy, è la mischia.

Già normalmente, soprattutto per chi non è particolarmente appassionato di questo sport, una partita di rugby appare come una specie di guerra di trincea dove un gran numero di energumeni si fronteggiano e si picchiano su un prato verde per il possesso di una strana palla di forma ovale. Ma ancor di più, in una partita di rugby, la mischia è quel momento in cui sembra che tutti i giocatori si ammucchino alla rinfusa spingendo un po’ a caso senza neanche guardare bene dove.

Il nome di questo metodo Agile è stato scelto appositamente proprio perché la realtà di una mischia al rugby è molto diversa da quel che può apparire dall’esterno ad un occhio poco esperto. Ogni giocatore ha in effetti un ruolo preciso, e quella che sembra essere una rissa con movimenti casuali è in realtà il frutto di uno schema organizzato, dove tutti spingono nella stessa direzione ma dove ciascuno lo fa per le proprie caratteristiche (in quel caso soprattutto fisiche).

Da questa idea nasce il concetto secondo cui uno SCRUM-TEAM è formato da diversi ruoli (compreso il Cliente) che anziché trovarsi in punti diversi e addirittura in posizioni contrapposte sono in realtà tutti fianco a fianco, abbracciati quando non “avvinghiati” fra loro, per raggiungere tutti insieme un obiettivo comune.

Il metodo SCRUM, che attualmente risulta essere, se non la più popolare metodologia di sviluppo Agile sicuramente una delle più diffuse, si presenta con i seguenti punti di forza:

  • È Adattiva, Iterativa, Veloce, Flessibile, Efficace;
  • Assicura trasparenza nelle comunicazioni;
  • Determina una responsabilità collettiva dei risultati;
  • Supporta diverse tipologie di progetto;

Per dirla in modo sintetico: Scrum è un framework attraverso il quale si cerca di indirizzare le soluzioni aiproblemi in maniera adattiva e dinamica, assicurando il rilascio dei deliverable con il maggior valore di business possibile.

Per non far sempre apparire tutto bello e facile, è bene sottolineare comunque che, per voce dei suoi stessi creatori (Ken Schwaber e Jeff Sutherland), Scrum va considerato:

  • Leggero;
  • Semplice da comprendere;
  • Difficile da padroneggiare;

Essendo un framework metodologico, all’interno di SCRUM possono essere impiegati diversi processi, strumenti & tecniche per gestire progetti dal più semplice al più complesso.

Nelle prossime “puntate” cercheremo di riassumere, sempre in modo semplice, i principali ruoli della “mischia” e come si procede, anche con esempi pratici, nella “spinta” verso la meta.

E ora palla (ovale) al centro.

Article by Alessandro Borgogno

Utilizziamo i cookie per essere sicuri che tu possa avere la migliore esperienza sul nostro sito. Se continui ad utilizzare questo sito noi assumiamo che tu ne sia felice.