Funzionamento e successo della metodologia Agile per lo sviluppo software

Il Metodo Agile funziona?

La metodologia Agile, nata inizialmente per lo sviluppo di software, è largamente utilizzata per i benefici che riguardano le interazioni nel processo di sviluppo, la collaborazione necessaria nella fase di ingegnerizzazione, il contatto con il cliente o utente finale. L’obiettivo è sempre stato la ricerca di un modello per la pianificazione e l’implementazione di progetti che specificatamente potesse adeguarsi alle singole necessità.

Un approccio strutturato sull’analisi di questo strumento di supporto alla produzione dovrebbe analizzare criticamente i benefici e valutare concretamente il risultato migliorativo ottenuto. Se si volesse valutare per parametri questi benefici si potrebbe iniziare a discutere alcuni temi come efficienza dell’approccio, la soddisfazione degli utenti coinvolti, il rispetto degli obbiettivi organizzativi e quello che può essere definito come il team experience e per concludere percentuale di successo/insuccesso.

L’attenzione rivolta alle performance del progetto a volte oscurano l’attenzione da porre sulla percentuale di successo. Si può concordare sicuramente nel definire di “successo” un progetto che si sia svolto nei tempi, coti e abbia raggiunto gli obbiettivi posti, ma come questo può essere considerato nel caso in cui gli obbiettivi non siano in linea con le necessità del cliente finale? Un esempio può essere Kodak, la multinazionale specializzata nella produzione di apparecchiature per immagini, che non investendo su prodotti digitali è andata incontro a un netto declino della sua presenza sul mercato. Sicuramente negli anni la Kodak ha intrapreso progetti di sviluppo condotti e conclusi con successo, ma una scelta strategica sbagliata e una poca attenzione ai desideri del mercato non gli ha permesso di cogliere quanto il mondo della fotografia digitale stava sostituendo quello tradizionale.

La metodologia Agile nel panorama dello sviluppo software è in contrasto con il più classico approccio Waterfall: obbiettivi flessibili, interazioni con il cliente, congelamento del software il più tardi possibile, un approccio incrementale piuttosto che un processo standardizzato. Un approccio più standard utilizza come strada per il raggiungimento del risultato una sequenza logica di step predeterminati in un piuttosto rigido processo di sviluppo con potenziali conseguenze su: soddisfacimento del cliente e flessibilità.

Una domanda da porsi potrebbe essere: ma davvero i progetti Agile sono più di successo?

Ebbene, partendo dal presupposto che qualsiasi deviazione progettuale può nascondere rischi, le deviazioni all’interno di un piano di progetto non possono essere evitate, sia che il progetto segua un approccio tradizionale o evolutiva a cicli multipli. Non potendo evitare tali deviazioni quello su cui si può intervenire è la metodologia di gestione delle conseguenze derivanti da questa deviazione. Se si considera che in alcuni casi si arriva ad avere che 50% delle attività di design avviene in fasi diverse da quella di design, è evidente come non sia possibile blindare la fase di design appena essa viene conclusa nelle prime fasi del progetto bensì è opportuno prevedere un approccio che tenga conto di queste modifiche e le gestisca si come eccezioni ma senza impatti critici.

Lo sviluppo deve concentrarsi su alcuni punti cardini:

• Gli individui e le interazioni nel processo;
• Collaborazione del cliente;
• Risposta ai cambiamenti.

L’utilizzo di documentazione deve essere ridotta al minimo in modo da non pregiudicare la complessità e reattività ai cambiamenti. Ebbene i cambiamenti sono la sfida che deve essere supportata adeguatamente, e riguardano generalmente tre ambiti:

• Obbiettivi;
• Risorse e strumenti;
• Relazione con altri progetti e prodotti.

Bohem nel 1996 identifico in questi cambiamenti quelli che maggiormente si riscontrano nello sviluppo di progetti IT ed in particolare identifico alcune conseguenze di una documentazione troppo dettagliata:

• Dettagli superflui, che non descrivono il prodotto da rilasciare come prototipo, e quini poco utili.
• Ricchezza di contenuti superflui, perché non conoscendo il prodotto si tenta di inserire il “più possibile” nell’unico istante in cui possono essere descritte le specifiche.
• Mancanza di visibilità, ci si focalizza sulla conoscenza e visione attuale non prevedendo eventuali cambiamenti che potrebbero occorrere nel corso del progetto.

Bohem propone inoltre un approccio ciclico mostrato nella figura di seguito dove ogni attività viene ripetuta nel tempo e con diversi livelli di dettaglio.

È utile sottolineare che il metodo Agile non tralascia e non critica la pianificazione anticipata e complessiva, ma il concetto fondamentale su cui ci si concentra è sul rendere questa pianificazione non un ambiente immutabile, bensì strutturare il processo di sviluppo in modo che si possano prevedere interazione e cambiamenti derivanti da influenze esterni. In uno studio condotto da Koskela e Abrhaamsson nel 2004 si è rilevato come il 42% del tempo in un progetto con metodologia tradizionale si sia impiegato nella pianificazione tanto che si può arrivare ad ottenere che l’impatto negativo risultante dal troppo tempo speso per la pianificazione è uguale all’effetto negativo che si otterrebbe nel caso di scarso impegno in questa attività di pianificazione.

Punto essenziale e chiave di svolta è la comunicazione con i clienti, tanto che da uno studio condotto nel 2015 è emerso che incontri e riunioni di allineamento aiutano a ridurre la “confusione” sulle attività da svolgere e nell’ambito IT le parti da sviluppare.

Analizzando per mezzo di un confronto per punti è possibile elencare alcune differenze presenti tra una metodologia Agile e una tradizionale.

Successo del Progetto

 È necessario a tale riguardo definire preliminarmente cosa può essere definito un successo e cosa no. Normalmente la misura del successo si basa sul prodotto e come questo possa essere di sufficiente qualità tanto da poter produrre il beneficio e il risultato atteso o desiderato. Sorge a questo punto normale concordare su quale debba essere il punto in cui deve essere fatta questa misura. Tradizionalmente il lavoro del Project Manager si conclude quando il progetto è consegnato al cliente e viene tralasciata la parte più ampia ma naturalmente consecutiva dell’utilizzo del prodotto. Esiste una lacuna, che nel processo evolutivo è stata colmata, definendo per successo quel progetto che rende sodisfatto il cliente, sostenendo che può essere definito di successo un progetto che sebbene non abbia rispettato gli obbiettivi iniziali abbia reso il cliente soddisfatto. L’identificazione degli obbiettivi può creare delle distorsioni nel caso in cui gli obbiettivi iniziali non siano rispettati e il cliente finale sia soddisfatto, questo può essere evitato solo attraverso un processo attento a inizio del progetto nella stesura del documento di scope, tuttavia questa circostanza può accadere molto più probabilmente nel caso in cui utilizzando un approccio tradizionale, l’utente non viene coinvolto. Il caso contrapposto è quello in cui gli obbiettivi vengono raggiunti ma il cliente non è soddisfatto.

Certamente la definizione di un progetto di successo passa per la valutazione di tre dimensioni: Tempi, costi e obbiettivi. L’obbiettivo come si è visto ricopre parte fondamentale nella definizione di successo, ma normalmente abbiamo anche:

• Efficienza del Progetto = raggiungimento dei costi, degli obbiettivi e dei tempi prefissati
• Successo degli stakeholder = soddisfacimento delle aspettative derivanti dal progetto (la migliore definizione di successo).

Una valutazione più ampia di progetto di successo può essere indirizzata svolgendo un’analisi su tutte le fasi di sviluppo analizzando valore e sprechi. In questa ottica un progetto di successo può essere definito come una serie ordinata di attività volte al raggiungimento degli obiettivi, pianificando attività che aggiungono valore con la loro esecuzione e che riducono (o monitorano) eventuali sprechi che possono verificarsi. Con un overview su quali sono le barriere che ostacolano l’aggiunta di valore possiamo osservare che potenziali barriere riguardano sicuramente quelle presenti nella seguente immagine.