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?
Tra una catena di Sant’Antonio, una proposta per un gruppo Facebook e un po’ di spam di routine oggi ho ricevuto questa storiella:
Un professore, prima di iniziare la sua lezione di filosofia, pose alcuni oggetti davanti a sé, sulla cattedra. Senza dire nulla, quando la lezione iniziò, prese un grosso barattolo di maionese vuoto e lo riempì con delle palline da golf. Domandò quindi ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.
Allora, il professore rovesciò dentro il barattolo una scatola di sassolini, scuotendolo leggermente. I sassolini occuparono gli spazi fra le palline da golf. Domandò quindi, di nuovo, ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.
Il professore, rovesciò dentro il barattolo una scatola di sabbia. Naturalmente, la sabbia occupò tutti gli spazi liberi. Egli domandò ancura una volta agli studenti se il barattolo fosse pieno ed essi risposero con un sì unanime.
Il professore tirò fuori da sotto la cattedra due bicchieri di vino rosso e li rovesciò interamente dentro il barattolo, riempiendo tutto lo spazio fra i granelli di sabbia. Gli studenti risero!
“Ora”, disse il professore quando la risata finì, “vorrei che voi consideraste questo barattolo la vostra vita. Le palline da golf sono le cose importanti; la vostra famiglia, i vostri figli, la vostra salute, i vostri amici e le cose che preferite; cose che se rimanessero dopo che tutto il resto fosse perduto riempirebbero comunque la vostra esistenza.”
“I sassolini sono le altre cose che contano, come il vostro lavoro, la vostra casa, l’automobile. La sabbia è tutto il resto, le piccole cose.”
“Se metteste nel barattolo per prima la sabbia”, continuò, “non resterebbe spazio per i sassolini e per le palline da golf. Lo stesso accade per la vita. Se usate tutto il vostro tempo e la vostra energia per le piccole cose, non vi potrete mai dedicare alle cose che per voi sono veramente importanti.
[...]
Un po’ come le feature marginali o addirittura inutili che occupano tempo e testa degli sviluppatori al posto delle core feature. Un po’ come assegnare sempre la priorità più alta ai task che promettono una conclusione più immediata tentati dalla possibilità di sembrare più produttivi.
Un po’ come rinunciare alla gallina oggi per l’uovo domani.
p.s. ho scoperto che odio la retorica un po’ new age delle catene di Sant’Antonio…
Un intervento di Gabriele Lana sulla mailing list XP nazionale mi convince oggi a pubblicare questa draft in agguato da qualche mese tra i miei post in sospeso.
Gabriele fa riferimento nella sua mail al rigore di un processo, all’autorità all’interno di un team e alle buone pratiche scrivendo:
Durante il primo stadio dell’apprendimento (di qualsiasi cosa) si
devono seguire delle regole per non farsi male e per non fare male,
non c’è molto spazio per la democrazia, se fossi sotto i ferri e ci
fosse un team di medici pronti ad operarti vorresti che per democrazia
vincesse il “per questa volta non ci laviamo le mani prima di
operare”?
Leggere queste righe mi ha fatto subito pensare che avevo intenzione da un po’ di parlare di buone pratiche e di processi di decisione nei gruppi facendo riferimento al dottor Ignác Fülöp Semmelweis, noto come il Salvatore delle madri. continue reading »
Un breve post per riassumere e condividere con te una riflessione che mi diverte in questi giorni.
Negli ultimi decenni i marchi più famosi hanno capito che può essere molto remunerativo mettere in atto il cosiddetto attitude branding ossia l’estensione della percezione pubblica del marchio – il brand – fino a rappresentare non più il solo prodotto inizialmente identificato ma un sentimento più ampio, talvolta spinto fino a costituire un sincero senso tribale di appartenenza. Ecco quindi che vediamo il marchio usato ora su un paio di scarpe, ora su un orologio e ora per dare il nome ad un campionato di calcio. In ogni senso, quindi, vediamo il logo trascendere il prodotto iniziale e rappresentare qualcosa di più astratto, un vero e proprio modo di essere. Se hai letto No Logo di Naomi Klein – o altri reportage simili – sai cosa sto cercando di comunicarti in breve: le grandi multinazionali non vendono più un prodotto – la scarpa – la cui riconoscibilità è garantita dal logo – accessorio; bensì vendono un’identità – il brand – utilizzando come supporto la scarpa – accessorio.
Bene, in questi ultimi tempi mi sto convincendo del fatto che un team agile non deve pensare di vendere semplicemente software. Mi sembra sempre più chiaro che un team agile debba acquisire una mentalità più alta in cui si senta elemento chiave di un processo che miri a consegnare manovrabilità, nel senso cirilliano del termine. Una mentalità che ponga la possibilità di cambiare direzione comeil vero prodotto.
Tutto questo si ottiene sicuramente partendo dal basso, da ogni riga di codice, non va dimenticato, mai. Ma, considerando che manovrare per il cliente significa reagire agli stimoli del mercato, il mantra di ogni team deve diventare questo: non consegno più un software – il prodotto – la cui manutenibilità è garantita da un design flessibile – accessorio; bensì vendo manovrabilità – il prodotto – utilizzando come supporto il software – accessorio.
E tu? Oggi consegnerai al tuo cliente righe di codice o manovrabilità?
Un post molto interessante di Jurgen Appelo mi ha ricordato un applet che avevo visto già alcuni anni fa, tangibile e lampante esempio dell’ordine che può emergere dal caos in base a poche regole ad un primo sguardo insufficienti a creare strutture tanto coese. La morale del post è: basta dirigere i progetti, i gruppi di lavoro, le situazioni complesse in base a regole da applicare caso per caso, cominciamo a definire solo dei vincoli e lasciamo che tutto si auto-organizzi. Cosa ha a che vedere con lo sviluppo agile tutto ciò?
Mi piace pensare, lavorare e scrivere questo blog in base ad un sano principio di multidisciplinarietà: amo stabilire ponti fra concetti apparentemente distanti, scovando pattern in giro e costruendo quelli che nella scienza delle reti vengono chiamati legamideboli tra piccoli mondi culturali. Oh parbleu!!! L’ho appena fatto! Beh, lo sto per rifare tirando in ballo Socrate. continue reading »
Uno sviluppatore con cui ho terminato oggi un’importante fase di un progetto web mi ha detto:
[...] Io diffido di chi propone un rimedio come panacea di tutti i mali. Nei progetti open source che vedo utilizzare i test automatici io vedo ancora liste di bug lunghissime.
Affermazione che equivale più o meno a dire:
Ritengo gli antibiotici un immenso bluff. Sono decenni che vengono impiegati e ci sono ancora milioni di malati in ogni parte del mondo
Ok, ci ammaliamo ancora tutti e ancora ovunque, ma rinuncereste agli antibiotici?
Gli antibiotici non ci regalano l’immunità totale, ma hanno abbattuto l’impatto dei batteri sulle nostre vite. I test automatici non sono una panacea, ma abbattono il tempo speso a fare debugging – che è sempre tempo perso, poiché non è passato a creare valore ma a verificarlo.
Nel corso dell’ultimo anno mi è capitato più di una volta di sentir parlare delle metodologie tradizionali – in contrapposizione a quelle agili – come di metodologie olistiche, in quanto imperniate sulla conoscenza completa dei requisiti di progetto.
Il ricordo della lettura di bellissimi libri anni fa e un breve ripassino sul concetto di olismo su Wikipedia rinforzano le mie diffidenze su questo uso del termine olistico.
Mi spiego: olismo significa concepire un sistema nella sua globalità e studiarne il comportamento e le reazioni emergenti non solo dalle sue singole componenti ma anche – e soprattutto – dall’interazione tra le parti stesse. L’approccio riduzionista – in diversi ambiti della scienza e della filosofia – si oppone a quello olistico e promuove la riduzione di un ente, di un concetto o di una metodologia alle entità più elementari possibili. La tendenza della scienza classica e, quindi, anche dell’ingegneria classica è sempre stato proprio quest’ultimo: cercare di conoscere l’intimo dettaglio perdendo di vista l’insieme, perdere di vista la foresta contemplando l’albero.
Negli ultimi decenni la nascita di nuove discipline scientifiche come la scienza della complessità hanno posto al centro dell’attenzione la necessità per la comunità scientifica di saper abbracciare anche un approccio olistico.
Nello sviluppo agile una serie di pratiche manageriali o ingegneristiche cerca di regolamentare alcuni dettagli della vita di un progetto software producendo come risultato globale – epifenomeno, direbbero alcuni – un successo dipendente dalla sinergia di quelle pratiche.
In questo riconosco olismo. Nel ben tristemente noto tentativo di raccogliere tutte le specifiche di un progetto software in un unico documento iniziale riconosco riduzionismo.
![[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)
