L’argomentazione di Martin parte da considerazioni sulla metafisica aristotelica per giungere a dichiarazioni concrete e molto chiare. I riferimenti alla storia della filosofia, devo ammettere, mi permettono di togliermi qualche soddisfazione: se anche luminari indiscussi del software internazionale come Martin li usano, allora io non devo aver fatto troppo male in passato! Scherzi a parte, il passaggio che mi è piaciuto di più è questo

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

Io ho smesso di usare la parola agile da qualche tempo. I miei ultimi clienti – perfino quelli che mi contattano perché non vedono l’ora di entrare nel mondo dei metodi agili – non mi sentono più pronunciarla. Combatto una lotta linguistica quotidiana per formulare concetti e frasi che aggirino queste 5 lettere in successione: a, g, i, l, ed e. Sono talmente preso da questa decisione ellittica da nutrire ormai forti dubbi anche sul nome di questo blog.

Perché questa avversione? Perché così all’improvviso? Per diversi motivi.

1. Una parola, usata depauperata del suo significato più denso, è come un magazzino pieno di componenti non usate, come un set di user story iniziate e non completate: è, in sostanza, una forma di waste. Trovo sia più importante per un team mettersi in marcia concretamente verso l’agilità che fregiarsi di tale caratteristica.
2. Persone che in buona o cattiva fede per motivi più o meno legati al marketing si vendono come agilisti e attribuiscono (anche) a passate collaborazioni con me la loro agilità mi danneggiano. Questo danno è vero qualunque sia il grado di evangelizzazione io abbia volontariamente apportato, questo danno è vero quantunque io abbia potuto ritenermi anche solo in grado di evangelizzare. E questo mi porta diritto al terzo punto.
3. Io sono agile? Io posso davvero ritenermi arrivato ad un punto degno di tale fatidico attributo? Domanda difficile da esaurire con una risposta netta e sai perché? Perché l’agilità non è un valore assoluto e con questo non intendo affatto abbandonarmi al più facile dei relativismi. Intendo invece stabilire una natura relativa a priori dell’attributo di agilità: come la sicurezza è definita solo in termini di “fare A è più sicuro che fare B” e non certo di “fare A è sicurissimo”, così l’agilità è definibile in termini di “fare X è più robusto rispetto al bisogno di produttività in un contesto mutevole rispetto a fare Y” ma non certo di “facciamo così, facciamo così tutti e facciamolo sempre perché funzionerà ovunque”!

Qualcuno diceva riguardo l’abuso di cose e concetti:

Inventato il martello, tutto diventa un chiodo

Ecco, io vorrei fare l’uso migliore del mio martello, ma solo sui chiodi.

I processi agili sono il mio mezzo, chiunque mai li chiamerà come vorrà. Cercare di essere produttivi nel mondo reale, questo è il mio unico obiettivo.

1. Il tema dell’incontro stesso è stato di per sé molto interessante: abbiamo iniziato a seguire il corso sul Test Driven Development di Piergiuliano Bossi. Di questo devo ringraziare Giorgio Vespucci dell’XPUG Roma che ha avuto questa ottima idea e ThinkCode Labs che ci ha concesso una licenza forfettaria per la visione in gruppo di 10 persone.
2. Con l’arrivo di nuove persone e una tanto attrattiva occasione abbiamo rischiato che la licenza per 10 non fosse sufficiente. Alla fine per fortuna (nostra) qualche influenza e qualche defezione dell’ultimo minuto hanno fatto il nostro gioco. Record di presenze comunque realizzato.
3. Detto record è solo l’ultimo episodio di un trend molto positivo innescato lo scorso anno – 12 mesi fa esatti. Nei pochi incontri del 2009 la presenza dei membri e quel sottile sentimento di partecipazione che va oltre la presenza fisica sono aumentati costantemente. Ottimo segno: l’intervento di defibrillazione di un anno fa sta portando i suoi frutti, col contributo di tutti. Abbiamo ancora tanto da invidiare a XPUG italiani ben più blasonati, ma è sempre più importante la tendenza dello stato, no?
4. Il penultimo incontro basato sui kata e quest’ultimo centrato sul corso TDD dimostrano che è possibile crescere se si portano contributi reali alla crescita culturale di tutti. L’introduzione di attività concrete è quanto basta a fare di un XPUG un XPUG sano. Detto questo, il limite è solo la fantasia. Nel frattempo, almeno per un po’, fra kata e corso TDD il programma degli incontri sembra essere già a posto

Ringrazio tutti gli appassionati partecipanti a questa piccola, sobria ma onesta avventura.

Bilancia (23 settembre – 22 ottobre) “Tutto quello che complica il lavoro”, scrive il poeta Jason Shinder, “fa parte del lavoro”. Se nei prossimi giorni incontrerai qualche ostacolo, tieni presente il suo consiglio. Se ti accorgi che stai pensando “Accidenti! Se non fosse per queste complicazioni farei molti più progressi”, prendi in considerazione la possibilità che le complicazioni non siano distrazioni, ma indizi essenziali. Che non siano affatto seccature insopportabili, ma stimoli utili che ti indicano dove stanno le vere opportunità.

Al di là dell’innegabile saggezza di Shinder riguardo cosa rientri nella definizione di lavoro, io trovo questo un consiglio validissimo per il mio lavoro di ogni giorno.

I problemi o sono indizi essenziali o sono opportunità. Certe volte giocano un ruolo doppio. In extreme programming due modi di catturare i problemi in una di queste modalità sono rispettivamente la retrospettiva ed il principio di opportunità.

La morale è sempre quella: meglio pianificare per il mondo vero in cui inevitabilmente accade quello che non vorremmo mai che assumere per ipotesi un mondo più controllabile di quanto persino la teoria ci autorizzi a sognare.

p.s. no, non mi piace l’astrologia

Nel frattempo però per fortuna c’è qualcun altro che scrive in tempi più rapidi. In questo post di Michael Marus sul blog dell’ICT-KM Program (CGIAR) trovi una sua retrospettiva e un mio piccolo intervento. Buona lettura e a prestissimo!

Kent Beck, papà di Extreme Programming, Test Driven Development e Manifesto Agile, per dirne giusto due o tre, in questo suo post fa una breve analisi del poker e ne trae una interessante lezione: nelle negoziazioni in cui non siamo al corrente di tutti i retroscena – caso peraltro abbastanza tipico – è possibile scambiare un certo valore in denaro con un corrispondente valore in informazioni.

Nel poker lo facciamo tutte le volte che vediamo il gioco avversario, raccogliendo informazioni sulle sue attitudini strategiche, o le volte in cui dichiariamo accettiamo il gioco in apertura – versando la quota opportuna nel piatto, per avere una prima impressione sul gioco in mano agli avversari. Nei negoziati a monte di tutti i nostri progetti lo facciamo tutte le volte che scopriamo di aver chiesto meno di quanto avremmo potuto, rinunciando quindi ad una certa quantità di denaro ora ottenendo informazioni sul vero valore del nostro lavoro preziose nel futuro.

È importante capire che tutto ciò è vero su entrambi i fronti del negoziato; anche il nostro cliente si chiede se il nostro lavoro vale la somma esborsata ed è pronto a sborsarne meno la volta successiva se scopre che il gioco non vale esattamente la candela. Questo significa che, a lungo termine, gli accordi, per mantenersi sostenibili, rischiano di attestarsi su valori più bassi del migliore possibile a causa dell’esborso necessario a raccogliere informazioni strategiche. Un po’ come dire che l’etica può essere pragmatica, no?

Ciò detto scritto, ti sembrano più ricchi accordi fatti in trasparenza o quelli fatti in un contesto opaco? Tu hai mai scoperto il bluff di un tuo cliente? E non hai mai bluffato? In quale caso il progetto ha avuto più successo?

Questa visione dei test come side effect di una tecnica di design – Test Driven Dev… Design – mi ricorda un mio vecchio post in cui sostenevo la maggiore importanza della manovrabilità delle specifiche rispetto al codice sorgente, relegando quest’ultimo al ruolo di mero strumento. Ovviamente la decentralizzazione del software che ho sostenuto in quell’occasione e in molte successive non ha nulla a che vedere con una presunta dequalificazione del codice stesso, che anzi, essendo espressione efficace dei nostri obiettivi, deve essere garantito di qualità eccellente. Nel corso dell’ultimo anno però ho potuto riflettere parecchio sul legame tra (sviluppo) software e user experience e sono quindi giunto ad una conclusione ulteriore, che integra quelle precedenti, estendendole.

Io credo che l’intero concetto di software sia in realtà un concetto collaterale. Noi sviluppatori vendiamo sì manovrabilità, ma non per ottenere software come prodotto finale. L’elevata qualità del nostro prodotto, il codice – che a questo punto scopriamo essere un semilavorato – serve infatti a garantire il successo del prodotto finito vero e proprio: la user experience. Il flusso di cassa diventa positivo nel momento esatto in cui il primo utente vive con successo l’esperienza che il nostro software contribuisce a realizzare. Non un solo attimo prima.

Una prova del 9 semplice semplice? Prova a sviluppare del software e a non farlo usare mai a nessuno. Pensi possa valere qualcosa?

Il libro è scritto in termini dichiaratamente divulgativi, ma aggirare i tecnicismi in questo caso non significa mai pagare in termini di rigore; l’autore spiega tutto in modo chiaro per chiunque ma senza mai perdere di vista quella che secondo me è il vero fulcro del libro stesso: il meccanicismo intelligente proprio dei sistemi complessi.

E qui, con questa visione al centro, scatta l’utilità del libro per noi professionisti o semplici appassionati di metodi agili. Il libro infatti insegna a ragionare in termini di effetti indiretti, di incentivi e disincentivi, di meccanismi ottusi in quanto tali ma capaci di interagire in modo adattivo e quindi (più) intelligente. Tutti concetti che hanno molto a che fare con i meccanismi in atto nei gruppi di persone che lavorano insieme. Anzi, rafforzo: tutti concetti implicati nella cooperazione tra individui con scopi collettivi da contrapporre o allineare a scopi privati.

Dawkins, per esempio, dedica buona parte del libro alla teoria dei giochi e alla trattazione del dilemma del prigioniero. Conoscevo già il dilemma e già quest’estate avevo abbozzato delle riflessioni al riguardo in relazione al rapporto cliente-sviluppatori e ad una sua modellazione più rigorosa dal punto di vista formale nonché all’utilizzo di questo modello per risolverne alcune criticità tipiche ben note ai più. La lettura di Dawkins mi ha definitvamente convinto della bontà dell’approccio e infatti, come spesso accade in caso di idee fertili, non risulta affatto inedito. Per esempio ad Agile2009, importante conferenza svoltasi a Chicago in agosto, Simon Bennett ha tenuto un talk esattamente su questo tema. Ottimo segno, mi piacerà approfondire.

Un altro concetto introdotto per la prima volta nella storia dell’umanità dallo stesso Dawkins con questo libro è quello di meme. Noti ormai alla massa, i memi sono stati concepiti da Dawkins per modellare in termini darwiniani i processi evolutivi culturali, separati da quelli biologici. L’analogia vuole che i memi stiano ai geni come la cultura umana stia agli ecosistemi. Ancora una volta Agile2009 ci fornisce indizi della bontà degli spunti che questo libro può offrire per lo sviluppo agile: Julian Everett presentò infatti in quell’occasione un talk su strategie decisionali basate su una concezione memica delle user story.

I tempi sembrano quindi maturi per integrare scienze socio-biologiche e ingegneria gestionale nella formalizzazione di  metodologie agili di management e sviluppo del software. Lo spazio di un solo post è poco sia per esaurire il tema che per essere davvero appaganti nei confronti di un volenteroso lettore arrivato fino a questo punto della lettura. A te, che generosamente hai letto fino a qui, prometto di tornare presto su questi temi. Una volta ancora, buon 2010!

Allora, però, penso anche che Google Wave potrebbe essere un ottimo strumento per gestire progetti se quello che ci interessa è l’aderenza più alta possibile del nostro stile di gestione al Manifesto Agile. Modellare infatti le interazioni fra i componenti umani di un team in modo il più possibile destrutturato – purché aggregato, storicizzato e usabile – mantenendo intatta la possibilità di integrare queste interazioni con informazioni CPU-generated – come i log SVN – credo sia infatti la chiave per un processo sufficientemente asciutto – diremmo lean – per essere adattato ad ogni contesto in modo vincente. Il principio di umanità di cui ho parlato in passato verrebbe sicuramente onorato.

Non so ancora se assocerei una wave ad un intero progetto o una wave ad ogni singola user story. La seconda possibilità mi sembra più promettente; immagino wave che iniziano con la data user story in cui vengono man mano inclusi wireframe, screenshot, user story, commenti, chat e magari un planning game e un log svn con dei plug-in ad hoc… Le possibilità mi sembrano tante, manca qualche riscontro empirico.

Cercherò di fare presto degli esperimenti con i più arditi tra i miei clienti e collaboratori. Appena ne saprò di più ti aggiornerò su queste pagine. Tu nel frattempo non fare il tirchio eh! Se sai qualcosa batti un colpo e facci sapere anche qui!

I metodi agili non possono funzionare con i clienti normali, da noi li usavamo già nel ‘98 e non sono realistici.

Fonte: xkcd

Dritta: occhio al 'title' della vignetta...