Dato che nessun uomo è un’isola qualche mese fa ho pensato di ravvivare la scena XP romana proponendo sulla dormiente lista dell’Extreme Programming User Group romano un nuovo incontro, non chiedendomi nemmeno se ci fosse mai addirittura stato un precedente incontro.
La risposta è stata rapida, forse esigua, ma sicuramente rapida. Ovviamente qualche perdita sul fronte delle famiglie, degli altri impegni e dei viaggi di lavoro c’è stata, ma a questo si rimedierà con calma usando il grimaldello della regolarità degli incontri.
Per ora sono lieto di annunciare la ripresa dei meeting del Roma XPUG con quello odierno al Big Hilda Caffè, Vicolo del cinque 33 alle ore 20:00.
Non pensi che Trastevere sia una bella cornice per parlare di user story, design emergente e scadenze da rispettare? A stasera!
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ò?
Il progetto è molto interessante e purtroppo non potrò rivelarne i dettagli. Nonostante questa limitazione però ho ritenuto interessante documentare le fasi del processo di progettazione e sviluppo per rendere l’idea, l’atmosfera che caratterizza il nostro modo di lavorare. continue reading »
Una delle problematiche principali del software project management è l’ordinamento degli obiettivi e dei task relativi. Ci sono delle cose da fare prima e altre dopo, mentre nel frattempo dobbiamo essere in grado di dimostrare responsabilità da una parte e progressi concreti dall’altra. L’extreme programming non ci risparmia questa difficoltà, pur mettendo a nostra disposizione strumenti – come il planning game – atti ad analizzare queste problematiche e a sostenere le decisioni del team.
Ieri finalmente il workshop su extreme programming tenuto al phpDay 2008 insieme a Francesco Trucchia. Un’esperienza fantastica, in compagnia di persone splendide, con un’ottima partecipazione e un’enorme soddisfazione per noi.
Nei prossimi giorni farò un resoconto più dettagliato – completo di foto e filmati delle fasi più accese del planning game che abbiamo simulato, ma certamente ringrazio fin d’ora Francesco, il direttivo del Gr.u.s.p. e Fullo, che ci ha messo davvero nelle condizioni di operare al meglio per la buona riuscita del workshop.
Un ringraziamento finale va a tutti i partecipanti. Vederli chiusi in cerchio giocando al planning game è stata una vera soddisfazione, davvero non speravamo in un tale coinvolgimento di tutti.
Ieri ho partecipato al primo giorno del phpDay 2008, in attesa di pubblicare con Francesco il nostro workshop oggi pomeriggio. Giornata divertente come ogni anno mi aspetto che sia, resa più frizzante dalla richiesta improvvisa di Fullo di aiutarlo a riempire un buco venuto improvvisamente a crearsi nell’agenda della giornata. Pensavo di fare un talk veloce sulle metafore fisiche con cui mi capita di descrivere (o di veder descritti) i processi agili, poi però Francesco mi ha dato l’idea migliore – parlare del Domain Driven Design – che ho poi deciso di integrare con riferimenti all’extreme programming.
Il domain driven design è una metodologia di modellazione del software che parte dal presupposto per cui gli sviluppatori devono nel tempo distillare una sempre maggiore porzione di conoscenza di dominio nella struttura del codice scritto, conoscenza che proviene dal contributo degli esperti di dominio, tipicamente il cliente.
Un obiettivo fondamentale di questo processo è quello di creare un ubiquitous language che sia condiviso tra team di sviluppatori ed esperti di dominio, che si rifletta fino in fondo alla scelta dei nomi delle classi, dei metodi, delle interfacce e delle strutture relazionali tra oggetti, in modo da
rendere più affidabile il design dell’applicazione
rendere più semplice la partecipazione del cliente alla progettazione stessa
Il che già di per sé sembra fortemente propedeutico per la pratica extreme programming denominata customer on site che richiede al cliente di essere presente direttamente – o per delega – presente presso il team di sviluppo del progetto di cui è committente.
Ma se poi andiamo a fondo nell’apprendimento del domain driven design scopriamo anche il concetto di continous learning e di new insight che riflettono il fatto che gli sviluppatori, man mano che vivono all’interno di un progetto, ne assimilano i concetti di dominio fondamentali e sono perciò portati a modificare il codice per riflettere questo incremento di conoscenza. Il libro di Eric Evans fornisce molti utilissimi consigli per ottenere codice che sia facile da manutenere e far crescere, ma per noi agilisti è chiaro che vengono alla mente i concetto di design emergente e, ancor di più, di refactoring.
Extreme programming quindi ci fornisce delle pratiche che, se seguite con attenzione, ci permettono di modificare il codice senza timore, di tenerlo pertanto aderente alla realtà di dominio e quindi di perseguire il continous learning senza attriti ed ostacoli di sorta.
È chiaro quindi come il domain driven design possa essere propedeutico alle pratiche agili, ma anche come extreme programming possa esserlo per l’incremento di conoscenza del dominio che una modellazione domain driven presuppone.
Molte pratiche extreme programming hanno a che fare con il coraggio.
La parola “coraggio” non va letta con riferimento ad un atteggiamento sprezzante del pericolo da parte dei membri del team di sviluppo – ma sì iniziamo a scrivere codice, poi si vedrà! – quanto piuttosto all’assenza di paura.
“Ma io non ho paura quando programmo!” molti di voi staranno pensando in questo momento. Bene, sono pronto a smentirne molti; mi sarà sufficiente porre una sola domanda:
Avete appena finito di lavorare ad un componente che ha richiesto 10 giornate (2 settimane!) del vostro prezioso lavoro. Ora il cliente ha ragionevolmente deciso, sulla base di ulteriori informazioni tecniche e di mercato di cui prima non disponeva, di modificare quel componente. Ciò richiederà di modificare ed integrare il lavoro appena concluso in misura tale da rischiare di compromettere il lavoro perfettamente compiuto fino a quel momento.
L’idea di manomettere il codice già scritto vi lascia perfettamente tranquilli?
Con questo post voglio inaugurare un nuovo filone di articoli sulle metodologie agili ed in particolare su extreme programming, cercando di pubblicare il più spesso possibile quello che ritengo il mio ultimo errore madornale nella gestione agile di un progetto. Se l’open source ci ha insegnato che l’esposizione è una cura contro i bug, voglio così assicurarmi che esponendo i bug del mio project management esso stesso ne esca rafforzato, corroborato, catarticamente immune.
![[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)
