Il punto centrale dei metodi agili è la massimizzazione del valore consegnato nell'unità di tempo. E' la continua ricerca di questo obbiettivo.
I valori assieme contribuiscono a questo obbiettivo
- feedback per sapere continuamente dove si è rispetto a dove si vuole andare
- coraggio per lasciare perdere le funzionalità inutili anche se "fighe" e per non aver paura di stabilire un rapporto di mutuo beneficio con il cliente (nei processi tradizionali invece di solito il rapporto è un rapporto di conflitto e "io vinco e tu perdi").
- semplicità per evitare fronzoli e portare avanti il minimo insieme di feature che realizza le aspettative del cliente, senza pretendere di fare un grande disegno di come sarà tutto il sistema (salvo poi buttarlo perché sconfessato dall'evoluzione delle cose)
- comunicazione perché la causa principale del fallimento di un progetto software è proprio un difetto di comunicazione tra le parti: all'interno del team, tra team e cliente, etc.
Poi cardine dei metodi agili sono l'approccio iterativo e incrementale.
Iterativo perché si vuole in poco tempo consegnare un sistema funzionante, anche se largamente incompleto. Incrementale perché si vogliono aggiungere pezzettini uno alla volta, lavorando per aggiunta di funzionalità (ovvero aggiunta di valore), e non per strati orizzontali come spesso accade nello sviluppo tradizionale, dove il progetto è consegnato "finito" dopo diversi mesi, e dove "finito" è solo una vaga e illusoria speranza del fornitore.
Il buon codice? C'entra, ma non è fondamentale: certo si fa forte accenno alla qualità senza compromessi: la qualità non è una variabile che si può usare per controllare i progetti sw.
E se consegni un progetto con codice "strafico" e di qualità eccelsa ma che non risponde alle esigenze del cliente, puoi definire il progetto un successo? NO