Capitano giornate nelle quali manca la motivazione, ci si sente svogliati, si comincia un pomodoro ma non si riesce a mantenere viva la concentrazione per terminarlo gestendo le interruzioni.

Capitano giornate nelle quali “il prossimo pomodoro andrà meglio” non è sufficiente.

Capitano giornate nelle quali manca talmente la motivazione, che anche scorrendo il magazzino delle attività alla ricerca di un’attività stimolante non si è grado di scorgerla. Read the rest of this entry »

qualche giorno fa mi sono trovato sul blog di luca grulla e ho risposto ad un suo articolo riguardante la stima agile delle storie.
poi luca mi ha mandato un email con le seguenti domande:
“come siete passati da stimare i task a decidere di che non era più utile e stimare solo le storie ?
quale è stato il passaggio che vi ha spinto in questa direzione ?“

per chi non ha letto l’articolo siamo passati da una situazione dove stimavamo solo i task in pomodori a stimare solo le storie in punti
(questa è solo l’ultima puntata del: “imparare a pianificare agile”, vi risparmio le altre)
un bel cambiamento insomma… qui sotto vi spiego il perchè di questa decisione. Read the rest of this entry »

Si sente spesso dire che per utilizzare una metodologia come eXtreme Programming, e molte delle sue pratiche (su tutte il TDD), è necessaria una disciplina maggiore che con altre metodologie. Penso che ci sia un fondamento di verità in questa affermazione. Tuttavia il De Mauro definisce la disciplina come (il grassetto è mio):

L’insieme delle norme che regolano il comportamento di un individuo, un gruppo, un ente; rispetto, obbedienza di tali norme: imporre, violare, mantenere la d., è incapace di d., non sanno osservare la d. | estens., dominio dei propri istinti, desideri e sim. suggerito da principi etici o religiosi: si impone una ferrea d. .

Il termine disciplina richiama quindi fortemente un altro termine: rigidità. Come è quindi possibile che un paradigma che si pone come obiettivo dichiarato quello della flessibilità anche del metodo stesso, richieda a chi applica tale paradigma, disciplina e rigidità? Read the rest of this entry »

Ormai sono rientrato a lavorare da due settimane e (purtroppo) sto lavorando da solo. Solitamente il ritorno dalle vacanze e la mancanza di un compagno portano a poca concentrazione e soprattutto a vagare con la mente su vari task, arrivando spesso a fine giornata con la sensazione di aver “sprecato un giorno”. Questi aspetti uniti al desiderio di tracciare in modo più preciso il tempo speso sulle storie e ad un metodo sistematico per migliorare le stime mi hanno portato alla prima esperienza con la pratica del Pomodoro ideata da Francesco Cirillo. Read the rest of this entry »

Scrivere software di qualità è molto difficile, e tale difficoltà non solo è legata naturalmente alla complessità del dominio, ma anche a fattori più “umani” quali la comunicazione all’interno del team soprattutto quando composto da elementi di esperienza e formazioni eterogenee.

Una serie di tool ci viene in soccorso per monitorare continuamente la qualità del codice che stiamo scrivendo, e se unita alla pratica di Continuous Integration (ad esempio per mezzo di CruiseControl), permette di controllare continuamente e su base regolare se tutti i componenti del team stanno scrivendo software al di sotto degli standard di qualità prefissati. Prevenire problemi di comprensibilità e mantenibilità del codice, affrontandoli per tempo, è possibile rendendo visibili nel workspace le misure di queste caratteristiche, per mezzo di Big Visible Charts o di una Ambient Orb, cioè di una sfera che, comandata da un task di Ant, a seconda della qualità del codice si colora di verde o di rosso acceso.

I seguenti tool di controlli statici del codice permettono di tenere gli occhi ben aperti su questi aspetti:

• CPD (con PMD): identifica le duplicazioni del codice della nostra applicazione da parte degli sviluppatori più ansiosi o meno accorti; comunichiamo abbastanza?
• CheckStyle: verifica che le Code Convention vengano rispettate
• Metrics: riteniamo la programmazione ad oggetti una chimera o ci impegnamo a fondo per comprenderla?
• Clover: stiamo scrivendo abbastanza test?

Articoli:

• Automation for the People: continuous inspection

Ultimamente in TV c’è una pubblicità che mi piace molto: la pubblicità della Mostra Internazionale d’Arte Cinematografica di Venezia. La frase cardine della promozione, che credo appenderò in ufficio è la seguente:

E’ il desiderio di qualità che ci ha sempre permesso di sognare.

Stamattina ho letto inoltre un post di uno dei miei blog preferiti: AgileAdvice. Il post si intitola Quality is Not Negotiable (consiglio vivamente una lettura) ed affronta il tema della qualità come condizione irrinunciabile ed imprescindibile ad un processo efficiente che minimizza gli sprechi e che voglia ottenere il massimo dal business di cui è a supporto. In caso contrario ci si ritrova ogni 2-3 anni a dover ricostruire da capo sistemi e prodotti, o nel caso migliore (si verifica raramente) a dover fermare la produzione per lunghi periodi di tempo al fine di rimettere ordine in un prodotto mal costruito e di bassa qualità. Mi viene in mente uno dei cardini del Toyota Production System e di tutta la filosofia del Lean Manufactoring: in ogni momento ogni componente del team ha il diritto di fermare la produzione se nota un artefatto di bassa qualità ed in questo caso la produzione non riprende fino a quando tale difetto non sia stato risolto e non se ne siano comprese le cause. Questa continua ricerca di qualità e la responsabilizzazione di ogni sviluppatore garantisce che il mostro venga ucciso in poco tempo quando ancora piccolo e non quando avendo raggiunto dimensioni ciclopiche un suo abbattimento renderebbe necessario un dispendio di forze (=soldi) molto alto; per non parlare degli ingenti danni che tale mostro avrà compiuto durante la sua crescita.

Una delle armi più efficaci in mano agli sviluppatori per identificare il prima possibile questi difetti è l’enfasi su brevi cicli Test Sviluppo Refactoring, in Toyota come nello sviluppo del software.

Per applicare questi brevi cicli e per continuare a sognare il team non può permettersi compromessi, e non deve accettarli da parte dell’organizzazione e del management: sareste disposti a calpestare la vostra dignità e a vivere senza sogni?

Conosciamo bene l’importanza del feedback con il cliente da parte di chi sviluppa software, e quali siano gli strumenti per aumentare tale feedback.

Anche dal punto di vista del miglioramento continuo del processo e dell’efficacia delle pratiche è molto importante ricercare un feedback frequente. Il problema è: in che modo accorgerci se stiamo migliorando nell’efficacia delle soluzioni intraprese, o se invece stiamo regredendo? Altra domanda importante che si lega alla precedente: quali obiettivi porre al team o al project manager, valutabili su base oggettiva al fine di stimolare nel modo corretto ed efficace team e manager?

Read the rest of this entry »

Riporto tre link ad una discussione molto interessante che sta scorrendo su Internet relativamente al tema di cui sopra ed in particolare riguardo una delle pratiche fondamentali dell’extreme programming: il Test Driven Development e lo stress posto sui test. Penso sia degno di una lettura sia da parte degli agili-scettici, sia da parte di chi invece si ritenga un agilista.

In particolare il sasso è stato gettato dal seguente post:

Carlo Pescio critica il TDD

Le risposte di agilisti di primo ordine quali Marco Abis (tra i comments del post) e soprattutto Francesco Cirillo non si sono fatte attendere:

Francesco replica I

Francesco replica II

Anche se i post non sono brevissimi consiglio vivamente una lettura, non ve ne pentirete!

P.S.: purtroppo la discussione in alcuni tratti ha preso una piega un po’ troppo polemica…penso comunque rimangano ottimi spunti di riflessione.

Venerdì sera dopo aver postato i miei ultimi mini-articoli sul mio blog, li ho segnalati alla lista di discussione xp-it.

Sabato mattina con molto piacere ho trovato nella posta da leggere una mail di Gabriele Lana, coordinatore dell'XP User Group Milano, fondato da Francesco Cirillo. Gabriele oltre a fare i complimenti a me e a tutta la community, ha proposto una collaborazione tra la nostra piccola comunità e la loro (più ampia), sostanzialmente in tre possibili modalità:

• Il vostro gruppo potrebbe partecipare ai nostri incotri (sarebbe meraviglioso) [due mercoledì al mese]
• Il vostro gruppo potrebbe "saltuariamente" venire a trovarci, e in quelle occasioni potremmo metterci d'accordo per organizzare qualcosa di particolare
• Potremmo collaborare a distanza, potreste partecipare alla nostra lista, potresti creare un feed aggregato dei vostri blog (solo titolo/link) da forwardare in lista, ecc…

Ovviamente ciò non poteva che farmi piacere, fermo restando che personalmente non mi è facile andare a Milano così spesso. Per questo motivo ho proposto una collaborazione assidua a distanza (ad esempio tramite la loro mailing list ed i nostri blog), cercando di cogliere allo stesso tempo le occasioni "particolari" delle quali si potrebbe approfittare per incontrarsi tutti insieme.

La prima di queste sarà la Java Conference 2006 che si terrà il 27 ed il 28 Giugno a Milano, alla quale mi sono già iscritto per il 27 Giugno (il mio CEO ancora non lo sa ), e alla quale spero non sarò l'unico nostro rappresentante. Interverranno tra gli altri anche James Gosling e Francesco Cirillo, quindi anche per questo motivo penso sarà molto interessante.

Spero e credo fortemente possa essere l'inizio di una collaborazione proficua per entrambi i gruppi, soprattutto per le persone davvero molto valide che compongono l'xpug milanese.

Complimenti a tutta la community!

Ho sentito parlare più volte dell’importanza delle condivisione dei valori all’interno di un team. Fino a qualche giorno fa non ne avevo avuto esperienza diretta all’interno del team di sviluppo, e soprattutto non l’avevo vissuta sulla mia pelle. Negli ultimi due giorni ho invece avuto la fortuna di sperimentarlo, grazie ad una pratica che mi ha permesso di confrontarmi in modo molto stretto con il mio collega sviluppatore: il pair programming. Read the rest of this entry »