Mi sono imbattuto poco fa in questo interessante post di Robert ‘Uncle Bob’ Martin a proposito dell’impoverimento del termine “agile” nell’industria del software. Meglio ancora, l’articolo parla della sovrageneralizzazione di termini il cui significato è invece limitato, per quanto profondo, per quanto vasto, e al tipico sfruttamento pubblicitario che ne consegue. È ovvio – considerato l’autore del post – che il nucleo di questa argomentazione sia posto sull’attributo agile, particolarmente discusso, celebrato o condannato in questi ultimi anni.
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.
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.
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.
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.
Ieri l’XPUG Roma si è riunito per il primo incontro di questo 2010. È stato un incontro molto positivo per diversi fattori:
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.
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.
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?
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.
Una vecchia amica mi invia il mio oroscopo odierno, che recita:
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.
Forse ricordi un vecchio post su un mio burndown chart. Le 5 iterazioni visualizzate in quel grafico col tempo sono diventate 10 poi 12 poi 13… Anche il burndown chart è cresciuto con noi e uno dei motivi per cui è da un po’ che non scrivo qui sul mio blog è che sto scrivendo un case study – grafici compresi – su questo progetto da cui, come al solito, ho imparato tantissimo.
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!
Sono un po’ ossessionato in questi giorni, ma oh… che ci posso fare? Rieccomi qui a scrivere di giochi e strategia dei conflitti.
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?
Tra le pagine del gruppo SIAgile, che da poco più di un anno si impegna a diffondere la cultura agile nella Svizzera italiana, mi è capitato di incontrare il concetto di Behavior Driven Development, inteso come un estensione del Test Driven Development che arriva perfino a mettere in secondo piano gli stessi test, pur conservandone – inevitabilmente direi – l’indispensabile utilità.
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?
Molto spesso mi accade di stabilire collegamenti tra discipline diverse, abitudine che non necessariamente produce risultati interessanti per tutti, ma che sicuramente – per circolarità tautologica – io stesso trovo stimolanti. L’ultima occasione deriva dalla lettura di un libro molto interessante dal titolo Il gene egoista di Richard Dawkins. Grazie a questo libro infatti ho definitivamente deciso di affrontare l’analisi di alcuni aspetti dei progetti di sviluppo software alla luce di alcuni concetti nati in altri contesti: la teoria dei giochi, i memi e il darwinismo. Oggi voglio iniziare dal libro appena finito, ma svilupperò questi temi perlomeno lungo tutto il 2010. A proposito: buon anno!continue reading »
Ultimamente sono sempre più disposto a ridurre gli strumenti di gestione dei progetti in cui lavoro ad un singolo spreadsheet, liberandomi da tutti i software di cui si è soliti discutere nella comunità agile e non. Anzi, a dire il vero, la mia migrazione non si sta compiendo verso fogli elettronici qualunque ma verso quelli offerti da Google Docs, per via del forte incentivo che essi stessi costituiscono alla condivisione di informazioni e alla collaborazione.
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!
In questo post – scoperto via Alberto – si espongono i vantaggi dello UX design – la progettazione della user experience – condotto in coppia. Noto interessanti analogie con uno dei miei primi post…
Scherzi a parte, il passaggio che mi è piaciuto di più è questo![[del.icio.us]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/digg.png)
![[Facebook]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/facebook.png)
![[Google]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/google.png)
![[LinkedIn]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/linkedin.png)
![[Technorati]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/technorati.png)
![[Email]](http://www.sviluppoagile.it/wp-content/plugins/bookmarkify/email.png)
