Agile: Quando?

Riassumiamo brevemente benefici e qualche costo delle metodologie agili.

Flessibilità

Negli ultimi anni hanno preso sempre più campo le metodologie cosiddette "agili" nell’ambito dello sviluppo software.

Tra gli altri motivi, queste metodologie sono sempre più applicate perché permettono molta più flessibilità delle metodologie più "classiche", basate su un approccio più lineare e con minor possibilità di correzione di rotta, quindi in pratica affrontano il problema delle correzioni in corso d’opera.

In cosa consiste l’agile?

Riassumendo molto, le metodologie agili partono dal presupposto che il cliente sia il miglior giudice del prodotto e quindi cercano di fargli avere con la maggior frequenza possibile prototipi e versioni pre-rilascio con l’intenzione di modificarle in base alla sua valutazione; siccome il cliente ha in mano continue versioni del software parziale, l’agile richiede anche test intensivo e possibilmente automatizzato, in modo da non presentare continuamente prodotti bacati.

L’agile costa?

Ovviamente tutto ha un costo, ed anche la adattabilità agile ha un costo intrinseco finale, a prescindere dal fatto che sia davvero necessaria, vale quindi la pena di chiedersi quando e come introdurre queste metodologie porti davvero un valore aggiunto.

Ad esempio immaginiamo la fatica di dover coinvolgere periodicamente il cliente mostrandogli il prodotto per raccogliere il suo feedback e quindi riallineare periodicamente il gruppo che sviluppa: In un processo lineare nessuno di questi due costi esiste.

Quali problemi affronta l’agile?

I problemi per cui nel corso dello sviluppo si va incontro a cambiamenti frequenti e quindi conviene usare l’agile si rispecchiano in una distanza tra il "cosa e come si deve fare" acquisito nella fase iniziale del progetto e quello che si ha in fase finale di rilascio, spesso distante, principalmente per:

• Cattiva comunicazione: Pure e semplici incomprensioni, uso di significati differenti per le stesse parole o errori verbali, che portano a requisiti errati rispetto alle vere esigenze dei clienti.
• Mancanza di tempi e fondi: Può succedere che tempi e fondi preventivati siano insufficienti (in questo caso si è verificato un errore di stima del software) o che i budget siano invece ridotti in corso d’opera, richiedendo quindi di tagliare o adattare il software in alcuni punti.
• Mancanza di feedback: Il cliente non può o non è interessato a dare il suo parere sul software prima che sia completamente pronto. Questo punto non è di per se fonte di errore ma amplifica grandemente il costo di qualunque cambiamento perché lo sposta dalle fasi di analisi e implementazione alla fase di integrazione e rilascio.
• Requisiti instabili: Spesso per motivi di evoluzione del business il cliente chiede modifiche in corso d’opera, che dunque fanno differire il software da quello pensato inizialmente, altre volte il cliente aveva già delle esigenze ma non se ne è reso conto fino al momento di valutare il software.

Conclusioni

Da questa breve panoramica si deduce immediatamente in che condizioni l’agile risulti più utile e possa portare un maggiore valore aggiunto: Quando i requisiti possono cambiare.

Sintetizzando in modo estremo, se abbiamo già tutti i requisiti del software all’inizio e per qualche motivo siamo certi della loro correttezza, totalità e immutabilità, l’agile non ci serve, anzi ci fa perdere tempo e denaro; altrimenti possiamo iniziare a considerarlo e vedremo in altri articoli quando e come sia più appropriato.