importa è soddisfare il cliente, consegnando del software che sia per lui di valore, e consegnarlo subito, a cicli brevi, per farlo verificare quanto prima.
3. Consegniamo frequentemente software funzionante, con cadenza variabile, preferendo i periodi brevi.
4. Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
5. Fondiamo i progetti su individui motivati. Diamo loro l'ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.
7. Il software funzionante è il principale metro di misura di progresso.
8. I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
9. La continua attenzione all'eccellenza tecnica e alla buona progettazione esaltano l'agilità.
10. La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.
11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza. 26
Questi punti si possono riassumere in quattro principi fondamentali:
le persone e le interazioni sono più importanti dei processi e degli strumenti (ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto) e, a partire dalla motivazione e dal giusto supporto agli individui, si può arrivare al risultato finale previsto;
è più importante avere software funzionante che documentazione (bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna
mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile);
bisogna collaborare con i clienti, possibilmente faccia a faccia, oltre che rispettare il contratto (la collaborazione diretta offre risultati migliori dei rapporti contrattuali), in quanto il focus è il valore per il cliente ed il feedback più importante è quello del cliente, quindi è necessario lavorare a suo fianco e comunicare al fine di non perdere tempo nello sviluppo di feature che non hanno valore per lui;
bisogna essere pronti a rispondere ai cambiamenti oltre che aderire alla pianificazione (quindi il team di sviluppo dovrebbe essere pronto, in ogni momento, a modificare le priorità di lavoro nel rispetto dell'obiettivo finale). Se lo scenario di progetto è in evoluzione continua, lavorare con tempi brevi consente di percepire e soprattutto reagire meglio al cambiamento. 26, 27
Figura 9 - Struttura di un progetto con approccio agile
I modelli di Agile Software Development si proponevano dunque di velocizzare la realizzazione dei deliverable, sfruttando un approccio iterativo ed evolutivo con cicli di miglioramento incrementale dell’output e osservando il prodotto maturare in corso d’opera.
A partire da questi principi basilari, i modelli agili furono rivisti ed adattati con i giusti accorgimenti alla gestione della progettazione di altri prodotti oltre ai software ed in un secondo momento all’intera organizzazione aziendale, andando a formare la famiglia di metodologie famosa come Agile Project Management.
Questo approccio vuole quindi quasi ripensare il modo di concepire l’azienda, abbracciando una soluzione di flessibilità ed assecondando il cambiamento, al fine di aumentare le probabilità di successo.
Il fatto di introdurre delle modifiche può facilmente comportare un aumento della mole di lavoro, quindi dei tempi e dei costi, dunque le soluzioni finali spesso prevedono una struttura sequenziale di gestione del progetto, le cui fasi vengono però gestite secondo uno sviluppo iterativo e/o per prototipi.
Questo genere di approccio alla gestione dei progetti, come quello sequenziale, ha dei vantaggi e degli svantaggi: operare in maniera incrementale consente al progetto di evolvere parallelamente ai requisiti del committente e quindi garantire quella flessibilità operativa che permette di rispondere rapidamente ad eventuali change orders. Inoltre le modalità di Agile Project Management tendono a dare molta importanza alle fasi di test e revisione e a favorire la collaborazione con fornitori e committente.
Parallelamente però un approccio di questo genere tende a concentrare l’attenzione su un orizzonte di breve termine, con il rischio di perdere, o quantomeno trascurare, la prospettiva di lungo periodo; inoltre, puntando fortemente sull’organizzazione autonoma del lavoro, è necessario che le risorse coinvolte siano altamente qualificate.
Il concetto di alleggerire le fasi di pianificazione e stesura della documentazione per aumentare l’attenzione sull’individuazione dei difetti e sul perfezionamento incrementale dei deliverable non deve sfociare nell’assenza di disciplina e in problemi
di gestione del progetto o di comunicazione con la committenza. In questo senso risulta fondamentale che il cliente si dedichi attivamente al progetto con il team di sviluppo, ma, se si deve interagire con molti clienti, ci si può trovare di fronte a punti di vista diversi ed in conflitto tra loro e aver limitato la documentazione può generare situazioni di incomprensioni e dubbi in un secondo momento.
Si può quindi pensare che il principio di ragionamento dietro questo approccio sia opposto a quello Waterfall: in questo caso, fissati a contratto budget e tempistiche del progetto, l’ambito di progetto e conseguentemente il deliverable rimangono flessibili e si adattano in funzione del massimo valore raggiungibile. 20
Dunque lo stesso modo di misurare le performance del team e il successo del progetto sono diverse: nel caso di un approccio tradizionale, un progetto di sviluppo di un prodotto è ottimo se rispetta budget e durata pianificati, mentre con i modelli agili un progetto può essere ritenuto di successo se il cliente (interno o esterno) riceve un deliverable aderente alle proprie richieste.
Figura 10 - Il "triplice vincolo" negli approcci Waterfall e agile
L’applicazione di una diversa metodologia di Project Management deve avvenire necessariamente tenendo conto della realtà operativa nella quale viene calata e delle caratteristiche dei deliverable. Un modello agile può, ad esempio, ben adattarsi ad un progetto di sviluppo di un software, facilmente riconducibile ad un processo incrementale per release, o ad un progetto di sviluppo di un nuovo prodotto di altro tipo, per cui esistono margini d’incertezza troppo ampi su alcune variabili ed è dunque difficile inizialmente pianificare al dettaglio la commessa. 28