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…
Ecco la presentazione che ha accompagnato il mio intervento venerdì scorso all’Italian Agile Day. Incredibilmente anche stavolta ce l’ho fatta in tempi che non richiedono la datazione al carbonio-14.
Ieri Italian Agile Day 2009. Grande affluenza, grande curiosità . Alle domande “chi usa qualche metodo agile?” poste al pubblico fra un talk e l’altro le mani alzate sono ancora poche, pochissime, ma l’alta partecipazione di ieri è un segnale di tendenza favorevole. E va bene così.
Della mia giornata – che lascia ancora una volta frustrato il desiderio di ubiquità – questi sono stati i momenti decisivi. continue reading »
Ringraziando la simpatica compagine di bit Time per la simpatia e l’accoglienza durante lo svolgimento di ITDevCon 2009, pubblico – stavolta entro i 6 mesi! – le slide che hanno accompagnato il mio intervento.
To benefit from engaging with users you have to be willing to change your idea. We’ve always encouraged founders to see a startup idea as a hypothesis rather than a blueprint. And yet they’re still surprised how well it works to change the idea.
Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.
Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum:
When someone is determined, there’s still a danger that they’ll follow a long, hard path that ultimately leads nowhere.
You want to push forward, but at the same time twist and turn to find the most promising path. One founder put it very succinctly:
Fast iteration is the key to success.
One reason this advice is so hard to follow is that people don’t realize how hard it is to judge startup ideas, particularly their own. Experienced founders learn to keep an open mind:
Now I don’t laugh at ideas anymore, because I realized how terrible I was at knowing if they were good or not.
You can never tell what will work. You just have to do whatever seems best at each point. We do this with YC itself. We still don’t know if it will work, but it seems like a decent hypothesis.
Mi sembra evidente che qui si alluda ad una serie di valori e principi ampiamente previsti ed esaltati nel compendio culturale dei metodi agili.Ci sono riferimenti alla capacità di accogliere il cambiamento, alla necessità di iterazioni strette per avere feedback frequente e via dicendo.
Il passaggio che mi ha colpito di più però è questo
Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that’s easy for you to solve. [...] Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum
Trovo importantissimo ribadire l’importanza di uno scope mutevoleche ci permetta di ridefinire il problema (il backlog, il lavoro da fare) dinamicamente per poi trovare soluzioni possibili. Un po’ come poter correggere la rotta di una nave deviata da una forte corrente. Un po’ anche come capire definitivamente la differenza fra indaffarato e produttivo.
![[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)
– le slide che hanno accompagnato il mio intervento.