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

Bellissimo come talk "emozionale", mi sarebbe piaciuto un approfondimento anche dal lato puramente economico (o con la teoria dei giochi) per cercare di capire perche' le cose stanno cosi' e come si puo' arrivare ad una situazione in cui convenga a tutti rompere il cerchio.

Molto ben fatto e chiaro, e ricco di spunti e grafici da proporre ai manager per coinvolgerli davvero nelle tematiche di lavoro.

bene: il tipo di esercizio e il modo in cui e' stato condotto.
Migliorabile: c'e' il pantano, ed impariamo ad uscirne, ma ricordiamoci che a volte (anzi spesso) abbiamo a che fare proprio con le sabbie mobili!

Ho apprezzato molto la prima parte del talk (modelli evolutivi), era tutto molto chiaro e puntuale. Inoltre, le slide erano perfettamente in armonia con la lezione.

La seconda parte è stata deludente. Si è voluto utilizzare il risultato di una ricerca (l'andamento dei costi di un team di sviluppo) per rispondere alla domanda cardine sui costi, ma senza specificare come è stata eseguita tale ricerca e nessun riferimento per un eventuale approfondimento.

Davvero un bel talk, grazie Claudio!

Bello,

peccato solo che i non javisti sono rimasti spiazzati dalla bruttura del codice nella seconda metà :-)

1) team agili costano più di quelli non agili e il risultato è misurato dalle esperienze dirette di Francesco.
Credo sia importante fermarsi su questo pensiero per un momento. Io domani chiederò un aumento come il normale corso delle cose. La qualità ha un costo, ma se costa troppo forse non è qualità. In medio stat virtus è un proverbio latino.

2) Dobbiamo sempre capire dove siamo e rimetterci in discussione e perché no analizzare bene quale è il nostro processo di sviluppo, mi ritrovo nelle slide di Francesco, con "parecchio" design upfront. Anche se non ho paura di cambiarlo, nei progetti solitamente piano piano il design diventa un zoccolo duro e ha un costo anche il solo pensarlo "flessibile al 100%".

3) Sicuramente trovo più da riflettere su questo talk che su altri, in particolare mi ritrovo spaesato su alcuni concetti come inseguire i principi solid è sbagliato se fatto a priori che poi il design migliore emergerà e quindi anche i buoni principi. Anche se trovo qualcosa di contorto in questa frase (che ammetto che è una mia personale sintesi), credo sia la definizione di design emergente a far uscire questi concetti. Lo stesso si può dire di refactoring, design pattern e grasp.

Mia conclusione:
C'è un qualcosa di contorto che spesso sento dal movimento agile.
O meglio io credo che noi programmatori dobbiamo lavorare per fare i soldi, e non per fare codice di qualità.

Produrre codice di qualità è il mezzo con cui lavoriamo, perché crediamo che favorisca il nostro lavoro e avere quindi un ROI migliore. Però non è la regola e non deve essere un vincolo del team, perché se il ROI peggiora stiamo sbagliando obiettivo.

quando si viene ad un evento del genere, c'è sempre l'imbarazzo della scelta. Si fa fatica a scartare qualche intervento che ha lo stesso orario di qualcun'altro. Io sono molto contenta di aver seguito questo. Camelia

è bello sentir parlare di etica in un mondo, quello della programmazione, sopraffatto dal principio del "buon mercato" (per quanto riguarda stipendio, tariffa, orario ecc.)... Camelia Boban

bene: la riflessione sulla differenza tra inventario e valore rilasciato effettivamente
migliorerei: la connessione logica tra la premessa di cui sopra e la conclusione suggerita dal titolo del talk.