Nel lontanto 2001, precisamente in Febbraio, in una località sciistica nelle Wasatch mountains dello Utah, 17 guru dello sviluppo software tra i quali personaggi del calibro di Martin Fowler, si incontrarono per studiare nuove e migliori metodologie di sviluppo sotware. Da questo profiquo incontro nacque il famoso “Manifesto for Agile Software Development” che è stato il primo passo ufficiale verso un nuovo modo di gestire i progetti software. Nella nostra azienda seguiamo più o meno consciamente questi principi e devo dire che portano reali vantaggi soprattutto perchè principi semplici e abbastanza facilmente adottabili e dunque rappresentano il punto di incontro tra “non avere nessun processo”(totale anarchia, BIG BALL OF MUD) ed “avere un Processo” (lento, pesante, eccessivamente burocratico). Qui’ ne propongo una mia traduzione:
Il manifesto dello Sviluppo Software Agile
Diciassette anarchici concordano:
Stiamo portando alla luce metodologie migliori di sviluppo software facendolo in prima persona e aiutando altre persone a farlo. Attraverso questo lavoro siamo arrivati a concludere:
- Individui e interazioni piu’ che processi e strumenti.
- Software funzionante piu’ che una documentazione esauriente.
- Collaborazione con il committente piu’ che negoziazione contrattuale.
- Rispondere al cambiamento piu’ che seguire un piano prestabilito.
Significa che, nonostante apprezziamo gli aspetti che si trovano sulla destra di questi punti, diamo maggiore valore agli aspetti citati alla sinistra.
Seguiamo questi principi
- La nostra piu’ alta priorita’ deve essere quella di soddisfare i requisiti del committente attraverso precoci e continui rilasci di software di qualita’.
- Non bisogna temere il cambiamento dei requisiti, anche se avviene in fasi avanzate dello sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del committente.
- Consegnare software funzionante in maniera frequente: ogni paio di settimane o al piu’ ogni paio di mesi, con una preferenza per scale temporali ridotte.
- I committenti e gli sviluppatori lavorano insieme quotidianamente per tutta la durata del progetto.
- E’ necessario basare i progetti su individui motivati. Bisogna dare l’ambiente e il supporto di cui necessitano e avere fiducia in loro sul fatto che il lavoro verra’ portato a termine.
- Il piu’ efficiente ed efficace metodo per trasmettere le informazioni al team e per far si che esse circolino al suo interno e’ la conversazione faccia a faccia.
- Un software funzionante e’ la principale misura dello stato di avanzamento del progetto.
- I processi agili promuovono un’attivita’ di sviluppo software sostenibile. Promotori , sviluppatori ed utenti devono essere in grado di mantenere un passo costante a tempo indeterminato.
- La Semplicita – l’arte di massimizzare il lavoro non svolto – e’ essenziale.
- Le migliori architetture, i migliori requisiti e progetti emergono da team auto-organizzati.
- Ad intervalli regolari, il team deve riflettere su come diventare piu’ efficace, e dunque regola ed adegua il suo comportamente di conseguenza.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
