Italian Agile Day 2011
19 - 20 Nov 2011 at Università degli Studi Roma Tre, Dipartimento di Informatica e Automazione

Fabio, grazie alla sua grande esperienza, ci ha potuto presentare una sintesi di un vero e proprio universo.
Ci si poteva illudere che bastasse leggere un libro o fare 3 giorni di corso per pensare di esaurire un tema così vasto e dinamico (parliamo sempre di rapporti tra persone)?
Forse avrei dedicato un po' più di tempo alle domande dal pubblico: è un piacere sentire Fabio spaziare da un tema all'altro mostrando sempre grande competenza e capacità di spiegare in maniera comprensibile.

Uno dei talk più interessanti e "partecipati" tra quelli dei 4 agile day a cui ho assistito.
Il punto di vista di Gabriele centrato sullo sviluppatore e sulla sua etica professionale è da me totalmente condiviso e penso varrebbe la pena traslarlo in altri campi per riportare maggiore focus proprio sull'etica della persona.
Diffonderò sicuramente la registrazione del talk: qualcuno ha già il link sotto mano?
Quando saranno disponibili le slide?

Questo è stato il mio 4 agile day e quello di Paolo probabilmente il miglior keynote che ho seguito. Personalmente mi sono divertito molto dall'inizio alla fine e non ho notato particolari "cali".
Secondo me è stato azzeccatissimo proporre "luoghi comuni e concetti banali" probabilmente tali per i "vecchi" dell'agile day ma probabilmente non tali per chi si avvicinava da poco ai temi dello sviluppo agile (ma non era forse anche questo uno degli obbiettivi del keynote?).
Proporrò sicuramente la visione della sessione registrata ad un po' di colleghi!

Gente, vi do la mia personale interpretazione di questo intervento, senza pretendere di parlare per Francesco. Fatto: se proviamo a leggere un qualsiasi libro in tema Metodi Agili, si dà per assodato che usando i Metodi Agili si diventa più bravi.

La realtà dei fatti, che ho personalmente riscontrato nelle mie esperienze, è che spesso questo /non è vero/. Diversi team agili di mia conoscenza hanno fallito progetti, o comunque hanno conseguito una fama di essere troppo cari. Fama immeritata? Che importa! Se il risultato finale è che il cliente non ti sceglie più hai fallito. E poi è facile che la fama non sia poi così immeritata.

E' vero che molte pratiche agili producono un beneficio immediato; quel problema che facevi fatica a debuggare si risolve brillantemente con gli unit test, la comunicazione con il cliente migliora se andiamo a chiedergli che cosa pensa veramente, ecc. ecc. MA! Ci vuole molta, molta fatica per rendere questi benefici permanenti. E' sulla distanza che si vede la differenza.

Tanti che credono di programmare a oggetti scrivono invece codice procedurale, e la differenza sulla distanza si traduce in codice ingarbugliato. Tanti che hanno capito che non devono fare big design upfront, non hanno capito che devono però fare tanto design in maniera continua. E magari non sarebbero in grado di farlo neanche se volessero, il design upfront, né big né small. E poi ci vuole tanto coraggio per continuare a mantenere il contatto con il cliente nel lungo periodo.

Kent Beck ha detto "What does it mean to be agile? My definition is that you accept input from reality and you respond to it”. Allora facciamola per davvero questa follia di accettare l'input dalla realtà! Misuriamo quanto ci costa sviluppare. E' da qui che si vede se quello che facciamo funziona veramente.

E già che ci siamo, da quanto tempo non andiamo dal cliente a chiedergli "sei contento di come lavoriamo?"

(Solo 4 thumbs up perché sono d'accordo che i grafici presentati da Francesco sarebbero stati più interessanti se corredati da numeri.)

Che dire. Gabriele rocks!

cari Anonimi, il mio intervento è iniziato con queste precise parole: "Il talk non vuole insegnare una metodologia di lavoro, nasce da esperienze personali e si riflette su situazioni personali. Non è detto che la strada intrapresa sia la migliore, la più agevole o la più redditizia. E’ semplicemente una strada che porterà, probabilmente, ad un nuovo percorso di crescita, di adattamento e di revisione."

Come ho più volte spiegato e ripetuto, non volevo vendere una metodologia, non volevo vendere certezze ma volevo fare un case study sulla mia personale esperienza.

Per quanto riguarda il "fatto" della telecamere chiedo venia a tutti, tensione, stanchezza ed un filo di provocazione in sala non mi hanno fatto brillare per lucidità.. lo ammetto. Ma, ripeto, non sono un ottimo commerciale.. avrei potuto fare i nomi (poi non dati neanche in sala) e bullarmene allegramente ;).

Detto questo, chiederei agli anonimi di presentarsi ed eventualmente farmi una critica costruttiva su come migliorare il talk, "rispetto" e "sincerità" mi paiono indispensabile per definirsi "agili".

Quoto Jacopo, nel talk ho trovato diverse conferme e alcuni spunti interessanti

Ottimo intervento, machevelodicoafare. Ho intravisto alcuni punti citati anche da Martin in "The Clean Coder". Molto interessante anche la discussione finale.

Il miglior intervento tra quelli che ho visto allo iad

Concordo con Filippo e Daniel. Bel talk, punto.

Buona introduzione generale all'argomento, che dopo una panoramica dei vari aspetti che si nascondono dietro alla parola "devops", si concentra sugli strumenti a supporto di queste pratica.

Su quella parte avrei preferito qualche dettaglio in più rispetto ad una semplice carrellata, magari con qualche esempio, per far capire meglio di cosa si sta parlando.