Cosa ha cambiato lo sviluppo software?

Snowbird, nello Utah, è un posto improbabile per organizzare una rivoluzione del software. A circa 25 miglia da Salt Lake City, Snowbird non è certo la Silicon Valley; non è noto per i climi soleggiati e temperati, per i centri di innovazione tecnologica o per un surplus di imprenditori sempre entusiasti. Ma è qui, incastonato tra le montagne dalle cime bianche di una stazione sciistica, che un gruppo di ribelli del software si è riunito dal 11 al 13 febbraio 2001 per inquadrare e firmare uno dei documenti più importanti della storia della sua industria 4.0, una sorta di Dichiarazione di Indipendenza per la programmazione.

Questo piccolo ritiro di tre giorni aiutò a modellare il modo in cui gran parte del software viene immaginato, creato e distribuito e, forse, come funziona il mondo.

Rappresentanti di Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming e altri simpatizzanti della necessità di un’alternativa ai pesanti processi di sviluppo software guidati dalla documentazione hanno unito le loro menti ed i loro sforzi, ciò che è emerso è stato il Manifesto Agile “Sviluppo software”.

Sarebbe difficile trovare un raduno più grande di anarchici organizzativi, quindi ciò che è emerso da questo incontro è stato davvero simbolico: un Manifesto per lo sviluppo agile del software, firmato da tutti i partecipanti. L’unica preoccupazione per il termine agile è venuta da Martin Fowler (un inglese per chi non lo conosce) che ha ammesso che la maggior parte degli americani non sapeva come pronunciare la parola “agile”.

Cosa potrebbe mai andare storto?

Le preoccupazioni iniziali di Alistair Cockburn riflettevano i primi pensieri di molti partecipanti. “Personalmente non mi aspettavo che questo particolare gruppo di agiliti fosse mai d’accordo su qualcosa di sostanziale.” Ma sono stati condivisi anche i suoi sentimenti post-incontro: “Parlando per me, sono felice della frase finale del Manifesto. Sono rimasto sorpreso dal fatto che gli altri siano apparsi ugualmente felici dalla frase finale. Quindi siamo stati d’accordo su qualcosa di sostanziale. “

Chiamandosi “The Agile Alliance”, questo gruppo di pensatori indipendenti sullo sviluppo del software, e talvolta concorrenti tra loro, ha concordato il Manifesto per lo sviluppo agile del software che potete trovare nell’articolo 12 Principi della Metodologia Agile di questo Blog.

Ma mentre il Manifesto fornisce alcune idee specifiche, c’è un tema più profondo che guida molti, ma non tutti, i membri dell’alleanza. Al termine della riunione di due giorni, Bob Martin ha scherzato sul fatto che stava per fare una dichiarazione “sdolcinata”. Ma sebbene venato di umorismo, pochi erano in disaccordo con i sentimenti di Bob: ci sentivamo tutti privilegiati a lavorare con un gruppo di persone che sostenevano un insieme di valori compatibili, un insieme di valori basati sulla fiducia e sul rispetto reciproci e sulla promozione di modelli organizzativi basati su persone, collaborazione e costruzione dei tipi di comunità organizzative in cui vorremmo lavorare. Fondamentalmente, credo che i metodologi agili si occupino davvero di cose “sdolcinate”, ovvero fornire buoni prodotti ai clienti operando in un ambiente che mette al primo posto le persone come la nostra risorsa più importante con i fatti e non solo con le parole. Quindi, in ultima analisi, il fulmineo aumento dell’interesse per le metodologie agili e talvolta delle tremende critiche riguarda le cose sdolcinate dei valori e della cultura.

Ad esempio, penso che alla fine l’uso e l’interesse per l’Extreme Programming si siano moltiplicati, non a causa della programmazione in coppia o del refactoring, ma perché, prese nel loro insieme, le pratiche definiscono una comunità di sviluppatori liberata dal bagaglio delle società dilbertesche. Kent Beck racconta la storia di un primo lavoro in cui stimava uno sforzo di programmazione di sei settimane per due persone. Dopo che il suo manager ha riassegnato l’altro programmatore all’inizio del progetto, ha completato il progetto in dodici settimane e si è sentito malissimo con se stesso! Il capo, ovviamente, ha arringato Kent su quanto fosse lento durante le seconde sei settimane. Kent, un po’ scoraggiato perché era un tale “fallimento” come programmatore, alla fine si rese conto che la sua stima originale di 6 settimane era estremamente accurata – per 2 persone – e che il suo “fallimento” era in realtà il fallimento del manager, anzi, il fallimento di la mentalità di processo “fissa” standard che affligge così frequentemente il nostro settore.

Questo tipo di situazione si verifica ogni giorno: il marketing, la direzione o i clienti esterni, i clienti interni e, sì, anche gli sviluppatori, non vogliono prendere decisioni di compromesso difficili, quindi impongono richieste irrazionali attraverso l’imposizione di regole aziendali . Questo non è solo un problema di sviluppo del software, si verifica in tutte le organizzazioni Dilbertesque.

Per avere successo nella nuova economia, per entrare in modo aggressivo nell’era dell’e-business, dell’e-commerce e del web, le aziende devono liberarsi delle loro manifestazioni di Dilbert di make-work e politiche arcane. Questa libertà dalle sciocchezze della vita aziendale attrae i sostenitori delle metodologie agili e spaventa i tradizionalisti. Francamente, gli approcci Agile spaventano i burocrati aziendali, almeno quelli che sono felici di spingere il processo per il bene del processo invece di cercare di fare il meglio per il “cliente” e fornire qualcosa di tempestivo e tangibile e “come promesso”, perché esauriscono le risorse posti dove nascondersi.

Metodologia agile o Anti-Metodologia?

Il movimento Agile non è anti-metodologia, infatti, molti di noi vogliono ridare credibilità alla parola metodologia. Vogliamo ristabilire un equilibrio. Abbracciamo la modellazione, ma non per archiviare qualche diagramma in un polveroso repository aziendale. Abbracciamo la documentazione, ma non centinaia di pagine di tomi mai mantenuti e usati raramente. Pianifichiamo, ma riconosciamo i limiti della pianificazione in un ambiente turbolento. Coloro che marchiano i sostenitori di XP o SCRUM o di qualsiasi altra Metodologia Agile come “hacker” ignorano sia le metodologie che la definizione originale del termine hacker.

L’incontro a Snowbird è stato incubato in una precedente riunione di sostenitori di Extreme Programming e alcuni “outsider”, organizzata da Kent Beck al Rogue River Lodge in Oregon nella primavera del 2000. All’incontro di Rogue River i partecipanti hanno espresso sostegno per un varietà di metodologie “Light”, ma non si è verificato nulla di formale. Nel corso del 2000 sono stati scritti numerosi articoli che facevano riferimento alla categoria dei processi “Light” or “Lightweight”. Alcuni di questi articoli si riferivano a “metodologie leggere, come Extreme Programming, Adaptive Software Development, Crystal e SCRUM”. Nelle conversazioni, a nessuno piaceva davvero il soprannome di “Light”, ma per il momento sembra rimanere.

Nel settembre 2000, Bob Martin di Object Mentor a Chicago, ha dato il via al prossimo incontro con un’e-mail; “Vorrei convocare una piccola conferenza (di due giorni) nel periodo da gennaio a febbraio 2001 qui a Chicago. Lo scopo di questa conferenza è riunire tutti i leader del metodo “Light” in una stanza. Siete tutti invitati; e io sarei interessato a sapere a chi altro rivolgermi.” Bob creò un sito Wiki e le discussioni infuriarono.

All’inizio, Alistair Cockburn intervenne con un’epistola che identificava il malcontento generale con la parola ‘Light’: “Non mi dispiace che la metodologia venga definita leggera, ma non sono sicuro di voler essere indicato come un leggero che partecipa a una riunione di metodologi “Light”. In qualche modo suona come un gruppo di persone leggere magre e deboli di mente che cercano di ricordare che giorno è.

Il dibattito più feroce è stato sulla location! Le possibili opzioni erano:

  • Chicago in inverno: freddo e niente di divertente da fare
  • Snowbird, Utah: freddo con cose divertenti da fare, almeno per coloro che sciano
  • Anguilla nei Caraibi: caldo e divertente, ma richiede tempo per arrivarci.

Alla fine, Snowbird e lo sci hanno vinto!

Ci auguriamo che il nostro lavoro insieme come Agile Alliance aiuti gli altri nella nostra professione a pensare allo sviluppo del software, alle metodologie e alle organizzazioni, in modi nuovi, più agili. Se è così, abbiamo raggiunto i nostri obiettivi.

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian MarickRobert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Posted

in

by

Tags: