Manifesto per lo Sviluppo Agile di Software
1 like813 views
Il manifesto per lo sviluppo agile di software, redatto da un gruppo di esperti nel 2001, promuove valori fondamentali come l'importanza delle persone e delle interazioni rispetto ai processi rigidi e alla documentazione eccessiva. Il documento sottolinea la necessità di adattarsi ai cambiamenti, consegnare software funzionante frequentemente e incoraggiare la collaborazione continua tra clienti e sviluppatori. In definitiva, il manifesto rappresenta una risposta alle pratiche tradizionali di sviluppo software, puntando a creare un ambiente più agile e reattivo.
![Storia del Manifesto
Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle
montagne dello Utah, diciassette persone si sono incontrate per
parlare, sciare, rilassarsi, cercare di trovare un terreno comune e,
naturalmente, mangiare. Il risultato è stato il Manifesto per lo
Sviluppo 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 relativa
documentazione.
Ora, un tale raduno di anarchici organizzati è difficile da tro-
vare, così, simbolicamente tutti i partecipanti si sono prestati a
sottoscrivere il Manifesto. L'unica preoccupazione riguardò l'uso
del termine “agile” e fu avanzata da Martin Fowler (un inglese,
per chi non lo conosce) che sottolineò come la maggior parte degli
americani non fosse in grado di pronunciarlo correttamente.
Le preoccupazioni iniziali di Alistair Cockburn riflettono i pen-
sieri di molti partecipanti. “Personalmente non mi aspettavo che
questo particolare gruppo di agilites riuscisse a concordare su
qualche punto fermo.” Ma anche i suoi sentimenti post-meeting
sono stati condivisi, “Parlando per me, mi rallegro per il fraseggio
finale [del Manifesto]. E mi ha sorpreso che anche gli altri ne sono](https://image.slidesharecdn.com/manifestoperlosviluppoagiledisoftware-160110161001/85/Manifesto-per-lo-Sviluppo-Agile-di-Software-4-320.jpg)
Manifesto per lo Sviluppo Agile di Software
- 2. Manifesto per lo Sviluppo Agile di Software AA.VV.
- 3. © 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, Giordano Scalzo, Lorenzo Urbini e Fabio Armani. Tutte le informazioni su Manifesto for Agile Software Development. Versione EPUB a cura di Federica Dardi ISBN: 978-88-503-1196-5 ~ Seguici su Twitter @apogeonline
- 4. Storia del Manifesto Tra l'11 e il 13 febbraio 2001, in una stazione sciistica sulle montagne dello Utah, diciassette persone si sono incontrate per parlare, sciare, rilassarsi, cercare di trovare un terreno comune e, naturalmente, mangiare. Il risultato è stato il Manifesto per lo Sviluppo 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 relativa documentazione. Ora, un tale raduno di anarchici organizzati è difficile da tro- vare, così, simbolicamente tutti i partecipanti si sono prestati a sottoscrivere il Manifesto. L'unica preoccupazione riguardò l'uso del termine “agile” e fu avanzata da Martin Fowler (un inglese, per chi non lo conosce) che sottolineò come la maggior parte degli americani non fosse in grado di pronunciarlo correttamente. Le preoccupazioni iniziali di Alistair Cockburn riflettono i pen- sieri di molti partecipanti. “Personalmente non mi aspettavo che questo particolare gruppo di agilites riuscisse a concordare su qualche punto fermo.” Ma anche i suoi sentimenti post-meeting sono stati condivisi, “Parlando per me, mi rallegro per il fraseggio finale [del Manifesto]. E mi ha sorpreso che anche gli altri ne sono
- 5. 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, ha approvato all'unanimità il Manifesto per lo Sviluppo Agile di Software. Ma mentre il Manifesto fornisce alcune idee specifiche, vi è un tema più profondo che spinge molti, anche se non tutti, i membri dell'alleanza. Al termine della riunione di due giorni, Bob Martin ironizzava sul fatto che stavano per fare una dichiarazione “molle”. Sebbene tinta di humor, questa sua espressione ha creato qualche disaccordo poiché tutti ci sentivamo dei privilegiati per poter lavorare con un gruppo di persone che teneva in grande considerazione 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à organizzativa in cui vorremmo lavorare. In definitiva, credo, che il cuore della metodologia agile sia veramente roba “molle”, ma in accezione positiva, perché consegna buoni prodotti ai clienti, operando in un ambiente che non si limita a parlare di “persone come il nostro asset più importante”, ma in realtà “agisce” come se le persone fossero l'unico aspetto importante, dimenticando definitivamente la parola “asset”. Quindi, in ultima analisi, il fulmineo interesse e, a volte, la critica più dura alla metodologia Agile è proprio il suo cuore “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
- 6. liberata dal bagaglio delle società “Dilbertiane”. Kent Beck rac- conta la storia di un lavoro per il quale stimò un impegno di sei settimane per due programmatori. Ma all'inizio del progetto il suo capo riassegnò il secondo programmatore, e Kent completò il pro- getto in dodici settimane, sentendosi malissimo con se stesso! Il capo, naturalmente, lo rimproverò per la lentezza. Kent, si sentì un “fallimento” come programmatore, ma poi finalmente capì che la 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, e non la persona. Questo tipo di situazione è estremamente comune quando un reparto produttivo non riesce a prendere le decisioni forti, e re- agisce alle pressioni imponendo richieste irrazionali attraverso l'istituzione di strutture di potere aziendale. Non si tratta sem- plicemente di un problema legato allo sviluppo software, tocca tutte le organizzazioni “Dilbertiane”. Per avere successo nella nuova economia, per muoversi aggres- sivamente verso l'era dell'e-commerce, nel Web, le aziende devono 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 (potete usare la parola m**da in un documento professionale) dei tradiz- ionalisti. Francamente, l'approccio Agile spaventa i burocrati aziendali o almeno quelli che sono felici di sostenere il processo per amore del processo perché sono a corto di posti in cui nascon- dersi invece di fare di fare del loro meglio per il “cliente” per fornire qualcosa di tangibile e tempestivo, “come promesso”. 6/24
- 7. 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 per archiviare 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 un ambiente turbolento. Coloro che etichettano i sostenitori del mar- chio di XP (Extreme Programming) o SCRUM o di una qualsiasi delle 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 primavera del 2000. In quella occasione i partecipanti espressero il sostegno per una serie di metodologie “light”, ma niente di più. Nel corso del 2000 una serie di articoli sono stati scritti e pubblicati facendo riferimento ai “processi light”. Un certo numero di questi articoli accennava a “metodologie light” facendo riferimento a Extreme Programming, Adaptive Software Development, Crystal, e Scrum. A nessuno è mai piaciuta molto l'etichetta “light”, ma sembrava funzionare 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 è quello di mettere tutti i leader del metodo light in una stanza. Siete tutti 7/24
- 8. 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 sono sicuro di voler essere indicato come un partecipante leggero a un incontro leggero. Suona un po' come un branco di persone magre e stupide che cercano di ricordare che giorno è.” Il dibattito più feroce comunque era sulla location! C'era seria preoccupazione perché a Chicago in inverno è freddo e non c'è ni- ente di divertente da fare. Montagne dello Utah: freddo, ma con cose 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 prossima volta. Ci auguriamo che il nostro lavoro insieme come Agile Alliance possa aiutare altre persone che svolgono la nostra professione a pensare allo sviluppo del software, alle metodologie e alle or- ganizzazioni, in un modo nuovo e più agile. Se così sarà, allora considereremo raggiunti i nostri obiettivi. Jim Highsmith, per la Agile Alliance ©2001 Jim Highsmith 8/24
- 9. I firmatari Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cock- burn, 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. Riguardo agli autori | Visualizza i firmatari | Diventa un firmatario
- 10. Manifesto per lo Sviluppo Agile di 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 e gli strumenti. • Il software funzionante più che la documentazione esaustiva. • La collaborazione col cliente più che la ne- goziazione dei contratti. • Rispondere al cambiamento più che seguire un piano. Ovvero, fermo restando il valore delle voci a destra, consideri- amo più importanti le voci a sinistra.
- 11. Primo 1 La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
- 12. Secondo 2 Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
- 13. 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.
- 14. Quarto 4 Committenti e sviluppatori devono lavorare insieme quotidia- namente per tutta la durata del progetto.
- 15. Quinto 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.
- 16. Sesto 6 Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all'interno del team.
- 17. Settimo 7 Il software funzionante è il principale metro di misura di progresso.
- 18. Ottavo 8 I processi agili promuovono uno sviluppo sostenibile. Gli spon- sor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
- 19. Nono 9 La continua attenzione all'eccellenza tecnica e alla buona pro- gettazione esaltano l'agilità.
- 20. Decimo 10 La semplicità - l'arte di massimizzare la quantità di lavoro non svolto - è essenziale.
- 21. Undicesimo 11 Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
- 22. Dodicesimo 12 A intervalli regolari il team riflette su come diventare più ef- ficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
- 23. Indice Storia del Manifesto I firmatari Manifesto per lo Sviluppo Agile di Software Primo Secondo Terzo Quarto Quinto Sesto Settimo Ottavo Nono Decimo Undicesimo Dodicesimo