Archive for the 'Visione agile' Category

La competenza che porta semplicità: mission possible.

La semplicità, l’arte di massimizzare il lavoro non svolto è una virtù strettamente legata alla competenza delle persone. Prendendo in prestito alcuni concetti dall’economia e dalla fotografia, mi sarà possibile dimostrartelo, perlomeno qualitativamente.

In economia esiste il concetto di isoquanto, ovvero

l’insieme delle combinazioni efficienti di input che forniscono lo stesso livello di produzione.

Questa arcana formula equivale a dire che più di una combinazione di ingredienti potrà darmi lo stesso risultato valido. Un esempio classico è quello del rapporto tra lavoro e capitale: fermo restando l’obiettivo di una start-up (il nostro output), se ho molto capitale e poco know-how potrò finanziarne una senza scrivere una riga di codice – il concetto di venture capital; se ho invece molto know-how e poco capitale potrò chiudermi in un garage tutte le notti e lanciarmi nell’impresa nerd.
Per opportune coppie capitale/know-how le chance di successo saranno le stesse e queste, in un diagramma cartesiano, saranno disposte lungo linee continue.

Isoquanti su Wikipedia

Isoquanti (fonte Wikipedia)

Un concetto simile esiste in fotografia: date certe condizioni di luce, sulla carta infinite coppie tempo di scatto/apertura diaframma mi garantiscono una corretta esposizione del fotogramma. Potrò chiudere il diaframma ed esporre per tempi più lunghi o potrò aprire il diaframma ed esporre per tempi più brevi.
Anche in un diagramma tempo-apertura perciò tutte le coppie accettabili saranno disposte lungo una linea continua. Ognuna di quelle linee corrisponderà ad un valore ISO della pellicola e sarà analoga all’isoquanto (hai notato qualcosa?) di cui sopra.

Cosa cambia di isoquanto in isoquanto? E di in ISO in ISO?

Banale ed intuitivo: se io posso disporre dello stesso know-how e di più capitale di un concorrente, avrò, ceteris paribus più chance di successo; se io posso disporre di un sensor… ehm di una pellicola caratterizzata da maggiori ISO, avrò, in condizioni per esempio di scarsa illuminazione, la possibilità di usare tempi di esposizione rapidi a parità di apertura diaframma, evitando un indesiderato effetto mosso.

Bene. E la competenza?

Si parla spesso di scegliere nel design del software fra una soluzione quick & dirty e soluzioni più “lente” ma più pulite. Se ne parla sempre. Se ne parla troppo. Il compromesso che si stabilisce è fra la massimizzazione del lavoro non svolto oggi e quello non svolto domani, tra 3 mesi o tra un anno. È possibile però ipotizzare l’esistenza di uno sviluppatore molto bravo che riesca a trovare una soluzione gagliarda oggi e facilmente estendibile in futuro, riuscendo quindi ad operare scelte win-win che trascendano il compromesso apparentemente inevitabile.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Il diagramma qui sopra spero sia sufficientemente chiaro da farti afferrare che a parità di lavoro non svolto nel futuro – il nostro A, la competenza può farci saltare da una linea all’altra (le linee di isocompetenza? :-) ) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.

Ipotizzare l’esistenza di uno sviluppatore molto bravo è utile ai fini di questo post. Diventarlo, una missione impossibile. La parola d’ordine è competenza, la sua espressione più diretta il refactoring.

February 24 2011 | Visione agile | 4 Comments »

Manager e coach: ruoli e metafore da bar

Un brevissimo post per segnalarne a mia volta uno piuttosto interessante di Jurgen Appelo, uno dei miei blogger preferiti, sul differente ruolo del coach e del manager.

Non resisto alla tentazione di integrare con una metafora sportiva: in una squadra di football ci sono i manager e c’è il coach. Non credo debba aggiungere altro, secondo me messa così rende bene l’idea.

April 13 2010 | Visione agile | 3 Comments »

Il prezzo delle informazioni nei negoziati: l’etica dell’azzardo

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?

January 08 2010 | Visione agile | 5 Comments »

Il codice? È un fastidioso contrattempo.

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? :P

January 06 2010 | Visione agile | 8 Comments »

Sant’Antonio, le giuste priorità e ‘getting things done’

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…

September 10 2009 | Visione agile | 1 Comment »

La maggioranza ha sempre ragione. O no?

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 »

June 02 2009 | Visione agile | No Comments »

Consegnare manovrabilità, non più software.

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 come il 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à?

May 24 2009 | Visione agile | 2 Comments »

Requirements rodeo

Sai quando si parla di valore per l’utente, no? Hai presente quando senti uno sviluppatore lamentarsi del cliente poco lean, vero? Ti è capitato di pensare che sviluppatori e designers avessero molti problemi in comune, ricordi?

Bene.

Ora ridici un po’ su.

Saputo da Sketchin che l’ha saputo da Chiara Fox che l’ha saputo da AdFreak.

January 22 2009 | Visione agile | No Comments »

La vera agilità: passare dalle regole ai principi

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ò?

continue reading »

December 18 2008 | Visione agile | 2 Comments »

Socrate era agile

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 legami deboli tra piccoli mondi culturali. Oh parbleu!!! L’ho appena fatto! Beh, lo sto per rifare tirando in ballo Socrate. continue reading »

November 22 2008 | Visione agile | 6 Comments »

Next »