Gabriele Lana

Avendo apprezzato Peter Seibel in “Founders at Work” ( consigliatissimo) in questi giorni sto leggendo con piacere il suo ultimo lavoro “Coders at Work”, stando all’ultimo suo post anche Joel Spolsky lo sta leggendo.

Joel ha elogiato Jamie Zawinski (uno dei programmatori intervistati da Seibel nel suo libro) per la sua capacità di scrivere velocemente codice funzionante e fruibile da un utente finale. Joel ha chiamato questo tipo di programmatore “Duct Tape Programmer”, un’etichetta che ha suscitato un bel polverone.

Insomma si parla del solito tradeoff “time, quality, money – pick two”, che poi ufficialmente si traduce sempre in “scegliamo tempo e denaro, per la qualità speriamo di farla franca”.

Cosa centra tutto questo con i kata? Quando qualcuno si lamenta del fatto che le tecniche che propongo non sono praticabili nella loro realtà perchè non c’è il tempo (la solita storia del “bello, ma da noi non si può fare”), mi ricordo quando anch’io mi lamentavo della stessa cosa, vedevo la carenza di tempo come la prima ragione di tutti i miei fallimenti, poi però ho iniziato a chiedermi: “se fino ad oggi non ho mai avuto tempo per fare le cose bene, come faccio ad essere sicuro di saperle fare? Come faccio ad essere sicuro di riuscire a scrivere codice pulito se non ho mai avuto il tempo di scriverlo?”… Interessante quesito che ci porta ai kata e alla nozione generale di esercizio

Gli esercizi di programmazione hanno due obiettivi

• Darci la possibilità di lavorare in un ambiente controllato e privo di vincoli. Il fallimento è visto in maniera positiva, venire a conoscenza dei nostri limiti è l’unico modo per poterli superare
• Visto che non avrete mai il tempo che volete, l’unica cosa che potete fare è diventare più veloci nello scrivere codice di qualità

Il secondo punto ci riporta al tema iniziale: dove sta scritto che per scrivere del buon codice serve tanto tempo? Io sono fermamente convinto che l’unica ragione per la quale intuitivamente lo pensiamo è perchè quando ci proviamo facciamo fatica, e l’unica ragione per la quale facciamo fatica è perchè non siamo abituati/allenati.

Ultimamente ho dedicato un po’ di tempo a pensare ai kata e ad esercitarmi, venerdì della settimana scorsa ho partecipato al primo javascript camp italiano organizzato da Ideato e ho presentato il kata “the game of life” in javascript, è stato molto divertente ed istruttivo

Gli ingredienti per un buon kata/esercizio sono

• Un problema sfidante per le vostre capacità e per la vostra preparazione
• Una o più persone pronte a darvi il loro feedback, fondamentale per capire come e dove migliorarsi
• Ripetere l’esercizio più e più volte finchè sentite che ormai il problema non ha più niente da insegnarvi

Il mio consiglio è di provare e di mettervi in gioco, per quanto mi riguarda le prossime mosse saranno: pubblicare gli screencast dei miei kata ed organizzare dei gruppi di esercizio/studio, se siete interessati contattatemi o iscrivetevi milano-codingdojo (non preoccupatevi se non siete di Milano, stiamo organizzandoci per fare qualcosa di distribuito ;-))

Stimolato dal professore l’ho fatto anch’io. Di solito i risultati di questi test su di me funzionano poco, quando facevo il militare ci facevano regolarmente dei test attitudinali/caratteriali/? e regolarmente su 12 profili possibili io risultavo appartenere in egual misura a 6/7 profili contemporaneamente… :-)

My Political Views
I am a centrist social moderate
Left: 0.14, Libertarian: 0.95

Oggi ho visto l’ennesimo strepitoso intervento di Eric Ries a proposito della pratica del MVP (Minimum Viable Product). Il problema è molto chiaro: la nostra vision di prodotto potrebbe portare ad un business non sostenibile; la strategia proposta lo è altrettanto: trovare il minimo set di funzionalità in grado di poterci dare un feedback reale sulle esigenze dei nostri utenti e in che misura il nostro prodotto le soddisfa.

Maggior conoscenza acquisiamo sui nostri utenti, maggiori saranno le probabilità che la prossima funzionalità pensata/implementata sarà apprezzata (aumentando il valore dell’applicazione). Minore sarà il tempo/costo d’implementazione di una nuova funzionalità, maggiori saranno le funzionalità che potremmo utilizzare per acquisire conoscenza sui nostri utenti

Cosa possiamo fare per minimizzare i tempi/costi d’implementazione? Chiaramente possiamo intervenire da un punto di vista tecnico migliorando la nostra capacità di produrre software, mantenendo sempre pulita la nostra base di codice, migliorando costantemente gli aspetti di project automation e di autonomation, ecc… insomma avete capito

L’altra cosa che possiamo fare è splittare in maniera creativa ed aggressiva le user story esistenti del prodotto. Prima possiamo iniziare a selezionere un minimo set di user story in grado di dare dignità di prodotto al nostro progetto, poi possiamo iniziare a considerarle singolarmente e a capire cosa possiamo togliere da ogni user story conservando la possibilità di poter utilizzare il risultato come MVP

Un esempio? Avevo 10 giorni (nessuna domanda please sul perchè di questo numero magico…) di tempo per realizzare un’applicativo piuttosto complesso, ovviamente c’era di mezzo uno storage, ovviamente il cliente aveva richiesto un’interfaccia di amministrazione/gestione di questo storage e ovviamente non aveva tralasciato nessun “goodies”: utenti, gruppi, ruoli, permessi, editing, viste configurabili sui dati, ecc… praticamente mi sarebbero serviti molti più giorni di quelli a disposizione solo per questa parte accessoria del sistema. Volevo iniziare dal vero prodotto, ma volevo anche che il cliente lo potesse utilizzare da subito, così ho installato phpMyAdmin e ho fatto vedere al cliente come utilizzarlo: ho creato utenti, viste, maschere, ecc… alla fine il cliente mi ha detto che è esattamente quello che voleva :-D Ok, sono stato fortunato, ma è stata una vera epifania

Un’altro esempio un po’ più creativo? Kent Beck qualche hanno fa ha tenuto un workshop sullo split delle user story usando un esempio alquanto “ardito”: il gioco del tetris… qual’è secondo voi la prima user story per Beck? Una colonna, un quadratino 1×1 che scende a velocià costante, quando un quadratino tocca il fondo parte un altro quadratino, il nuovo fondo è il quadratino precedente, quando il fondo arriva in cima alla colonna “game over” :-D

Ancora una volta una conferma del fatto che il business (il problem team come lo chiama Ries) e la tecnologia (solution team) non si possono/devono ignorare a vicenda

Qualche settimana fa ho capito una cosa tanto semplice quanto per me importante, il miglioramento della produttività applicando una metodologia Agile si ottiene su due fronti

• Pianificazione: identificare le User Story tenendole ad una granularità/indipendenza sufficiente da poter realizzare prima quelle con il più alto valore di business. Inutile dire che la valutazione del valore di business di ogni singola user story è fondamentale
• Esecuzione: migliorare costantemente la velocità di realizzazione delle suddette User Story

L’obiettivo supremo è sempre quello di massimizzare la quantità di valore consegnato nell’unità di tempo e in subordine la capacità di produrne in futuro, il resto sono chiacchere

E’ un concetto estremamente semplice, ma estremamente efficace se dovete introdurre a qualcuno le pratiche proprie delle metodologie Agili. Detto questo però se avete poco tempo a disposizione per catturare l’attenzione di qualcuno, se dovete fare un elevator pitch, vi serve qualcosa di molto immediato, vi servono delle metafore

Negli ultimi due anni ne ho raffinata una per spiegare come funziona la pianificazione e visto che è risultata essere particolarmente efficace la condivido con tutti, la scrivo come la racconto di solito

Supponiamo che dall’altro lato di quella porta (nda. di solito c’è una porta nelle vicinanze :-)) ci sia un team di programmatori che deve iniziare un progetto per il quale sono necessarie determinate conoscenze, queste conoscenze possono essere acquisite attraverso lo studio di alcuni libri, il vostro compito è quello di fornirglieli

Il materiale che vi viene dato consiste in 15m^3 di libri e di uno scatolone di 10m^3, se vi state chiedendo “esiste una metodologia in grado di far entrare 15m^3 di libri in uno scatolone di 10m^3?” la risposta è no! Anche le metodologie Agili non fanno eccezione :-)

Quindi cosa facciamo? Se seguissimo alla lettera i vincoli che ci sono stati dati e se non fossimo abbastanza svegli da misurare i volumi che abbiamo a disposizione, probabilmente spenderemo la maggior parte del nostro tempo a tentare di organizzare i libri per riuscire a farceli stare tutti nello scatolone. Una volta arrivati in prossimità della scadenza ficcheremo il maggior numero possibile di libri all’interno dello scatolone per poi spingerlo finalmente al di là della porta dove ci sono i programmatori che lo aspettano

Evidentemente non è una strategia molto furba… come possiamo migliorarla? Ci chiediamo: “qual’è il reale obiettivo di questo lavoro?” Massimizzare al quantità di conoscenza da passare al team di programmatori che sta al di là della porta, “la quantità di conoscenza erogata è indipendente dal libro?” Ovviamente no, quindi una cosa che possiamo fare è scegliere i 10m^3 di libri in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che la scelta delle user story da implementare è il primo passo verso la massimizzazione del flusso di valore)

Bene, possiamo migliorare? Ci chiediamo “ogni capitolo all’interno di un libro eroga la stessa quantità di conoscenza?” Nella maggior parte dei casi no, sicuramente non erogano conoscenza le copertine cartonate, le prefazioni, i ringraziamenti, ecc… Quindi possiamo procedere con un approcio creativo e stracciare ogni libro tenendo solo i capitoli migliori e quindi scegliere i 10m^3 di materiale in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che splittando le user story possiamo prendere la maggior parte del valore minimizzando il costo)

Ottimo! Possiamo ancora migliorare? Ci chiediamo “chi è che decide la quantità di conoscenza erogata da un testo?” Fino a questo momento siamo stati noi ma effettivamente è un assunto grave, cosa succederebbe se avessimo torto? La nostra strategia sarebbe ancora valida, ma le nostre misurazioni sarebbero pura speculazione, non possiamo essere sicuri di aver realmente erogato la maggior quantità di conoscenza possibile. “chi potrebbe valutare con maggiore accuratezza?” Sicuramente il team di programmatori che sta dietro alla porta

Quindi possiamo essere ancora più creativi e possiamo chiedere di barattare lo scatolone da 10m^3 con 10 scatoloni da 1m^3, nel primo scatolone ci mettiamo quello che noi riteniamo essere il miglior metro cubo di materiale possibile e lo spingiamo fuori dalla porta chiedendo ai programmatori di chiamarci una volta letto tutto. Quando i programmatori ci chiameranno chiederemo il loro feedback sul materiale, sulla base di queste informazioni sceglieremo cosa mettere nel prossimo scatolone. In questo modo non solo avremo una corretta valutazione del valore consegnato, ma abbiamo anche la possibilità di adattarci al contesto del progetto (nda. in questo caso stiamo dicendo che le funzionalità individuate all’inizio del progetto e la stima di valore che ne viene fatta è nella maggior parte dei casi errata e che quindi serve un reale strumento di feedback)

Secondo me funziona bene perchè

• All’inizio non ti aspetti di poter migliorare molto, quando capisci che puoi farlo è una bella sensazione :-)
• I 15m^3 in 10m^3 danno quella sensazione di claustrofobia che tutti hanno provato nei progetti “fixed *” (leggi: dove tutto è prefissato)
• Si capisce chiaramente che il modo per migliorare dipende poco dalla capacità di fare stime “corrette” quando dall’organizzazione del flusso di lavoro e di feedback

Cosa ne pensate? Possiamo ancora migliorare? :-)