Uncovering better ways of developing software
Il mio pensierino per il result day
Ne approfitto per tirare un po' le somme anche sull'evento.
Sul XP Day.
Dal punto di vista dell'organizzazione logistica, mi sembra che sia andata discretamente, senza macchia ne lode: la partecipazione e' stata buona e lo svolgimento regolare con i soliti intoppi, aggravati dal numero elevato di persone. Pero' e' andata.
Sulla “natura” della giornata confermo il mio solito dubbio: mi sembra che ci siano due anime in competizione, la necessita' di un evento italiano di divulgazione e consolidamento delle metodologie agili ed il sacrosanto bisogno della comunita' agile di incontrarsi. Per me bisognerebbe fare una due giorni con momenti distinti: un convegno “classico” a pagamento con tutorial, workshop, relatori pagati … ed una giornata della comunita' dove trovarsi. Questi eventi possono essere integrati in una 2-3 gg.
Sugli interventi, a mente fredda, direi che su una scala 1-10, siamo sul 6+ con punte di 8.
La sensazione che mi e' rimasta e' che le metodologie agili sono oggettivamente mainstream, chi non le conosce puo' essere tacciato di ignoranza, chi non le usa si giustifica (cose che solo due anni fa non erano ovvie). Forse manca una vera ingegnerizzazione delle pratiche, sentendo alcuni interventi ho avuto la sensazione che fossero ancora considerate “nuove e sperimentali”.
Team.
I ragazzi che sono venuti sono tornati convinti e carichi, e questo e' molto bene. In particolare sono piu' propositivi, hanno tirato fuori alcune idee veramente valide. Grazie a questo abbiamo una C.I. con coverage e risultati on-line sul Trac di progetto. Questo non e' vero per tutti: alcuni si sono fatti una gita e non gli e' servito a nulla (sembra). Per il resto la vita continua come al solito: stand-up meeting, paring, TDD … ed e' questo per me il valore maggiore: la metodologia non e' piu' oggetto di discussione distruttiva, ma una base su cui migliorare, anche mettendola in discussione.
Un aspetto negativo: dopo l'iniziale entusiasmo di due anni fa, i manager hanno snobbato la conferenza “e' una cosa da tecnici”. Questo e' male, molto male. Infatti non partecipano quasi piu' alle verifiche e cominciamo ad avere i primi problemi di "specifiche” non capite. Questa cosa e' dannosissima e sto cercando di correggerla (leggi: estirparla).
Inoltre, in seguito alle belle idee della conferenza, oltre al normale lavoro, sono stato incaricato di introdurre un po' piu' di agile nello sviluppo della parte embedded C del progetto. Siamo all'inizio ed e' molto dura, ma … per aspera ad astra!
Sul XP Day.
Dal punto di vista dell'organizzazione logistica, mi sembra che sia andata discretamente, senza macchia ne lode: la partecipazione e' stata buona e lo svolgimento regolare con i soliti intoppi, aggravati dal numero elevato di persone. Pero' e' andata.
Sulla “natura” della giornata confermo il mio solito dubbio: mi sembra che ci siano due anime in competizione, la necessita' di un evento italiano di divulgazione e consolidamento delle metodologie agili ed il sacrosanto bisogno della comunita' agile di incontrarsi. Per me bisognerebbe fare una due giorni con momenti distinti: un convegno “classico” a pagamento con tutorial, workshop, relatori pagati … ed una giornata della comunita' dove trovarsi. Questi eventi possono essere integrati in una 2-3 gg.
Sugli interventi, a mente fredda, direi che su una scala 1-10, siamo sul 6+ con punte di 8.
La sensazione che mi e' rimasta e' che le metodologie agili sono oggettivamente mainstream, chi non le conosce puo' essere tacciato di ignoranza, chi non le usa si giustifica (cose che solo due anni fa non erano ovvie). Forse manca una vera ingegnerizzazione delle pratiche, sentendo alcuni interventi ho avuto la sensazione che fossero ancora considerate “nuove e sperimentali”.
Team.
I ragazzi che sono venuti sono tornati convinti e carichi, e questo e' molto bene. In particolare sono piu' propositivi, hanno tirato fuori alcune idee veramente valide. Grazie a questo abbiamo una C.I. con coverage e risultati on-line sul Trac di progetto. Questo non e' vero per tutti: alcuni si sono fatti una gita e non gli e' servito a nulla (sembra). Per il resto la vita continua come al solito: stand-up meeting, paring, TDD … ed e' questo per me il valore maggiore: la metodologia non e' piu' oggetto di discussione distruttiva, ma una base su cui migliorare, anche mettendola in discussione.
Un aspetto negativo: dopo l'iniziale entusiasmo di due anni fa, i manager hanno snobbato la conferenza “e' una cosa da tecnici”. Questo e' male, molto male. Infatti non partecipano quasi piu' alle verifiche e cominciamo ad avere i primi problemi di "specifiche” non capite. Questa cosa e' dannosissima e sto cercando di correggerla (leggi: estirparla).
Inoltre, in seguito alle belle idee della conferenza, oltre al normale lavoro, sono stato incaricato di introdurre un po' piu' di agile nello sviluppo della parte embedded C del progetto. Siamo all'inizio ed e' molto dura, ma … per aspera ad astra!
Visualizzazioni: 11
Risposte a questa discussione
-
Permalink Risposto da Ste su -
Ciao Roberto, a proposito di "e' una cosa da tecnici", come stai cercando di risolverlo (o meglio estirparlo? ;) )
E' un aspetto fondamentale in ambienti non banali perche' quando hai a che fare con centinaia di US, molte possono essere di un dettaglio tale che diventano davvero cose da tecnici. Il PO inizia quindi a sentirsi un po' perso. Come stai affrontando il problema?
Ste
-
Permalink Risposto da Roberto Bettazzoni su -
Ciao,
penso di estirparlo con la sincerita'.
I manager devono capire che giochiamo nella stessa squadra e che la fiducia e' tutto.
Se stiamo parlando di "cose da tecnici" che non gli interessano devono dirlo apertamente e noi non dobbiamo offenderci, ma valutare se e' veramente una cosa nostra o se ha impatto anche sul businnes. In questo caso dobbiamo spiegarlo in italiano comprensibile (e se non ci dovessimo riuscire vuole dire che non abbiamo capito bene la questione. E' colpa nostra non del manager!)
|Nel caso che la questione non abbia impatto businness il PO deve andarsene. Dopo un po' di "buche" dovremmo riuscire a valutare la natura delle US in anticipo e non vessarlo piu' di tanto.
Ok, non e' facile e non puo' funzionare con tutti. Ho in mente 2 o 3 personaggi che non possono farcela, ma questo deve essere chiaro e condiviso. (leggi: il PO deve avere pazienza, le interfacce con il PO devono essere cordiali e parlare bene in italiano. Niente orsi da codice :-) )
Se funziona, il vantaggio che ne avra' il PO portera' naturalmente gli altri manager a seguirlo o a considerarlo migliore, il che, per me e' lo stesso.
Non mi viene in mente una soluzione duratura diversa.
© 2013 Creato da Marco.
