Ecco un esempio di sviluppo software agile rispetto al waterfall:
Prendiamo una banca che ha bisogno di aggiornare il software che usa. Spendono molte ore di lavoro per scrivere requisiti molto dettagliati per ogni possibile eventualità. Quando li hanno scritti, li passano agli sviluppatori che li interpretano e li codificano. Si incontrano ogni tanto per discuterne e tutti tornano alle loro scrivanie a lavorare da soli. Quando arriva il momento di implementare, il project manager scopre che quello che hanno costruito non era esattamente quello che ci si aspettava perché hanno costruito quello che hanno capito ma la comprensione era sbagliata.
Prendiamo ora la stessa Banca che lavora in Agile e che deve aggiornare lo stesso software. Prima di scrivere una parola di documentazione, si riuniscono e fanno un brain storming di idee. Stanno letteralmente tutti in piedi e discutono su cosa avranno bisogno di costruire. Mentre discutono, creano storie di come l'utente interagirà con il sistema. Scrivono queste storie dell'utente e poi definiscono quali sono i criteri per ogni funzionalità che sono venuti fuori. Fanno questo ripetutamente e quando tutti hanno finito hanno capito cosa deve essere costruito. Il codice viene costruito 2 settimane alla volta e controllato per assicurarsi che sia corretto prima di passare a costruire altro. La documentazione è scritta come la raccolta delle storie dell'utente insieme ad una guida su quali sono i cambiamenti. Quando il progetto è finito, hanno realizzato ciò che ci si aspettava.
Sembra che l'agile abbia funzionato meglio.
Non dico che l'agile risolva tutto o che i progetti software non possano fallire anche con l'agile, ma il potere di comunicare è molto forte e aiuta veramente i team agili più che in qualsiasi altra metodologia di sviluppo.
Per maggiori informazioni sulla scrittura delle user stories leggi questo articolo, controlla anche questo articolo: Cos'è l'Agile Software Development.