AGILE: Distribuire software funzionante, ancor prima della completezza della documentazione
Capire davvero le aspettative del cliente è indispensabile per lavorare bene
Chiunque sviluppi software, in ogni settore e contesto, sa 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'abbiamo 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 abbiamo imparato dai numerosi confronti con i 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.
L’approccio AGILE ci insegna infatti che per poter raccogliere le informazioni necessarie alla realizzazione di un software è fondamentale porre le domande corrette.
Nel caso di prima, per esempio, 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 realizza.
Altra 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 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: a chiunque sarebbe piaciuto studiare sapendo prima quali sarebbero stati gli esercizi del compito in classe poiché in quel caso il risultato non sarebbe potuto che essere eccellente.
Allora perché rischiare il fallimento di un progetto quando predisporre il successo richiede semplicemente l'adozione di un facile strumento alternativo?
Massimo risultato con il minimo sforzo. Come si fa a dire di no?