AGILE: Distribuire un software funzionante, ancor prima della completezza della documentazione

Tutti coloro i quali sviluppano software, in ogni settore e contesto, sanno che non è possibile consegnare un’applicazione assolutamente perfetta, così come chiunque progetti edifici non può garantire in modo assoluto che la sua opera non venga spazzata via da un evento naturale anomalo.

In ogni progetto complesso, però, il primo criterio per poterne valutare il successo è quello di confrontare il risultato di ogni fase con l’aspettativa stabilita nel momento di avvio del progetto stesso.

Nel caso del software, questa immediatezza tra ciò che ci si aspetta e ciò che si ottiene non esiste, poiché è strettamente dipendente da una serie di  fraintendimenti relativi alle aspettative del cliente, che generano situazioni quali: “ma io pensavo che…”, oppure “io avevo capito che…”. Un caso indicativo l’ho riscontrato proprio l’altro giorno sentendo parlare un commerciale con uno dei suoi clienti: “Come vuoi che sia il tuo sito internet?” è stata la domanda. Ed il cliente: “Beh, vorrei che fosse bello e funzionale”.

Ciò che ho imparato dai numerosi confronti con i miei clienti per capire cosa stessero cercando, ed offrire loro la soluzione migliore, è che tanto più la domanda è generica, altrettanto lo sarà la risposta. Questo significa maggior incertezza progettuale, e conseguentemente maggiore probabilità di non offrire ciò che il cliente si aspetta.

Da quando mi sono avvicinato all’AGILE ho capito molto bene che, per poter raccogliere le informazioni necessarie alla realizzazione di un software, è fondamentale porre le domande corrette. Nel caso di prima, secondo la mia esperienza, una domanda che avrebbe generato maggiori informazioni e minor incertezza avrebbe potuto essere: “Cosa ti aspetti di ottenere dal sito internet, e a chi vuoi che si rivolga?” .
Probabilmente sarebbe stata la prima di una serie di altre domande sempre più precise, mirate a comprendere al meglio l’immagine di ciò che il cliente ha in mente.

Questo approccio si rivela particolarmente vantaggioso, non solo perché si riesce ad ottenere un’idea più chiara di ciò che immagina il cliente, ma anche perché ci consente di investigare su quali saranno i criteri che il cliente utilizzerà per valutare il risultato del progetto.

Comprendere e definire i criteri di valutazione del cliente ci permette di creare i test prima di cominciare a realizzare il software, e quindi di poterlo verificare dopo ogni fase e dopo ogni iterazione.

Con l’obiettivo di consegnare un software funzionante, che in questo caso significa corrispondente alle aspettative e che soddisfa i criteri di adeguatezza del cliente. Inoltre nel caso in cui ci si accorga della presenza di un bug o di un’anomalia, è possibile intervenire in modo decisamente più tempestivo, poiché è più facile localizzare dove questo si realizzi.

Inoltre, cosa apparentemente banale ma assolutamente non scontata, creare i test di verifica prima di realizzare il software aiuta nella definizione  contrattuale  delle funzionalità e delle grandezze attraverso le quali misurare il risultato con il cliente stesso in base alle sue priorità, eliminando ogni possibilità di fraintendimento.

Un’ulteriore ma utilissima indicazione riportata nell’approccio AGILE è quello di prevedere dei rilasci frequenti, creati esattamente con questo modello di verifica preventiva: rilasci di moduli consecutivi, parziali e periodici, che prevedono il confronto con il cliente, e che permettono di proseguire il progetto basandosi su sezioni di lavoro consolidate ed approvate.  Un metodo alternativo e vantaggioso, che consente di essere certi che ogni singolo componente rilasciato sia funzionante e coerente con le richieste del cliente, indicazione importante per poter amplificare ancor di più l’effetto di aderenza degli sviluppi con le sue aspettative.

Per riassumere, credo che a chiunque sarebbe piaciuto studiare sapendo prima quali sarebbero stati gli esercizi del compito in classe, e in quel caso il risultato non sarebbe potuto che essere eccellente.

Allora perché rischiare il fallimento di un progetto, quanto predisporre il successo richiede semplicemente l’adozione di un facile strumento alternativo?

Come dire: massimo risultato, con il minimo sforzo. Come si fa a dire di no?

Marco Merlino

Questo articolo è pubblicato anche su   

  Clicca quì per leggerlo