Vediamo quale sia l’approccio agile allo sviluppo del software e vediamo quali siano i limiti e gli approcci che c’erano prima. Prima praticamente avevamo quasi sempre la metodologia a cascata e questa ha mostrato i limiti più importanti. Una metodologia rigida, i risultati sono visti solamente alla fine, grande produzione di carta e documentazione, rischio di poca soddisfazione per il cliente, tutti quanti i requisiti ci vogliono all’inizio, ma almeno il 20-50% cambia durante il progetto e inoltre il 45-65% dei requisiti non sono usati. Sul campo si è sperimentato che i cambiamenti ci sono e avere un modello molto rigido non aiuta nello sviluppo. Slide 4 Chaos Report 2011-2015 che fa una analisi dei progetti software e fa vedere le problematiche, le criticità e il tasso di successo. Notiamo che praticamente col Waterfall riusciamo ad avere un discreto successo solamente per progetti definiti come “piccoli”.

Le metodologie agili sono partite da un confronto tra 17 esperti nello Utah che una volta, andando a sciare, cercarono di risolvere alcuni problemi di sviluppo del software. Capirono che lo sviluppo fosse diverso da tutti gli altri e non si potessero andare ad usare metodolgie di sviluppo classiche. Viene definito come la produzione software come attività creativa e i lavoratori sono definiti come “lavorati di conoscenza”, non siamo operai come nel film Tempi Moderni. E’ importante anche l’aspetto umano per cui i dev si confrontino tra di loro e con il cliente. Alla fine è uscito fuori un manifesto che propone 4 punti:

1. molto importante curare le interazioni tra i componenti del team, il cliente
2. il software funzionante è più importante della documentazione → l’obiettivo è il software non la doc
3. la collaborazione col cliente è più importante di un contratto. Non facciamo un contratto e poi software solamente alla fine
4. rispondi ai cambiamenti piuttosto che rimanere incollati al piano; non incaponirsi a seguire il piano

Le metodologie tradizionali davano molta enfasi ai processi, alla documentazione, ai contratti e ai piani. Il metodo agile non butta via quello che c’era prima, ma dice solamente di fare attenzione riguardo allo sviluppo. Sposta il focus su temi diversi. Ci sono associati anche 12 principi:

1. è importante sicuramente andare a soddisfare il cliente, è importante quello. Non mi interessa se sto cambiando piano, perché è importante solamente quello. Fagli vedere software in esecuzione
2. dare il benvenuto ai cambiamenti dei requisiti anche alla fine dello sviluppo. Questo non è banale perché magari succede spesso alla fine. Fa anche un po’ arrabbiare in un certo senso, però dobbiamo essere pronti a questo genere di cose. Si capisce la sua utilità quando tutto è in funzione di andare a soddisfare il cliente.
3. Frequenti rilasci del software, tutto in tempi stretti tipo 2 settimane.
4. I dev dovrebbero lavorare insieme giornalmente con quelli del commerciale. In una azienda chi sviluppa e il commerciale si era visto che questi ultimi hanno il rapporto col cliente, ma con un scollamento tra le due parti interne.
5. Bisogna andare a costruire un ambiente in cui si riesce a tenere le persone motivate. Ci sono persone a cui piacciono più o meno consciamente le sfide, altri invece no. La cosa difficile è capire come trattare i propri dipendenti in tal senso per cercare di tenere tutti tranquilli/ben motivati.
6. suggeriscono interazioni faccia a faccia, non mandare mail su mail perché sono strazianti a volte
7. Il cliente vuole vedere il software funzionante e questo è un metro di progresso del nostro progetto.
8. Sostenibilità in termini di ritmi di lavoro. Non fare crunch time e periodi di lazyness totale.
9. attenzione alla eccellenza tecnica. Viene suggerito di stare al passo di stare al passo con la tecnologia.
10. semplicità, come arte di massimizzare la quantità di lavoro non fatto. Cerchiamo di sfrondare tutte le attività inutili.