Archive for the 'Esperti' Category

Imparare ad imparare

Leggendo su indicazione del buon Stelio un articolo su Wikipedia relativo al metodo Montessori ho notato immediatamente, folgorato, un passaggio che riporto qui liberamente tradotto, riguardo gli elementi essenziali di un buon processo educativo:

  • Classi di età mista.
  • Attività a scelta dell’allievo all’interno di una ristretta gamma di opzioni.
  • Blocchi temporali di lavoro ininterrotto.
  • Un modello costruttivista o di scoperta, in cui gli allievi imparano i concetti lavorando materialmente in prima persona, piuttosto che per istruzione frontale.
  • Materiale didattico specializzato, sviluppato ad hoc.
  • Libertà di movimento nella classe
  • Un insegnante con padronanza del metodo

Beh, non posso fare a meno di notare come tutti questi punti possano essere tradotti, ricondotti, mappati con successo sulle metodologie agili e sui principi che ormai da 10 anni sostengo, pur con un approccio mutevole ed evolutivo, senza indulgere nella liturgia, nel cargo cult.

L’assunto fondamentale di questo mio articolo è semplice quanto basta per scriverlo in poche, pochissime parole: sviluppare un prodotto digitale è un processo di apprendimento.

Sulla base di questo assunto, rivediamo i punti esposti uno per uno:

  • La diversità come valore imprescindibile per la crescita – nel lungo termine – ed il successo dell’azione – nel breve. Raccogliere professionalità diverse in un team cross funzionale presenterà dei costi, certo, che saranno però ampiamente ripagati dalla robustezza dell’apprendimento del team stesso.
  • Ridurre il work in progress, focalizzare l’azione ma rinunciando a processi strettamente prescrittivi. Chiunque sappia cosa sia una kanban board – <rant>e vi assicuro che sono meno di quelli che ne parlano</rant> – sa che le caratteristiche fondamentali di questo strumento sono
    1. la limitazione della concorrenza
    2. la modalità di selezione autonoma del lavoro da svolgere sulla base di una coda di priorità e delle proprie competenze
  • Il timeboxing è un concetto antico, ausilio di qualsiasi processo cognitivo. Decenni e decenni prima che noti brand vegetali – ormai pericolosi anche da citare per motivi di copyright… – vedessero le prime luci, il metodo Montessori già affermava la necessità di non essere interrotti per intervalli protetti di tempo.
  • Il modello cognitivo di scoperta per eccellenza nella programmazione è il test driven development (TDD), vera e propria trasposizione del costruttivismo nel contesto virtuale del software. Procedere per tentativi incrementali di ipotesi, assemblaggio, validazione e pianificazione è infatti parte fondamentale della teoria costruttivista. Ma programmare è solo una parte dello sviluppare prodotti digitali! C’è anche l’interaction design e lo sviluppo del business model. E qui manteniamo un allineamento pazzesco con i principi costruttivisti se pensiamo alle tecniche tipiche del mondo UX (wireframe, prototipi…) e alla business model canvas utilizzata nel business model generation.
  • Continuous integration, user story, wireframe etc etc sono tutti artefatti creati appositamente per massimizzare il feedback cognitivo del team mentre questo impara sempre meglio cosa il mercato si attenda da lui.
  • Esaltazione della libertà di azione individuale, per massimizzare l’espressione del proprio valore, senza badare a sovrastrutture che non portano reale valore a nessuno degli stakeholder, purché sia chiaro a tutti cosa ci si attenda dai membri del team. Giacca e cravatta, sistemi operativi imposti, strumenti di sviluppo standardizzati, obbligo rigido di presenza in ufficio e altre inutili benché spesso scontate regolette sono solo una forma di spreco.
  • Un coach che sappia davvero cosa significhi sviluppo agile, agile UX, lean start-up senza diffondere versioni distorte delle metodologie che mettano a repentaglio la salute e la redditività del progetto. Per sgombrare il campo da sospetti di marchetta – lettore maliziosetto che non sei altro :-) – mi affretto ad aggiungere:
    1. A seconda del livello di maturità di un team il coaching potrà essere anche auto-condotto dal team, senza la presenza fisica (e pagata) di un coach
    2. Lungi da me qui fare un appello all’ortodossia! Le metodologie devono evolvere e deve regnare la serenità di poter sperimentare, ma solo dopo aver capito quale strada vecchia si sta lasciando per la nuova.

Concludo senza dimenticare di celebrare il volto che, senza che gli italiani si rendessero bene conto, finiva negli anni ‘90 sulla banconota delle mille lire e per ottimi motivi! Questa recente scoperta probabilmente mi porterà a capire meglio i dettagli del lavoro di Maria Montessori e magari a scoprirne di nuovi utili al mio lavoro.

Mi porterà ad imparare insomma. ;-)

July 19 2013 | Esperti and Uncategorized | 3 Comments »

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 »

Dei dubbi, delle certezze, della crisi e della crescita.

Dopo aver affrontato il tema dello stile di coaching con Federico Galassi, Stefano Leli e Gabriele Lana durante la cena pre-IAD 2010 e risollecitato da un recente, recentissimo thread della mailing list SIAgile, in cui la discussione avviata da Pino riguardo i pattern SOLID ci ha portato a discutere di crescita personale, evangelizzazione, didattica costruttiva, didattica distruttiva, regole e principi ho pensato di scrivere qualcosa su questo sempre più avaro blog. Alla fine ruota tutto attorno alla questione: è utile imparare a seguire regole ed affermarle e riaffermarle in seno ad un percorso (auto)didattico? In questo post intenderò mostrarti perché a mio avviso la risposta sia un SOLIDo[1] “sì”.

continue reading »

December 08 2010 | Esperti | 18 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 »

Giocare cambiando le regole a partita iniziata

Nell’ultimo articolo di Paul Graham intitolato What startups are really like leggo

10. Change Your Idea

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 mutevole che 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.

November 12 2009 | Esperti | No 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 »

Virtù emergente: continuous integration

Una riflessione snella, senza pretese, un divertissement estivo. Sarò breve, seguimi.

La teoria della complessità ci insegna che comportamenti complessi possono emergere da sistemi costituiti da agenti semplici in relazione tra di loro in virtù di regole semplici. Craig Reynolds può introdurti a questi concetti sul web con spettacolari sciami virtuali.

Bene. Poniamo ora un team soggetto a queste due regole:

  1. ogni sviluppatore – ogni coppia – deve fare commit del codice solo a test verdi sulla sua macchina
  2. ogni sviluppatore – ogni coppia – deve prendersi carico della risoluzione dei conflitti che incontrerà al momento del proprio commit

È evidente che la probabilità di avere conflitti nel codice tende a 1 col passare delle ore; i commit degli altri sviluppatori infatti avranno sempre maggiori possibilità di introdurre linee di codice non integrabili automaticamente con le nostre. Questo dato sommato al fatto che eventuali conflitti su poche righe sono comunque preferibili a conflitti su interi moduli del nostro software fanno sì che ogni sviluppatore sarà quindi fortemente incentivato a fare frequenti commit che, in virtù della prima regola, non violeranno la stabilità della repository. Abbiamo quindi introdotto con queste due semplici regole una delle pratiche più preziose del contesto agile: la continuous integration.

Spesso introdurre pratiche nuove nei team può essere complicato anche quando il vantaggio che ne deriverebbe può essere facilmente dimostrato. Individuare regole molto semplice e deburocratizzanti può essere molto utile ad indurre i giusti comportamenti nel team di sviluppo con una redditività molto elevata, anche – perché no – in termini di morale.

August 07 2009 | Esperti | 1 Comment »

Iteration plan: prevenire è meglio che curare. Banale vero?

In questo post di Jack Milunsky leggo

I find way too many companies after each iteration still trying to close things down in order to get this potentially shippable code shipped. More often than not there’s on-going QA etc long after the iteration is over. This is not a healthy state of affairs.

Credo sia un’ottimo spunto di riflessione da incrociare e mediare dopo aver letto questo post di Francesco Trucchia.

Il problema è ben articolato: da una parte il bug fixing non è valore consegnato al cliente - repetita juvant; dall’altra un iteration plan sovraccarico è il tipico sintomo di un cliente avido che non lascia al team lo spazio di manovra necessario a produrre quel valore tanto agognato e, chiaramente, di un team in posizione di debolezza rispetto al cliente.

Continuo a credere che alcune mie vecchie passioni da ingegnere gestionale ritrovate poi nel Lean Software Dvelopment possano essere la risposta a questo tipo di situazioni. Devo rifletterci ancora un po’…

June 07 2009 | Esperti | No Comments »

Next »