ITDevCon è una conferenza Europea dedicata interamente a Delphi e alle tecnologie ad esso collegate.
[...]
Durante le due giornate di intensa formazione programmatori, analisti e software architect avranno la possibilità di scegliere fra le tre sessioni parallele della conferenza e confrontarsi con esperti di fama nazionale ed internazionale provenienti da realtà eterogenee che permetteranno loro di valutare punti di vista molto differenti tra loro.
Così recita la homepage del sito di ITDevCon 2009 e devono avere intenzioni di eterogeneità molto serie, visto che hanno invitato a parlare di extreme programming, scrum e metodologie agili in genere perfino me, che ho scritto le mie ultime righe in Delphi nel 1997!
Sarà quindi un piacere perfino maggiore presentare giovedì 12 novembre il talk intitolato Un approccio per unificarli tutti: cosa significa sviluppo agile in cui cercherò di porre l’accento sugli aspetti cross-tecnologici dei processi agili e sul vero baricentro metodologico: valori e principi. L’abstract del talk recita
Lo sviluppo agile è ormai un concetto diffuso e un termine sulla bocca di molti. Fortunatamente indipendente dalla tecnologia, questo approccio al nostro lavoro permette un notevole incremento del tasso di successo di un progetto software. Ma facciamo un passo indietro e cerchiamo di capire: abbiamo capito bene cosa significa sviluppo agile? In questo talk introduttivo Jacopo Romei spiegherà le pratiche Extreme Programming e i principi e i valori che sono il vero nocciolo dello sviluppo agile.
Mercoledì e giovedì, insomma, a Verona sarà un bel sondare un’altra comunità non-Java sui temi agili. Ti troverò lì?
Rieccomi finalmente dopo un breve periodo di assenza per un po’ di post in fila, per condurti, ma soprattutto condurmi, verso la prossima edizione del più importante evento italiano sui metodi agili come Scrum, Extreme Programming e Lean Software Development, l’Italian Agile Day 2009. Sarò infatti presente per la prima volta all’annuale evento come speaker con una sessione dal titolo Tutti i miei sbagli. E quelli di qualcun altro.
Sarà un talk autobiografico inverso in cui, senza pudore e senza nemmeno temere il ridicolo – che pur talvolta sfiorerò, toccherò, supererò? – racconterò non i successi dei miei ultimi anni da coach bensì ogni possibile esperienza negativa, cercando di vedere insieme a te perché le cose vadano male, perché possano andare male nonostante ci si ritenga agili e cosa ne pensi il pubblico di agilisti e non.
Se il principio di esposizione ha portato tanti benefici ai software open source, chissà che non faccia bene cominciare a mostrare i propri bug anche nel contesto del management. Il carattere del talk sarà fortemente suicida, in cerca della figuraccia, dell’errore da principiante… Per scoprire e ricordarmi da una parte che sono un principiante e dall’altra che un sano galileismo non teme auto-osservazione retrospettiva, per crescere ancora.
Mi metto alla gogna con le mie stesse mani. Nella fossa dei leoni per giunta. Porta i pomodori!
Con spirito schizofrenico da una parte e prudenza giuridica dall’altra – non abbiamo ancora bene capito cosa potremo ben scrivere – Francesco e io vi presentiamo il blog dedicato al nostro libro Pro PHP Refactoring with Test Driven Design. Poi magari non vi potremo scrivere niente di rilevante; poi magari non vi scriveremo niente che non si possa scrivere sui nostri rispettivi blog; poi magari non ci verrà niente in mente di interessante da scrivere; però oh, noi intanto lo abbiamo tirato su, con buona pace degli spider di Google.
Siamo già a caccia di lettori replicanti, non umani. Alla faccia di Rick Deckard!
Un grafico burndown relativo ad un progetto di cui sto curando il processo
Questo è un burndown chart disegnato appena prima di pranzo, oggi. Lo sto pubblicando per diversi motivi:
Mi sembrava abbastanza chiaro e quindi, di base, adatto alla sua stessa diffusione.
Dimostra che è possibile disegnarne uno in 5-6 minuti, segando le gambe quindi a tutte le pigrizie possibili. In futuro sarei comunque disposto a faticare anche un po’ di più per vedere quell’espressione di chiarezza acquisita sul volto di tutti: clienti, sviluppatori e interaction designer: “Ah, effettivamente così rende proprio il senso di quello che accade quando aggiungiamo feature selvaggiamente!”. Credo si riferisse alla 4 iterazione, secondo te?
Trovo piacevole constatare come il passo del progetto sia tutto sommato costante, rendendo chiaro come le oscillazioni della project velocity e della – più rara – ristima delle user story si compensino caoticamente suggerendomi di essere meno paranoico sul valore di project velocity ottenuto di iterazione in iterazione.
Tu? Ci leggi altro? Scrivimi le tue considerazioni, mi interessano moltissimo.
In un recentissimo post di Alberto Mucignat, caro amico più volte ospite di questo blog, nonché esperto progettista di interfacce, si possono leggere sintetizzati i punti salienti per capire come lavorano gli interaction designer di Facebook.
Sebbene mi piacerebbe soffermarmi sul punto
3. I designer lavorano principalmente in codice (html/css e un pizzico di php)
tradendo così la mia estrazione da sviluppatore e confermando il codice come valido (!= perfetto) formalismo per questi scopi, preferisco invece farti notare questo:
4. Non si affezionano troppo al lavoro: il software cambia continuamente.
È più di un anno che scrivo e dico che l’unica via per rendere più agile il lavoro degli interaction designers è basata su due punti:
Trovare strumenti che permettano il facile refactoring dei wireframe.
Adottare una filosofia di progettazione più incline al rifacimento e meno al desiderio di essere – disperatamente – up front.
Il primo vincolo potrà anche essere squisitamente tecnico – ed è solo questione di tempo, ma il secondo non è che di natura umana.
Avevo pronta una categoria recensioni da tempo qui per questo blog. Non l’ho più usata un po’ per questione di priorità di argomenti – il tempo per scrivere è già così poco – un po’ per doverosa umiltà: perché dovrei recensire libri altrui? Allora comincio dal mio. Anzi, dal nostro.
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…
Domani sera, 08 settembre 2009, al Caffé Emporio, Piazza dell’Emporio 1, nuovo appuntamento della nuova serie di meeting Roma XPUG. Dopo la lunga pausa estiva rieccoci per incontrarci fra neofiti, appassionati, professionisti e semplici curiosi della metodologia agile dei nostri cuori. Il tema di stasera saranno il Lean Software Development, il kanban e le relazioni di questa metodologia con extreme programming. Ovviamente varie ed eventuali emergeranno! Se sei di Roma e dintorni vieni anche tu: un drink in compagnia non si nega mai!
Non sembra, non è esattamente l’immagine familiare che hai del saccottino che forse ha accompagnato la tua infanzia, ma è invero un saccottino. L’ho trovato ieri nel mio pacco e sono rimasto abbastanza sorpreso. Anzi, devo ammettere di aver provato inizialmente un certo sgomento, una certa diffidenza. Farà mica male? Poi ho capito che si trattava solamente di due mezzi saccottini evidentemente sfasati [1] rispetto alla catena di produzione in azione nello stabilimento industriale dove questi due sfortunati saccottini erano in fase di confezionamento .
Poi ho capito anche un’altra cosa. Il mio sgomento trovava le sue radici nella rarità. Non mi era mai successo di comprare saccottini difettosi. Il prodotto esente da difetti nell’industria del saccottino è una rarità. E così in molte, moltissime altre industrie.
Che l’industria del software sia storicamente di tutt’altra qualità è una cosa che percepisco io e percepisci anche tu, anche senza dati oggettivi.
Ecco, tutto il senso dietro a SCRUM, dietro a Extreme Programming, dietro allo sviluppo agile, dietro al Lean Software Development… è proprio questo: lo sforzo di ricerca di un mondo in cui un software difettoso generi lo stesso sgomento di un saccottino sfasato.
[1] Uno sfasamento di mezzo saccottino è, in termini controllistici, uno sfasamento di 90°. Lo scrivo qui un po’ perché amo le note a pie’ di pagina, un po’ perché l’ingegneria dell’automazione è leggermente off topic in questa sede, ma solo leggermente.
![[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)
Per scoprire e ricordarmi da una parte che sono un principiante e dall’altra che un sano galileismo non teme auto-osservazione retrospettiva, per crescere ancora.
– un po’ per doverosa umiltà: perché dovrei recensire libri altrui? Allora comincio dal mio. Anzi, dal nostro.
