Post on 16-Apr-2017
Manifesto per lo Sviluppo Agile diSoftware
AA.VV.
© 2001, gli autori questa dichiarazione può essere copiata libera-mente in qualsiasi forma, purché sia inclusa questa stessa nota.
Traduzione italiana di Jacopo Romei, Claudio Perrone, GiordanoScalzo, Lorenzo Urbini e Fabio Armani. Tutte le informazioni suManifesto for Agile Software Development.
Versione EPUB a cura di Federica Dardi
ISBN: 978-88-503-1196-5
~
Seguici su Twitter @apogeonline
Storia del Manifesto
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sullemontagne dello Utah, diciassette persone si sono incontrate perparlare, sciare, rilassarsi, cercare di trovare un terreno comune e,naturalmente, mangiare. Il risultato è stato il Manifesto per loSviluppo Agile di Software (Agile Software Development Mani-festo). I rappresentanti di Extreme Programming, Scrum, DSDM,Adaptive Software Development, Crystal, Feature-Driven Devel-opment, Pragmatic Programming e altri simpatizzanti erano ac-comunati della necessità di trovare un'alternativa ai pesanti pro-cessi di sviluppo software e alla stesura della relativadocumentazione.
Ora, un tale raduno di anarchici organizzati è difficile da tro-vare, così, simbolicamente tutti i partecipanti si sono prestati asottoscrivere il Manifesto. L'unica preoccupazione riguardò l'usodel termine “agile” e fu avanzata da Martin Fowler (un inglese,per chi non lo conosce) che sottolineò come la maggior parte degliamericani non fosse in grado di pronunciarlo correttamente.
Le preoccupazioni iniziali di Alistair Cockburn riflettono i pen-sieri di molti partecipanti. “Personalmente non mi aspettavo chequesto particolare gruppo di agilites riuscisse a concordare suqualche punto fermo.” Ma anche i suoi sentimenti post-meetingsono stati condivisi, “Parlando per me, mi rallegro per il fraseggiofinale [del Manifesto]. E mi ha sorpreso che anche gli altri ne sono
stati altrettanto deliziati. Così siamo giunti a un accordo su qual-cosa di sostanziale.”
Proclamatasi “Agile Alliance”, questo gruppo di pensatori indi-pendenti , professionisti del software, e talvolta concorrenti, haapprovato all'unanimità il Manifesto per lo Sviluppo Agile diSoftware.
Ma mentre il Manifesto fornisce alcune idee specifiche, vi è untema più profondo che spinge molti, anche se non tutti, i membridell'alleanza. Al termine della riunione di due giorni, Bob Martinironizzava sul fatto che stavano per fare una dichiarazione“molle”. Sebbene tinta di humor, questa sua espressione ha creatoqualche disaccordo poiché tutti ci sentivamo dei privilegiati perpoter lavorare con un gruppo di persone che teneva in grandeconsiderazione valori basati sulla fiducia, il rispetto e la pro-mozione di modelli organizzativi basati “sulla persona”, la col-laborazione e la costruzione di quel tipo di comunità organizzativain cui vorremmo lavorare. In definitiva, credo, che il cuore dellametodologia agile sia veramente roba “molle”, ma in accezionepositiva, perché consegna buoni prodotti ai clienti, operando inun ambiente che non si limita a parlare di “persone come il nostroasset più importante”, ma in realtà “agisce” come se le personefossero l'unico aspetto importante, dimenticando definitivamentela parola “asset”. Quindi, in ultima analisi, il fulmineo interesse e,a volte, la critica più dura alla metodologia Agile è proprio il suocuore “molle” di valori e di cultura.
Per esempio, penso che alla fine, il metodo Extreme Program-ming ha visto crescere consensi e interesse perché, nel complesso,spinge verso la definizione di una comunità di sviluppatori
5/24
liberata dal bagaglio delle società “Dilbertiane”. Kent Beck rac-conta la storia di un lavoro per il quale stimò un impegno di seisettimane per due programmatori. Ma all'inizio del progetto il suocapo riassegnò il secondo programmatore, e Kent completò il pro-getto in dodici settimane, sentendosi malissimo con se stesso! Ilcapo, naturalmente, lo rimproverò per la lentezza. Kent, si sentìun “fallimento” come programmatore, ma poi finalmente capì chela sua stima iniziale di 6 settimane era accurata e che il suo “falli-mento” era in realtà un fallimento del suo capo, e della mentalitàdi quei manager che mettono al centro dell'industria il processo, enon la persona.
Questo tipo di situazione è estremamente comune quando unreparto produttivo non riesce a prendere le decisioni forti, e re-agisce alle pressioni imponendo richieste irrazionali attraversol'istituzione di strutture di potere aziendale. Non si tratta sem-plicemente di un problema legato allo sviluppo software, toccatutte le organizzazioni “Dilbertiane”.
Per avere successo nella nuova economia, per muoversi aggres-sivamente verso l'era dell'e-commerce, nel Web, le aziendedevono sbarazzarsi delle loro manifestazioni e dell'eredità di Dil-bert. Questa libertà dalla vacuità della vita aziendale attrae sos-tenitori di metodologie agili, e spaventa quella begeeber (poteteusare la parola m**da in un documento professionale) dei tradiz-ionalisti. Francamente, l'approccio Agile spaventa i burocratiaziendali o almeno quelli che sono felici di sostenere il processoper amore del processo perché sono a corto di posti in cui nascon-dersi invece di fare di fare del loro meglio per il “cliente” perfornire qualcosa di tangibile e tempestivo, “come promesso”.
6/24
Il movimento Agile non è anti-metodologia: molti di noi vogli-ono ridare credibilità alla parola “metodologia”. Vogliamo ristabi-lire un equilibrio. Abbracciamo la modellazione, ma non perarchiviare qualche diagramma in un repository aziendale. Abbrac-ciamo la documentazione, ma non centinaia di pagine mai ag-giornate e raramente utilizzate. Facciamo programmi, non im-provvisiamo, ma riconosciamo i limiti della pianificazione in unambiente turbolento. Coloro che etichettano i sostenitori del mar-chio di XP (Extreme Programming) o SCRUM o di una qualsiasidelle altre metodologie Agili come “hacker” sono ignoranti di en-trambe le metodologie e della definizione stessa del termine.
La riunione del febbraio 2001 era stata incubata da una preced-ente tra i sostenitori di Extreme Programming, e alcuni“outsider”, organizzato da Kent Beck in Oregon nella primaveradel 2000. In quella occasione i partecipanti espressero il sostegnoper una serie di metodologie “light”, ma niente di più. Nel corsodel 2000 una serie di articoli sono stati scritti e pubblicati facendoriferimento ai “processi light”. Un certo numero di questi articoliaccennava a “metodologie light” facendo riferimento a ExtremeProgramming, Adaptive Software Development, Crystal, e Scrum.A nessuno è mai piaciuta molto l'etichetta “light”, ma sembravafunzionare per il momento.
Nel settembre del 2000 Bob Martin della Object Mentor in Ch-icago, iniziò il successivo giro di incontri con un'email. “Mi pi-acerebbe convocare una piccola conferenza (due giorni) tra gen-naio e febbraio a Chicago. Lo scopo di questa conferenza è quellodi mettere tutti i leader del metodo light in una stanza. Siete tutti
7/24
invitati e sarei interessato a sapere chi altri dovrei contattare”.Bob creò una Wiki e stimolò la discussione.
All'inizio, Alistair Cockburn intervenne con una lettera che rias-sumeva il malcontento generale la la parola “light”: “Non mi dis-piace che la metodologia venga definita leggera, ma non sonosicuro di voler essere indicato come un partecipante leggero a unincontro leggero. Suona un po' come un branco di persone magree stupide che cercano di ricordare che giorno è.”
Il dibattito più feroce comunque era sulla location! C'era seriapreoccupazione perché a Chicago in inverno è freddo e non c'è ni-ente di divertente da fare. Montagne dello Utah: freddo, ma concose divertenti da fare, almeno per chi scia, come Martin Fowler.Anguilla nei Caraibi: caldo e divertente, ma richiede tempo per ar-rivare. Alla fine, vinsero le montagne e lo sci; tuttavia alcune per-sone, come Ron Jeffries, esigono un posto più caldo la prossimavolta.
Ci auguriamo che il nostro lavoro insieme come Agile Alliancepossa aiutare altre persone che svolgono la nostra professione apensare allo sviluppo del software, alle metodologie e alle or-ganizzazioni, in un modo nuovo e più agile. Se così sarà, alloraconsidereremo raggiunti i nostri obiettivi.
Jim Highsmith, per la Agile Alliance©2001 Jim Highsmith
8/24
I firmatari
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cock-burn, Ward Cunningham, Martin Fowler, James Grenning, JimHighsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland,Dave Thomas.
Riguardo agli autori | Visualizza i firmatari | Diventa unfirmatario
Manifesto per lo Sviluppo Agiledi Software
Stiamo scoprendo modi migliori di creare software, sviluppan-dolo e aiutando gli altri a fare lo stesso. Grazie a questa attivitàsiamo arrivati a considerare importanti:
• Gli individui e le interazioni più che i processi egli strumenti.
• Il software funzionante più che la documentazioneesaustiva.
• La collaborazione col cliente più che la ne-goziazione dei contratti.
• Rispondere al cambiamento più che seguire unpiano.
Ovvero, fermo restando il valore delle voci a destra, consideri-amo più importanti le voci a sinistra.
Primo
1
La nostra massima priorità è soddisfare il cliente rilasciandosoftware di valore, fin da subito e in maniera continua.
Secondo
2
Accogliamo i cambiamenti nei requisiti, anche a stadi avanzatidello sviluppo. I processi agili sfruttano il cambiamento a favoredel vantaggio competitivo del cliente.
Terzo
3
Consegnamo frequentemente software funzionante, con ca-denza variabile da un paio di settimane a un paio di mesi, prefer-endo i periodi brevi.
Quarto
4
Committenti e sviluppatori devono lavorare insieme quotidia-namente per tutta la durata del progetto.
Quinto
5
Fondiamo i progetti su individui motivati. Diamo lorol'ambiente e il supporto di cui hanno bisogno e confidiamo nellaloro capacità di portare il lavoro a termine.
Sesto
6
Una conversazione faccia a faccia è il modo più efficiente e piùefficace per comunicare con il team ed all'interno del team.
Settimo
7
Il software funzionante è il principale metro di misura diprogresso.
Ottavo
8
I processi agili promuovono uno sviluppo sostenibile. Gli spon-sor, gli sviluppatori e gli utenti dovrebbero essere in grado dimantenere indefinitamente un ritmo costante.
Nono
9
La continua attenzione all'eccellenza tecnica e alla buona pro-gettazione esaltano l'agilità.
Decimo
10
La semplicità - l'arte di massimizzare la quantità di lavoro nonsvolto - è essenziale.
Undicesimo
11
Le architetture, i requisiti e la progettazione migliori emergonoda team che si auto-organizzano.
Dodicesimo
12
A intervalli regolari il team riflette su come diventare più ef-ficace, dopodiché regola e adatta il proprio comportamento diconseguenza.
Indice
Storia del Manifesto
I firmatari
Manifesto per lo Sviluppo Agile di SoftwarePrimoSecondoTerzoQuartoQuintoSestoSettimoOttavoNonoDecimoUndicesimoDodicesimo