martedì 28 ottobre 2008
alla fine è arrivato: il momento di dare un taglio nuovo alla mia attività in rete. tante piccole cose in questo ultimo periodo, che sommate mi hanno convinto ad aprire un nuovo spazio in cui pubblicare le mie esperienze. così, armato di pazienza e buona volontà, ho iniziato ad allestire un nuovo blog, in cui conto di postare molto materiale e dare maggiore visibilità al lavoro svolto dal mio team.
il blog è raggiungibile all'indirizzo http://jfranzoi.wordpress.com
mi sono scritto - rigorosamente test-driven - un tool in Ruby (di cui a breve racconterò) con il quale ho importato tutti i contenuti, a parte purtroppo i preziosi commenti - che rimangono in ogni caso presenti in questo blog.
dopo due anni e mezzo, ho deciso definitivamente di passare da un'ottica tecnologica - l'esperienza della community UGIdotNET - ad una metodologica, che poco avrà a che fare con .NET e il mondo che vi ruota attorno.
invito quindi tutti quelli che vogliono continuare a leggere quello che ho da dire su eXtreme Programming e metodologie Agili, testing automatico di applicazioni (Java, e magari Ruby), architetture e principi di progettazione software, di aggiornare il proprio feed-reader con il nuovo indirizzo.
spero di trovarvi presto - virtualmente - tra i commenti dei miei prossimi post, e - fisicamente- magari a Bologna, per il prossimo Italian Agile Day 2008, al quale parteciperò anch'io attivamente con una sessione, insieme ad un mio collega, su "Retrospettive, Stand-Up Meeting e Journal".
è tutto, a presto.
-papo-
venerdì 3 ottobre 2008
oggi a pranzo con qualche collega discutevamo di come risolvere un esercizio di logica (ad esempio, trovare l'intersezione tra array, e valutarne la complessità), che il nostro coach ognitanto ci lascia come stimolo per tenere allenata la mente, e per favorire il confronto tra tutti noi del team [continua..]
sabato 20 settembre 2008
questa settimana è arrivato un nuovo tassello nel mosaico dell'applicazione Java che il mio team sta sviluppando in questo periodo. è ormai in code complete la user-story che ho preso in carico, che si occupa di realizzare l'aggancio ad una coda, realizzata da sviluppatori di un altro team interno, e di supportare il formato dei dati concordato con loro. [continua..]
lunedì 15 settembre 2008
non è un segreto, sono test-infected. questo significa che prima di iniziare a scrivere del codice, il mio istinto (o malattia) mi porta a partire da un test automatico. ma non è solo questo: l'approcio infatti mi si rivela utile in ogni situazione in cui ci sia da scoprire come fare qualcosa di nuovo. [continua..]
domenica 6 luglio 2008
no, non è un post in inglese. il titolo si riferisce alla sessione che io e il mio collega Tommaso abbiamo tenuto lo scorso giovedì per i ragazzi della
ESSAP (
European Summer School on Agile Programming) presso Villa Toeplitz a Varese. è stata un'esperienza stupenda, sia per il fatto che ci siamo tutti divertiti moltissimo, sia per l'interesse che i partecipanti (un po' assonnati per il post pranzo!) hanno dimostrato verso i temi esposti.
putroppo, questa era la prima volta che la sessione prendeva corpo, e quindi sicuramente non siamo stati efficaci quanto speravamo: l'argomento è insidioso perchè offre il fianco a lunghe discussioni puramente tecniche, errore in cui siamo caduti anche noi. il pubblico, una ventina di ragazzi da tutta europa, era molto eterogeneo, chi vedeva per la prima volta le tematiche legate ai
metodi Agili, accanto a chi invece già adotta alcuni principi e pratiche nel proprio lavoro ed era lì per affinarli o capire come farli meglio funzionare.
abbiamo scelto di dividere la sessione in due parti. prima un'introduzione al concetto di
iterazione e
test di accettazione scritti da/con il cliente, quali possibili forme usare per scriverli e quali tool esistono a supporto. abbiamo descritto in dettaglio il funzionamento di
FIT e
FitNesse e mostrato le principali fixtures usate, quelle di FIT e alcune di
FitLibrary.
nella seconda parte della sessione invece abbiamo fatto un esercizio, partendo da un esempio scritto da noi (una variazione di quello che i ragazzi avevano già visto in altre sessioni): un semplice
gioco di ruolo per il quale abbiamo realizzato una decina di
user stories, corredandole di
test unitari e
test di accettazione. quindi abbiamo eletto a
customer uno dei ragazzi nel pubblico, chiesto a lui di inventarsi la prossima user story e iniziato a descriverla in
forma testuale su una lavagna. prendendo spunto da quanto già fatto per le altre storie, abbiamo poi scritto un test di accettazione, sempre su lavagna, e tradotto poi in
forma tabellare.
il resto del pomeriggio (troppo breve!) i ragazzi hanno così lavorato in coppie cercando di implementare la storia richiesta, partendo dalla traduzione in FitNesse del test di accettazione, collezzionando una bella "barra rossa", doverosa a inizio iterazione. hanno poi iniziato a decidere dove porre le responsabilità richieste, e mi pare che tutti abbiano deciso di assegnarle a oggetti già esistenti, iniziando così a scrivere i test unitari, a vederli fallire uno ad uno, per poi modificare il sistema e godersi il premio di una barra verde!
anche se l'esempio era molto semplice e le modifiche da aggiungere davvero limitate, ho notato la soddisfazione sopratutto dei ragazzi nuovi alle tematiche ad ogni esecuzione con successo dei test unitari. è quello che in
eXtreme Programming viene detto il
valore del feedback, assolutamente fondamentale.
prima di andare a casa, tutte le coppie sono riuscite a chiudere la micro-iterazione, verificando che il loro lavoro fosse
corretto e
concluso, vedendo passare con successo anche il test di accettazione. qualche coppia, avendo finito in anticipo, ha iniziato a lavorare su una seconda carta, inventata al momento. mi spiace solo che l'abbiano scelta loro invece di coinvolgere il "customer-per-un-giorno", ma è comprensibile dato l'entusiasmo e la brama di giocare col la pratica e lo strumento.
a me non resta che ringraziare tutti: gli organizzatori (primo tra tutti il mio coach
Matteo) per l'occasione concessa e i partecipanti per le ottime domande a cui abbiamo cercato di rispondere in modo conciso. da parte mia, è stata una giornata splendida, mi ha fatto crescere come "speaker", ruolo per me nuovo, ho avuto anche l'occasione per conoscere di persona alcuni nomi "digitali" (come
Luka), e si è conclusa con uno ottimo
social-dinner!
il materiale della sessione sarà presto disponibile sul sito della ESSAP, nel frattempo è raggiungibile qui:
le nostre gesta sono anche state immortalate! più le rivedo e più sorrido. in ogni caso, sono
qui,
qui,
qui e
qui (peccato non si veda la scritta sul mio tesserino "
Jacopo - xtreme guitarist", nascosta dalla maglia rosso acceso!).
grazie ancora a tutti, spero la scuola possa farsi conoscere ancora di più, magari nelle prossime edizioni ci troveremo anche molti della comunità ugidotnet!
a presto.
-papo
lunedì 28 aprile 2008
segnalo
questo annuncio di lavoro, che qualcuno avrà già letto sulla mailing list di extreme-programming italia.
il mio team vuole allargarsi!
siamo alla ricerca di giovani agilisti nella zona di milano, chiunque fosse interessato può contattare direttamente
Matteo, che attualmente ricopre il ruolo di
coach.
spero di poter incontrare presto qualcuno di voi!
ciao
-papo-
giovedì 17 aprile 2008
se c'è una cosa che mi dispiace davvero è aver permesso che il mio blog rimanesse in silenzio per così tanto tempo. è passata una vita dal mio ultimo post, ma sopratutto tante sono le cose successe. occasione, che cerco oggi di cogliere, è un particolare anniversario che cade questa settimana: un anno da quando ho iniziato a lavorare come eXtreme Programmers, un anno che vivo da solo, un anno in una città come milano.
il 2008 si è aperto con una grossa novità, una grandissima occasione: si è conclusa la collaborazione che mi ha visto impegnato per gran parte dello scorso anno ed è iniziato il mio nuvo impiego, a tempo indeterminato, per una piccola ma attivissima realtà nel panorama Agile italiano. nello stesso tempo, mi sono impegnato a tempo pieno come membro dello XP User Group locale, organizzando alcuni incontri sia nella vecchia azienda che in quella nuova. con i ragazzi dello xpug abbiamo anche partecipato alla scorsa edizione dell'Agile Day, in cui ho avuto modo di dare un volto a mille dei nomi conosciuti in rete.
un anno, tempo di tirare le somme. mi vergogno quasi un po' a dirlo, questo anno appena passato è stato per me davvero importante: ho imparato un mestiere, il mestiere che mi sono scelto e che mi appassione ogni giorno di più, affiancando dei veri professionisti e toccando con mano il valore dell'approcio Agile allo sviluppo del software. e sono cresciuto sopratutto come persona, imparando a vivere fuori casa, ad organizzarmi la vita.
la novità più grossa è che mi è stata offerta la possibilità di fare mentoring. da oltre due mesi infatti sto seguendo un team di una grossa banca italiana nel suo percorso di avviamento all'agilità. particolarmente interessante è la formula scelta: un team misto, in cui alterniamo attività di formazione ad altre di sviluppo puro. tutto questo è decisamente stimolante, passare in così poco tempo da apprendista stregone a sciamano! la portata della responsabilità è notevole, ma è altrettanto grande la soddisfazione nel sentirsi dire, da sviluppatori che fanno questo mestiere da anni, "grazie di avermi fatto scrivere tutti questi test", o nel vedere riconosciuto il valore del customer on-site e della continua comunicazione.
questo è quanto, non posso che considerarmi soddisfatto dei mie miseri 27 anni. auguro a molti miei coetanei che vengano loro offerte le stesse opportunità che ho ricevuto io, e che sappiano farne buon uso!
dimenticavo l'ultima novità: sto scrivendo da un bellissimo MacBook Pro!
a presto
-papo-
venerdì 26 ottobre 2007
stavo per rispondere a Jeremy , che è curioso di sapere quale variante di Model-View-Presenter sia maggiornente diffusa tra i suoi affezionati, indicando come nel mio caso si tratti del Passive View. però poi mi sono accorto che era uno spunto buono per un post...
[continua]
giovedì 28 giugno 2007
stavo per rispondere a
questo post, poi mi sono accorto che e' disabilitato il feedback, quindi posto qui il mio commento.
in realta' non hai *risolto* il problema, prima o poi qualcuno dovra' fixare il codice che ha 'rotto' la build. hai soltanto aggiunto un ritardo tra quando il problema e' stato introdotto (durante la scrittura del codice), a quando il problema sara' visibile (la build di CC.NET che fallira').
in realta' chi notera' che la build si e' rotta potresti non essere tu (o chi ha aggiunto il codice incriminato) e quindi sara' piu' difficile localizzare e correggere l`errore. 5 minuti non mi sembrano affatto molti, prova a considerare i vantaggi che hai nel feedback immediato sulla correttezza del tuo codice, rispetto a dover correggere a posteriori l`errore di qualcun`altro.
in azienda noi seguiamo una politica di questo tipo: mentre sviluppi esegui solo i test della parte che *pensi* sia influenzata dal nuovo codice (classi correlate e qualche test di accettazione che tocca quella parte), ma poi prima di integrare e committare le modifiche viene eseguita tutta la suite di test, due volte: la prima solo sulla propria versione del codice, la seconda dopo aver prelevato le modifiche dal repository e corretto i conflitti.
questo perche' la rottura di una build e' una cosa seria: in alcune aziende ci sono riti di fustigazione pubblica dei colpevoli (cappelloni ridicoli da dover indossare per tutto il giorno) o sirene di allarme che suonano per l`ufficio! questa invece e' una
lava-lamp collegata a CC.NET
ciao!
-papo-
venerdì 18 maggio 2007
finalmente, non so come, trovo il tempo di postare
le prime impressioni sulla mia nuova situazione: nuovo lavoro e nuova
città, nuovi colleghi e nuova casa. è passato appena un mese, eppure
sono tantissime le cose che avrei da raccontar(mi). per ora voglio focalizzare le
idee solo sugli aspetti di lavoro. quindi...
come avevo accennato nello scorso post, ho avuto la possibilità di unirmi ad
un gruppo di eXtreme Programming avviato, imparare quindi da chi queste
cose le vive quotidianamente da anni. il team al momento non è esteso, e questo
mi ha permesso di poter "sperimentare" il lavorare in coppia con tutti gli altri
elementi del gruppo, a turno, su problemi diversi. in questo modo ho avuto la
possibilità di toccare tutte le parti di cui è composto il progetto, entrando di
volta in volta nel vivo dei problemi.
la prima cosa
che ho imparato è il rapporto con il tempo. in passato, io e il
tempo non siamo sempre andati d'accordo, diciamo che generalmente vinceva lui:
finiva la giornata, io ero distrutto, a volte per la fretta di concludere, che mi portava a
intensificare il lavoro per lunghi periodi, con l'evidente stress che ne
derivava. ora le cose sono diverse, e posso dire di essere sulla strada buona
per prendermi qualche rivincita!
il tempo è scandito da una unità atomica, che nel nostro caso
è il pomodoro: 25 minuti di lavoro
seguiti da 5 minuti di pausa. questo significa che non mi è concesso occupare la
mente per un periodo più lungo di una mezz'oretta, c'è sempre una piccola
sosta per riposare il pensiero e riprendere le forze. ma la cosa più importante è imparare a
stimare l'effort necessario a completare una qualche
attività: è perciò fondamentale poter misurare e tracciare come il tempo
venga speso durante una giornata. per questo per ogni compito
e funzionalità che prendiamo in consegna, rappresentati da
carte (sì sì, simpatici foglietti di carta con un
nome scritto sopra e in caso qualche annotazione), vanno segnati quanti pomodori
sono stati utilizzati e come questi sono stati spesi: esplorazione, codice,
rifattorizzazione, integrazione, etc. a fine giornata poi, prima di andare
a casa, inseriamo queste informazioni in uno strumento di tracking:
ci saranno utili per trarre alcune considerazioni sull'andamento dell'iterazione di sviluppo, confrontando
misuarazioni e stime iniziali.
infine l'altra novità, decisamente piacevole, è stata
scoprire che parte del mio lavoro consiste nello studio. dico
"decisamente piacevole" perchè si tratta di qualcosa che ho sempre fatto per
passione e che ora sono chiamato a fare per
mestiere. design patterns, principi di progettazione del software, articoli
e interi capitoli dei libri della letteratura di riferimento (xp, refactoring)
sono alcune delle cose che ho potuto (ri)prendere in considerazione, analizzare,
schematizzare (ad esempio con delle mappe mentali) e discutere con il
resto del team: qualcuno risponde alle domande che mi sono
fatto e anch'io contribuisco a chiarire i dubbi di qualcun'altro. come
qualsiasi altra attività, anche il tempo dedicato allo studio (in genere
un'ora al giorno) di ciascun argomento viene stimato e misurato.
non posso quindi nascondere la soddisfazione nello
scoprire quanto spazio mi sia concesso per crescere professionalmente. primo
perchè il lavoro è svolto sempre in coppia (pair
programming): questo favorisce il confronto e la collaborazione continua.
e nonostante io sia il più giovane e meno esperto si fa tesoro anche della mia esperienza
in questioni tecniche (come la gestione della persistenza
- Hibernate e il suo cugino .NET sono parenti strettissimi!). secondo, per
gli stimoli allo studio, ovviamente finalizzato all'applicazione in pratica di quanto appreso.
la "biblioteca" interna è infinita e ghiottissima! e, se non bastasse, sono anche disponibili account per leggere articoli
di alcune riviste online.
ho solo scalfito la superficie degli argomenti che avrei voluto affrontare, ma per questa volta direi che può bastare (se
solo penso al fatto che questo post è stato abbozzato due
settimane fa mi vengono i brividi!). spero di poter raccontare i
dettagli di quanto resta da qui in avanti.
a presto
-papo-