C’è sempre un momento nel quale nella mente avviene uno switch, quando una cosa che prima non capivi, non vedevi, improvvisamente ti appare chiara.

Nel mio percorso di avvicinamento ad Agile il cambio di paradigma è avvenuto su questa slide.

La chiamano “Agile Value Proposition” perché in effetti racchiude la proposta di valore che Agile fa a chi decide di adottare questo approccio allo sviluppo.

  • Business Value
  • Visibilità
  • Rischio
  • Adattabilità

Business Value

Il metodo tradizionale per sua natura non porta valore al cliente finale se non alla fine. Si decide cosa/come sviluppare, si iniziano le varie fasi di analisi, sviluppo, test, ecc… per poi consegnare tutto il valore alla fine, ahimé con i consueti misunderstanding fra quello che s’era detto di fare all’inizio e quello che in realtà è stato consegnato alla fine.

Una delle promesse di Agile è invece quella di consegnare valore di frequente. E per farlo ha dovuto strutturare dei team cross-funzionali (per evitare gli handover fra dipartimenti), ha dovuto spingere molto sui test automatici di vario tipo (non c’è più la mega fase di test alla fine), ha introdotto il concetto di refactoring come un valore (non si fa più codice perfetto e lungimirante da subito) ed ha dovuto creare le iterazioni, alla fine delle quali si rilascia sempre qualcosa al cliente finale, per davvero.

È chiaro quindi che il valore massimo si esprimerà alla fine, o comunque in una major release, ma il delivery sul cliente c’è da subito, o almeno quando le prime funzionalità possono essere unite in un Minimun Viable Product.

Visibilità

Mi ricordo sempre 2 episodi. Il primo: un programmatore che per 2 mesi mi teneva un progetto in ostaggio pronto al 99%, ma del quale non si poteva vedere nulla. Il secondo è quello del prete dell’oratorio che, da ragazzi, durante l’allestimento di uno spettacolo, alla vista del nostro palco pieno di strumenti, impianto audio, luci, dopo 4-5 ore di montaggio ci diceva “non sento ancora nulla”. Per il committente la visibilità è importante.

Nell’approccio tradizionale si dialoga molto con il cliente all’inizio, nella stesura della documentazione e nella sua validazione: è fondamentale farlo perché si decide cosa e (a volte anche) come si svilupperà. Poi ci si immerge letteralmente come un sottomarino, scomparendo dagli occhi di tutti: cliente, committente, PM, stakeholder. È normale, perché la modalità di sviluppo non consente di avere niente di “ispezionabile”: non c’è niente da vedere fino alla fine, quando finalmente il tutto riemerge, viene testato e messo in produzione.

Invece in Agile la visibilità verso il cliente è un fattore cardine, è una promessa che la software house fa al committente: “sviluppiamo con metodologie agili affinché tu possa ispezionare costantemente il nostro lavoro, per consentirti di godere a pieno dei vantaggi della business agility”. Per questo alla fine di ogni iterazione c’è un momento formale durante il quale si tocca con mano il prodotto, lo si vede funzionare davvero. Non solo: dato che va davvero in produzione ad ogni iterazione, si può decidere di farlo testare al cliente, di far testare ad un gruppo ristretto una beta version, di rilasciare una versione di prova sul mercato, un prototipo per raccogliere feedback e orientare gli sviluppi futuri.

Rischio

Che rischi ci sono in un progetto software? Fondamentalmente sono tutti quegli accadimenti che possono portare forti ritardi al progetto (integrazioni fra le componenti, incompatibilità non previste, costruzione delle piattaforme di produzione, ecc..) oppure eventi che possano rendere nullo il progetto (cambiamenti importanti di mercato, evoluzione della domanda non prevista dalle specifiche).

Lo sviluppo tradizionale ha rischi molto alti fino alle fasi finali perché posticipa l’integrazione fra le componenti, i test e la costruzione delle piattaforme di produzione alla fine, tutte fasi con un alto livello di incertezza; inoltre, fissando i requisiti all’inizio si porta con sé il grande rischio che durante il tempo dello sviluppo il mercato si sia evoluto, impedendo tuttavia il rilascio di una versione del prodotto minima per poter comunque raccogliere feedback.

Agile invece riduce il rischio fin già all’inizio perché anticipa tutte le varie fasi di integrazione e di costruzione delle infrastrutture alla fine di ogni sprint. Il rischio ovviamente non si azzera da subito perché ci saranno altre integrazioni da fare, altre componenti da sviluppare. Ma alla fine di ogni iterazione il rischio si mitiga un po’.

Adattabilità

Bellissima la definizione di agilità di wikipedia: “L’agilità o scioltezza è la capacità di cambiare in modo efficiente la posizione o la direzione del corpo in modo efficiente e efficace…”, che mi sentirei anche di paragonare alla capacità di adattamento.

È nell’essenza di Agile consentire ad un prodotto in sviluppo di potersi facilmente adattare. A cosa? Ai cambiamenti di mercato, alle richieste del committente, ai cambiamenti di standard, a qualsiasi cosa in un mondo così complesso come quello dello sviluppo software possa cambiare da un giorno all’altro. Il progetto software è fluido, prende la forma desiderata (alla fine è solo codice) e non è più un monolite difficilmente modificabile.

Alcune frasi epiche del mondo agile riguardo all’adattabilità:

  • “turn on a dime for a dime“: la promessa che Agile fa alle aziende che ne fanno propria la cultura di poter fare una inversione a U (radicale) su un progetto talmente stretta da girare intorno ad una moneta da 10 cents, al costo di 10 cents (con costi molto bassi)
  • “inspect and adapt“, ovvero l’obiettivo congiunto della product review e della retrospettiva: analizziamo cosa abbiamo fatto con il committente, guardiamo come l’abbiamo fatto con il team e capiamo come adattare (in caso di bisogno) il nostro lavoro, il nostro backlog nella prossima iterazione.

Purtroppo lo sviluppo tradizionale non lascia grandi margini sull’adattabilità: si può lavorare sul progetto e modificarlo soltanto all’inizio, quando si stende la documentazione dettagliata. Dopo quella fase, a sviluppo iniziato, nulla può essere adattato se non a costi altissimi in termini di tempo.

Per riassumere

Lo sviluppo software con metodologie agili consente di consegnare valore al cliente fin da subito, garantendo al committente estrema trasparenza e costante visibilità sul prodotto sviluppato, riduzione del rischio di bucare la deadline, possibilità di adattare in corsa lo sviluppo per qualsiasi esigenza possa emergere con costi molto bassi.