Talk comments

Anonymous at 22:58 on 17 Nov 2014

Qualche incertezza, ma l'attore é un lavoro difficile :)

Anonymous at 22:56 on 17 Nov 2014

Qualche difficoltà a seguire il codice, ma non saprei cosa consigliare

Anonymous at 22:55 on 17 Nov 2014

Anche se era la seconda volta che sentivo parlarne finalmente ho colto le sfumature
Dario

Anonymous at 22:52 on 17 Nov 2014

Era evidente la preparazione e lo studio dietro.
Ottimi i messaggi
Dario

Anonymous at 22:49 on 17 Nov 2014

Tempi giusti, buona organizzazione.
DARIO

Grazie per i commenti. Terremo in futuro più spazio per la parte più intuitiva dell'edilizia. La parte aziendale relativa a Breton mi rendo conto sia stata molto densa di contenuti. In futuro se dovessi ripeterla ne terrei conto.

Anonymous at 18:07 on 17 Nov 2014

Estremamente interessante, come l'altro talk che parlava di agile fuori da un contesto IT. Anche qui esempi concreti di applicazione/modellazione di principi e tecniche agili, col valore aggiunto di un contesto complesso nel caso Breton. L'esempio applicato all'edilizia merita il massimo punteggio, e anche più spazio nel talk.

Andrea, grazie del feedback.

Con l'alveare non volevo suggerire che i team siano o debbano essere omogenei (d'altronde neanche le api fanno tutte lo stesso mestiere). Volevo suggerire che in un alveare le api costruiscono un sistema complesso senza bisogno di un coordinamento centrale. In un team XP i novizi si inseriscono bene, ma non e' questo il problema piu' grosso che io vedo e di cui io volevo parlare.

Per il resto quello che ho raccontato e' in (gran) parte frutto di quello che ho imparato da altri, in parte frutto della mia esperienza. E' vero, ci sono organizzazioni che hanno successo anche senza usare metodi agili. In molti casi pero' si tratta di organizzazioni che vivono di semi-monopolio (vedi il famoso sito di Trenitalia).

Comunque, fino a che hai successo, non sono certo io a venirti a dire che devi cambiare. Io parlo per quelli che non riescono a portare a termine i progetti con successo, o a quelli che non riescono a fare sufficiente margine per tirare avanti, quelli che non sono piu' in grado di fare evolvere il loro codice legacy.

I metodi di cui racconto funzionano si' in pratica, e lo so dall'esperienza. Ma il punto del mio discorso e' che per farli funzionare in pratica bisogna fare fatica! Non si tratta di un proiettile d'argento che si possa facilmente adottare o comprare. Si' c'e' molta distanza fra teoria e pratica, e la maniera di migliorare, secondo me, e' di modificare la pratica per farla aderire il piu' possibile alla teoria.


Anonymous at 17:57 on 17 Nov 2014

E' la prima volta che assisto a un tuo talk. Non sono riuscito a seguire bene il filo del discorso e catturare i contenuti, in questo la presentazione mi è sembrata debole e non ho una conclusione finale. L'esposizione comunque è stata molto brillante e mi ha tenuto ben sveglio, e alla fine del secondo giorno non è poco.

Bravi, mi è piaciuto molto il formato e l'argomento è spinoso.
Sono contento che è emerso dal talk: "il programmatore non può essere uno schiaccia tasti, ma un Designer del codice". Sono anni che lo dico e sono felice che altri manifestino questa incomprensione della figura del programmatore.
Mancava solo un po' di più ritmo.