Grazie a Tim e Ilias il 23 all'Agile Day ho rivisto il disegno di
Kent Beck che mostra come le pratiche si sostengono a vicenda (
http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/luKa/516/o_pract
ices_net.jpg ).


L'equivoco lo trovo nei team che cominciano ad applicare XP pure con
buon successo e si danno da subito l'obiettivo di adattare XP alle
proprie esigenze  - azienda/team/cliente -  tralasciando pratiche,
inventando nuove pratiche, non provando  la condivisione e
organizzazione base dei compiti e responsabilità (tra scrum master,
product owner e ream member o tra coach, team membere e cliente).
Questo prima di aver provato _una_volta_ ad applicare insieme
_tulle_le_pratiche_e_l'organizzazione_ standard.

Trovo che questo equivoco può portare alla convinzione di fare XP o
Scum quando in realtà non lo si stà facendo - ok chiaro
ecccchisssenefrega se non è XP col bollino! - il punto è che IMHO si
perde anche la possibilità di trarre benefici ormai a portata di mano
e invece ci si avventura alla ricerca di altre soluzioni più
complicate.



La tesi che più mi convince è che una volta bisogna provare con
successo tutto insieme "come da libro" e dopo si può/deve cominciare
ad adattare XP/Scrum analizzando il feedback e individuando le azioni
ad esempio con le Retrospective. Questo dovrebbe essere l'obiettivo
quando si comincia un passo alla volta a partire dalla pratica che da
più valore al cliente.

Successivamente - appreso e sperimentato quel senso di equilibrio
complessivo tra tutte le pratiche - si può/deve iniziare ad adattare
XP/Scrum alla propria specifica realtà azienda/team/cliente.



Vedete anche voi questo equivoco? Oppure credere che XP-but e Scrum-
but sia il modo giusto di applicarlo piuttosto che sempre e
solo "come da libro" ?

Uhm...argomento interessante.

Ti espongo prima la mia situazione verso XP:
come consulente da sbarco, saltello spesso da un progetto all'altro, e
ogni volta mi trovo di fronte a problemi e ambienti diversi. Per me XP
è un'ottima cassetta degli attrezzi: a seconda della situazione cerco
"i frutti bassi" e li colgo:
- se il team comunica poco spingo per metter tutti nella stessa stanza
e propongo stand up meeting
- se il livello di bug è alto la collective code ownership, il TDD e
l'introduzione di un sistema di versioning fanno miracoli
- se c'è turnover forte nel team il pair programming riduce il rischio
di trovarsi senza la persona che sa come riavviare il db

E, cribbio, funziona. Non mi capita mai di darmi come obiettivo
diretto l'introduzione completa e in blocco di XP: ho la sensazione
che la resistenza sarebbe troppa, e che userei energie in direzioni
che in quel momento non convengono. Penso che SE tutto continuasse ad
evolvere potrei arrivare ad introdurre tutte le pratiche, ma non mi
deprimo se non ci riesco :)

E, ovviamente, introducendo le pratiche un po' per volta ti trovi ad
accumulare esperienze che te le fanno modificare. In un progetto con
un forte bagaglio di bachi ci siamo resi conto che la caccia al baco
in pair non rendeva: l'intuito di due persone spesso lavora in
direzioni diverse, e la collaborazione era difficile. Si è rivelato
molto meglio puntare sulla caccia "parallela" al baco: sia tu che io
lo cerchiamo, e una volta trovato ci ricompattiamo per fissarlo. E
applicare un ragionamento del genere senza che si generi agonismo nel
team per me è agilità :)

Per dare una risposta  alla tua domanda: Se dovessi avviare un team da
zero, avendo nel team una base di consenso per partire con XP, lo
farei :)
Partendo invece da realtà già esistenti mi trovo più propenso ad un
approccio graduale.Le pratiche vanno apprese e metabolizzate. Il
cambiamento ingenera stress e fatica: può essere più semplice
apprendere le basi del TDD in solitudine e poi applicarle in pair.
Oppure prima abituarsi alle tre domande dello stand up e POI portarsi
il customer on site :)

Ammetto candidamente i miei due vantaggi nella seconda situazione:
- è spesso facile arrivare  in un ufficio e con l'occhio dell'esterno
individuare le migliorie più convenienti
- nonostante non abbia mai lavorato su un progetto con tutte le
pratiche applicate contemporaneamente, tra milano xpug e agile day ho
a disposizione esperienze che, anche se non purtroppo non dirette,
danno una "mira" migliore nel valutare quali pratiche convengono e
quali "personalizzazioni" siano covi di complessità controproducente.

Sono d'accordo con te che si debba agire con cautela, pena perdere "la
possibilità di trarre benefici ormai a portata di mano e invece ci si
avventura alla ricerca di altre soluzioni più complicate".
Tra l'altro, le retrospettive che io userei per cautelarmi  non sono
una pratica core di XP :)


On Dec 2, 2007 9:04 PM, lucaminudel <lminudel@...> wrote:
>
>
>
>
>
>
> Grazie a Tim e Ilias il 23 all'Agile Day ho rivisto il disegno di
>  Kent Beck che mostra come le pratiche si sostengono a vicenda (
>  http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/luKa/516/o_pract
>  ices_net.jpg ).
>
>  L'equivoco lo trovo nei team che cominciano ad applicare XP pure con
>  buon successo e si danno da subito l'obiettivo di adattare XP alle
>  proprie esigenze - azienda/team/cliente - tralasciando pratiche,
>  inventando nuove pratiche, non provando la condivisione e
>  organizzazione base dei compiti e responsabilità (tra scrum master,
>  product owner e ream member o tra coach, team membere e cliente).
>  Questo prima di aver provato _una_volta_ ad applicare insieme
>  _tulle_le_pratiche_e_l'organizzazione_ standard.
>
>  Trovo che questo equivoco può portare alla convinzione di fare XP o
>  Scum quando in realtà non lo si stà facendo - ok chiaro
>  ecccchisssenefrega se non è XP col bollino! - il punto è che IMHO si
>  perde anche la possibilità di trarre benefici ormai a portata di mano
>  e invece ci si avventura alla ricerca di altre soluzioni più
>  complicate.
>
>  La tesi che più mi convince è che una volta bisogna provare con
>  successo tutto insieme "come da libro" e dopo si può/deve cominciare
>  ad adattare XP/Scrum analizzando il feedback e individuando le azioni
>  ad esempio con le Retrospective. Questo dovrebbe essere l'obiettivo
>  quando si comincia un passo alla volta a partire dalla pratica che da
>  più valore al cliente.
>
>  Successivamente - appreso e sperimentato quel senso di equilibrio
>  complessivo tra tutte le pratiche - si può/deve iniziare ad adattare
>  XP/Scrum alla propria specifica realtà azienda/team/cliente.
>
>  Vedete anche voi questo equivoco? Oppure credere che XP-but e Scrum-
>  but sia il modo giusto di applicarlo piuttosto che sempre e
>  solo "come da libro" ?
>
>



--
Fabio Bertone
fabio.bertone@...
http://www.fabiobeta.it

[cut]

>  La tesi che più mi convince è che una volta bisogna provare con
>  successo tutto insieme "come da libro" e dopo si può/deve cominciare
>  ad adattare XP/Scrum analizzando il feedback e individuando le azioni
>  ad esempio con le Retrospective. Questo dovrebbe essere l'obiettivo
>  quando si comincia un passo alla volta a partire dalla pratica che da
>  più valore al cliente.

Sono d'accordo con quello che ha scritto Fabio (e quindi non lo ripetero'),
ma forse Fabio si è perso il pezzo qui sopra: se ho capito bene tu non sei
per introdurre "a bomba" tutte le pratiche, ma per direzionare l'evoluzione
del team verso tutte le pratiche. Ho capito bene?

>  Successivamente - appreso e sperimentato quel senso di equilibrio
>  complessivo tra tutte le pratiche - si può/deve iniziare ad adattare
>  XP/Scrum alla propria specifica realtà azienda/team/cliente.
>
>  Vedete anche voi questo equivoco? Oppure credere che XP-but e Scrum-
>  but sia il modo giusto di applicarlo piuttosto che sempre e
>  solo "come da libro" ?

Penso che il metodo "migliore" per un team che sviluppa un progetto
dipenda dal team e dal progetto. Questo potrebbe voler dire discostarsi
molto da XP/Scrum/Altro oppure no

Potrebbe valere la pena di attingere solo dalle pratiche di XP quando
si cerca la soluzione ad un problema e quindi potrebbe valere la pena
di spingere il team per "tendere" ad XP nella sua completezza

Sinceramente non l'ho mai fatto, la cosa che mi preoccupa di più non
è tanto "la foto XP", ovvero l'integralismo, ma la complessità/fattibilità
delle
pratiche proposte (ex. TDD/Customer on site). Ho paura di trovarmi a
dedicare troppe energie al problema sbagliato (introdurre XP vs
migliorare la produttività+qualità)

Mettiamola così, non tutti possono applicare con successo XP, ma tutti
possono migliorare grazie ad XP, anche se alla fine quello che viene
fuori non lo si può chiamare XP [*]

[*] Qui poi possiamo aprire un dibattito su cosa si può chiamare XP,
in quanto l'insieme delle pratiche è lo strato superficiale e più debole
di XP, togliere e/o aggiungere una o più pratiche non è così traumatico
come violarne apertamente i principi e i valori. Quindi quando Tim
parlava di XPbut si riferiva soltanto alle pratiche, e i prindipi? E i valori?
Se segui tutti i principi/valori di XP e non ne applichi nessuna pratica,
stai facendo ancora XP?

--
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it - Agile methodologies and Programming
http://www.xpug.it - italian eXtreme Programming User Groups

Grazie a Tim e Ilias il 23 all'Agile Day ho rivisto il disegno di
Kent Beck che mostra come le pratiche si sostengono a vicenda (
http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/luKa/516/o_pract
ices_net.jpg ).

L'equivoco lo trovo nei team che cominciano ad applicare XP pure con
buon successo e si danno da subito l'obiettivo di adattare XP alle
proprie esigenze - azienda/team/cliente - tralasciando pratiche,
inventando nuove pratiche, non provando la condivisione e
organizzazione base dei compiti e responsabilità (tra scrum master,
product owner e ream member o tra coach, team membere e cliente).
Questo prima di aver provato _una_volta_ ad applicare insieme
_tulle_le_pratiche_e_l'organizzazione_ standard.

Trovo che questo equivoco può portare alla convinzione di fare XP o
Scum quando in realtà non lo si stà facendo - ok chiaro
ecccchisssenefrega se non è XP col bollino! - il punto è che IMHO si
perde anche la possibilità di trarre benefici ormai a portata di mano
e invece ci si avventura alla ricerca di altre soluzioni più
complicate.

La tesi che più mi convince è che una volta bisogna provare con
successo tutto insieme "come da libro" e dopo si può/deve cominciare
ad adattare XP/Scrum analizzando il feedback e individuando le azioni
ad esempio con le Retrospective. Questo dovrebbe essere l'obiettivo
quando si comincia un passo alla volta a partire dalla pratica che da
più valore al cliente.

Successivamente - appreso e sperimentato quel senso di equilibrio
complessivo tra tutte le pratiche - si può/deve iniziare ad adattare
XP/Scrum alla propria specifica realtà azienda/team/cliente.

Vedete anche voi questo equivoco? Oppure credere che XP-but e Scrum-
but sia il modo giusto di applicarlo piuttosto che sempre e
solo "come da libro" ?

Ciao a tutti,

aggiungo i miei 2 centesimi al thread.
Il messaggio di Tim riguardo a XP-but e Scrum-But e' stato una delle
cose che mi sono piaciute di piu', in particolare la metafora del
golf. Calandola nella mia realta' io la leggo cosi': e' ovvio che non
posso pensare di applicare XP per intero nella mia realta' fin dal
giorno zero, perche' sarebbe un cambiamento troppo grosso. E' ovvio
che il processo di adozione sara' incrementale, e agile (c'e' una
sorta di autoreferenzialita' frattale qui... simpatico).
Pero', quello che _non_ ha senso, e' pensare fin dal giorno zero che
nella mia realta' fra n giorni io faro' xp, TRANNE la tal pratica x, o
la tal altra pratica y, per questo o quell'altro motivo. Il fatto che
le pratiche siano tra loro intercorrelate e si auto-sostengano e' un
fatto provato e indiscutibile. Quindi e' "stupido" non mirare fin dal
primo momento al green, alla situazione ideale, all'eventuale adozione
di TUTTE le pratiche, anche se questo richiedera' tanto tempo. Se
nell'immediato so che non potro' applicare una certa pratica, non e'
su quella mancata applicazione che dovro' concentrarmi, ma
sull'applicazione delle pratiche che invece mi sono accessibili. In
altre parole, pensa positivo (o meglio propositivo), non negativo.

Stefano

On 12/3/07, Martino Vallara <martino.vallara@...> wrote:
> Non sono d'accordo con quanto hai scritto, perchè se un'azienda  ha la capacià
di fare feedback e di fare scelte di processo che crede possano  aumentare la
propria produttività (come hai indicato tu) questa capacità la può  e la deve
esercirare sempre e al più presto, contiunandosi a correggere. Quindi  se seglie
di fare XP-But propabilmente, nel suo processo alla ricerca della  maggior
produttività, è migliore di XP puro.

>  aggiungo i miei 2 centesimi al thread.
>  Il messaggio di Tim riguardo a XP-but e Scrum-But e' stato una delle
>  cose che mi sono piaciute di piu', in particolare la metafora del
>  golf. Calandola nella mia realta' io la leggo cosi': e' ovvio che non
>  posso pensare di applicare XP per intero nella mia realta' fin dal
>  giorno zero, perche' sarebbe un cambiamento troppo grosso. E' ovvio
>  che il processo di adozione sara' incrementale, e agile (c'e' una
>  sorta di autoreferenzialita' frattale qui... simpatico).
>  Pero', quello che _non_ ha senso, e' pensare fin dal giorno zero che
>  nella mia realta' fra n giorni io faro' xp, TRANNE la tal pratica x, o
>  la tal altra pratica y, per questo o quell'altro motivo. Il fatto che
>  le pratiche siano tra loro intercorrelate e si auto-sostengano e' un
>  fatto provato e indiscutibile. Quindi e' "stupido" non mirare fin dal
>  primo momento al green, alla situazione ideale, all'eventuale adozione
>  di TUTTE le pratiche, anche se questo richiedera' tanto tempo. Se
>  nell'immediato so che non potro' applicare una certa pratica, non e'
>  su quella mancata applicazione che dovro' concentrarmi, ma
>  sull'applicazione delle pratiche che invece mi sono accessibili. In
>  altre parole, pensa positivo (o meglio propositivo), non negativo.

E' proprio qui che sta il mio problema, dai per scontato che l'obiettivo
sia di implementare tutte le pratiche, perchè?

Perchè è "provato" che funzionino meglio insieme? Può anche darsi,
ma vorrei arrivarci da solo (leggi: vorrei che i miei team ci arrivassero
da soli), ma vorrei arrivarci puntando agli obiettivi di business del mio
cliente e al benessere del mio team, se poi arriviamo a tutte le pratiche
di XP bene, sarà un'ulteriore riprova della bontà sinergica delle pratiche,
altrimenti siamo felici lo stesso :-)

Insomma non vorrei includere/escludere a priori nessuna pratica che
possa aiutarmi  a raggiungere i miei veri obiettivi

--
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it - Agile methodologies and Programming
http://www.xpug.it - italian eXtreme Programming User Groups

On 12/3/07, Gabriele Lana <gabriele.lana@...> wrote:
>  E' proprio qui che sta il mio problema, dai per scontato che l'obiettivo
>  sia di implementare tutte le pratiche, perchè?
>
>  Perchè è "provato" che funzionino meglio insieme? Può anche darsi,
>  ma vorrei arrivarci da solo (leggi: vorrei che i miei team ci arrivassero
>  da soli), ma vorrei arrivarci puntando agli obiettivi di business del mio
>  cliente e al benessere del mio team, se poi arriviamo a tutte le pratiche
>  di XP bene, sarà un'ulteriore riprova della bontà sinergica delle pratiche,
>  altrimenti siamo felici lo stesso :-)

Certo. Infatti, come dice giustamente Simone, quasi sicuramente al
green non ci si arriva con un colpo solo. L'importante e' _mirare_.

>  Insomma non vorrei includere/escludere a priori nessuna pratica che
>  possa aiutarmi  a raggiungere i miei veri obiettivi

Direi che siamo daccordo allora.

Quello che mi e' piaciuto leggere nell'intervento di Tim e' stato che
non ha senso concentrarsi e perdere tempo nel motivare perche' e per
come il customer on-site, per dirne una, nel mio team non trovera' MAI
posto, anche se sara' cosi'. Non ha senso trovare una motivazione
fondazionale sulla carenza di questa pratica. E' una carenza e sempre
lo sara'. Se poi ci devo convivere, pazienza. Ma devo essere coscente
del fatto che e' una carenza, e mi conviene investire il mio tempo nel
cercare di migliorare le pratiche che sono alla mia portata, tenendo
presente che se potessi attuarle tutte sarebbe il massimo.

Stefano

ho letto con attenzione le risposte di Fabio, Gabriele, Simone,
martino e Stefano e mi trovo molto d'accordo sul fatto di  procedere
nell'adizione a piccoli passi scegliendo quelli che danno + valore al
cliente e che sono realistici nel team in cui si lavora.

è trovo un bel segno di maturità l'attenzione al valore consegnato al
utente/cliente

ho capito bene vero ?




c'è un altro punto su cui ho ancora questo dubbio :

ipotesi : procedendo in questo modo dopo molti mesi arriva il giorno
in cui ci sebbra una buona idea inventare una nuova pratica e/o
personalizzare pesantemente una  pratica o parte del processo.

non ho ancora provato - nemmeno a livello ditattico - l'esperienza di
equilibrio nel usare insieme le pratiche standard e l'organizzazione
standard e non ho con me un coach che lo ha fatto.

=>
A) mi avventuro lo stesso in questo adattamento/tailoring avanzato
con molta attenzione e opportune retrospetcive
oppure ...
B) prima do una chance all'approccio standard completo e dopo con
l'esperienza fatta passo all'adattamento/tailoring avanzato
oppure ...
C) - la preferita da Pier F. Loche :D - chiedo aiuto a un coach che
ha già sperimentato l'equilibrio di tutte le forze in gioco (tutte le
pratiche standard) e mi può aiutare nel procedere con questo
adattamento/tailoring avanzato

???

>  Quello che mi e' piaciuto leggere nell'intervento di Tim e' stato che
>  non ha senso concentrarsi e perdere tempo nel motivare perche' e per
>  come il customer on-site, per dirne una, nel mio team non trovera' MAI
>  posto, anche se sara' cosi'. Non ha senso trovare una motivazione
>  fondazionale sulla carenza di questa pratica. E' una carenza e sempre
>  lo sara'. Se poi ci devo convivere, pazienza. Ma devo essere coscente
>  del fatto che e' una carenza, e mi conviene investire il mio tempo nel
>  cercare di migliorare le pratiche che sono alla mia portata, tenendo
>  presente che se potessi attuarle tutte sarebbe il massimo.

Aggiungo che mi piacerebbe anche che si sapesse il perchè vogliamo
il customer on-site, ovvero se riesco ad ottenere *tutti* i vantaggi della
pratica applicandone un'altra mi piacerebbe non inseguire qualcosa
che mi darebbe gli stessi risultati che sto già ottenendo

Mi rendo conto che il pericolo di adattarsi troppo ad un ambiente che
potenzialmente potrebbe essere disfunzionale è alto, ma i coach esistono
per quello :-)

--
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it - Agile methodologies and Programming
http://www.xpug.it - italian eXtreme Programming User Groups

concordo con le tue conclusioni  .


la curiosità che mi resta riguarda i prerequisiti di esperienza
consigliati prima di adattare/personalizzare pratiche e processi XP

cioè durante l'adozione graduale di XP in un ipotetico team (su
gradualità e modalità dalle risposte devo che siamo tutti allineati)
pensi che sia conveniente provare almeno una volta l'esperienza di
vedere (quasi) tutte le pratiche in azione e il modo in cui si
sostendono
(http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/luKa/516/o_practi
ces_net.jpg) oppure ritieni sia conveniente adattare/personalizzare
pratiche e processo già da subito prima ancora di avere provato le cose
standard ?

[cut]
>  concordo con le tue conclusioni .
[cut]

Visto che non sembra possibile controllare il subject delle mail
in modo che vengano ordinate correttamente, ti chiedo se per lo
meno è possibile quotare il testo a cui ti riferisci in modo che anche
gli altri possano capire a chi ti stai riferendo

Grazie :-)

--
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it - Agile methodologies and Programming
http://www.xpug.it - italian eXtreme Programming User Groups

On Monday 03 December 2007, lucaminudel wrote:
> A) mi avventuro lo stesso in questo adattamento/tailoring avanzato
> con molta attenzione e opportune retrospetcive
> oppure ...
> B) prima do una chance all'approccio standard completo e dopo con
> l'esperienza fatta passo all'adattamento/tailoring avanzato
> oppure ...
> C) - la preferita da Pier F. Loche :D - chiedo aiuto a un coach che
> ha già sperimentato l'equilibrio di tutte le forze in gioco (tutte le
> pratiche standard) e mi può aiutare nel procedere con questo
> adattamento/tailoring avanzato

io preferisco la "A" e con coraggio, ma bisogna sapere dove si sta tirando!!


...a parte la risposta sopra... volevo aggiungere una sfumatura che mi era
venuta in mente quando Tim parlava del golf.

Qualcuno tempo fa mi aveva insegnato che le "persone" sono degli oggetti con
una strana proprietà fisica: tu puoi spingerle fortemente in una direzione,
indicargli l'obbiettivo, inclinare il terreno in discesa ...ma a differenza
delle palle da biliardo (e da golf) non rispondono alle leggi fisiche e vanno
a finire sempre da un'altra parte.

Ciò che porta le persone a seguire la direzione indicata sono:
- comunicazione chiara,
- motivazione,
- fiducia,
- maturità delle persone,
- autorevolezza di chi indica la direzione

Questi elementi non li vendono al supermercato, non si inventano in pochi mesi
e nemmeno anni... però credo che un buona manager sia in grado di
capire "quanto" fanno parte di un team.

Più sono qualità radicate nel team e più e possibile tirare dritto e forte
verso il green!
Se ci sono in piccola quantità, magari meglio procedere per piccoli colpi per
non ritrovarsi nel laghetto...


Ilias
--
/**
  * Reply to: ilias.bartolini(at)gmail.com
  * ICQ# 42797710 - PGP Key-ID:0xC6867602
  * http://zatoichi.homeip.net - will write free code for food
  */

cioè dici  le persone prima che il processo ... una rappresentazione
diversa della questione


da questa prospettiva se fossi un jazzista sarei capace di vincere
con la (A) esplorando e improvvisando , se fossi un rugbysta sarei
capace di vincere con la (B) allenamento preparazione e cuore, se
fossi un judoca con la (C) disciplina e insegnamenti dal maestro

modi diversi e ugualmente plausibili

ogniuno nel team ha il proprio stile personale ( personalmente sono
un ex rugbysta e judoca ;-) ) e quando è ben assortito ci sono tutti
gli ingredienti ben amalgamati

quando il cliente è soddisfatto e il team è orgoglioso del prorpio
lavoro è un successo
retrospective + i 5 perché e la dispobibilità a rimescolare le carte
quando si desidera migliorare ancora



così mi torna



--- In extremeprogramming-it@yahoogroups.com, Ilias Bartolini
<ilias.bartolini@...> ha scritto:
>
> On Monday 03 December 2007, lucaminudel wrote:
> > A) mi avventuro lo stesso in questo adattamento/tailoring avanzato
> > con molta attenzione e opportune retrospetcive
> > oppure ...
> > B) prima do una chance all'approccio standard completo e dopo con
> > l'esperienza fatta passo all'adattamento/tailoring avanzato
> > oppure ...
> > C) - la preferita da Pier F. Loche :D - chiedo aiuto a un coach
che
> > ha già sperimentato l'equilibrio di tutte le forze in gioco
(tutte le
> > pratiche standard) e mi può aiutare nel procedere con questo
> > adattamento/tailoring avanzato
>
> io preferisco la "A" e con coraggio, ma bisogna sapere dove si sta
tirando!!
>
>
> ...a parte la risposta sopra... volevo aggiungere una sfumatura che
mi era
> venuta in mente quando Tim parlava del golf.
>
> Qualcuno tempo fa mi aveva insegnato che le "persone" sono degli
oggetti con
> una strana proprietà fisica: tu puoi spingerle fortemente in una
direzione,
> indicargli l'obbiettivo, inclinare il terreno in discesa ...ma a
differenza
> delle palle da biliardo (e da golf) non rispondono alle leggi
fisiche e vanno
> a finire sempre da un'altra parte.
>
> Ciò che porta le persone a seguire la direzione indicata sono:
> - comunicazione chiara,
> - motivazione,
> - fiducia,
> - maturità delle persone,
> - autorevolezza di chi indica la direzione
>
> Questi elementi non li vendono al supermercato, non si inventano in
pochi mesi
> e nemmeno anni... però credo che un buona manager sia in grado di
> capire "quanto" fanno parte di un team.
>
> Più sono qualità radicate nel team e più e possibile tirare dritto
e forte
> verso il green!
> Se ci sono in piccola quantità, magari meglio procedere per piccoli
colpi per
> non ritrovarsi nel laghetto...
>
>
> Ilias
> --
> /**
>  * Reply to: ilias.bartolini(at)gmail.com
>  * ICQ# 42797710 - PGP Key-ID:0xC6867602
>  * http://zatoichi.homeip.net - will write free code for food
>  */
>

Ciao,
mi sono perso il link alle slides dall'agileday 2007 e sul sito ancora
non c'e'!

qualcuno mi puo' aiutare?

Fabio

Appariva alla fine del wizard di "feedback" sulle impressioni dei
partecipanti. Però, una volta uscito, anch'io non lo trovo più...

Andrea Turchi
> Ciao,
> mi sono perso il link alle slides dall'agileday 2007 e sul sito ancora
> non c'e'!
>
> qualcuno mi puo' aiutare?
>
> Fabio
>
>
>
>

Mi interessano le vostre esperienze come ispirazione :)

Il punto che mi duole è se fare la raccolta delle storie dal cliente
con tutto il team o con un sottoinsieme limitato di 2-3 persone.

Quando proviamo con tutto il team l'entropia è troppa: le teste
partono in direzioni diverse e confondiamo il cliente. Per non parlare
della nostra amabile tendenza a cadere in dettagli implementativi :P

Quando inviamo dei rappresentanti del team, il resto della banda si
sente poco allineato, anche a fronte di più occasioni e canali di
allineamento.

L'unica cosa che abbiamo consolidato è che non si manda una persona sola :)

Voi come fate?

--
Fabio Bertone
fabio.bertone@...
http://www.fabiobeta.it

On 12/4/07, Fabio Bertone <fabiobeta@...> wrote:
>  Il punto che mi duole è se fare la raccolta delle storie dal cliente
>  con tutto il team o con un sottoinsieme limitato di 2-3 persone.
[...]
>  Voi come fate?

Ciao,

noi abbiamo passato varie fasi. Adesso siamo nella fase distruttiva...
:) nel senso che siamo arrivati a fine progetto, e siamo presissimi
dalle "richieste operative", come le chiamiamo noi, piu' che alle
storie di implementazione di nuove funzionalita'. In questa fase
troviamo difficilissimo applicare diligentemente qualunque pratica,
non siamo abbastanza rodati, e la nostra buona volonta' viene messa a
dura prova.

Comunque, tornando al punto, in questa fase dal cliente ci andiamo in
due o anche io da solo, perche', come dicevo, non ci sono piu' tante
funzionalita' nuove da implementare e quindi da ragionare, ma piu' che
altro c'e' da aiutare il cliente ad usare il sistema e fare un po' da
"avvoltoio sulle spalle", per capire i loro flussi di lavoro e vedere
come e' meglio aiutarli, in questa fase fortemente operativa. Il resto
del team forse ha perso un po' il contatto visivo, ma tanto sono tutto
il giorno al telefono comunque, quindi l'interazione e' forte.

All'inizio del progetto invece c'era da decidere, capire,
formalizzare, progettare, e quindi andavamo in 3. Forse qualche volta
in 4... ma principalmente in 3. In ogni caso non tutto il team, che
comunque e' fatto di 5 persone, anche perche' non potevamo lasciare
fermi gli altri progetti per un intero giorno. In quella fase era
molto utile essere di piu', e abbiamo notato una grossa differenza
sulla percezione dell'importanza delle storie, tra chi era stato dal
cliente e chi no. In pratica, chi non c'era stato tendeva a partire
per la tangente e a dare troppo peso a questioni irrilevanti.

Stefano

• descrizione
• versione
• priorità

1. le storie le scrive il cliente
2. il cliente ci scrive cose che per lui hanno un valore di business

Grazie a tutti!

Ciao a tutti

è la prima volta che scrivo in lista dopo mesi di lurking. Non credo
riuscirò ad aggiungere molto ma intanto ve la butto lì

Ho appena letto questo articolo [0] sugli anti-pattern tipici di chi usa
software per la continuous integration

L'ho trovato interessante soprattutto perchè ho trovato confermati dei
problemi che finora erano solo sospetti, in particolare quelli che
nell'articolo sono chiamati "Spam Feedback" e "Bloated Build"

Vi ritrovate in qualcuno di questi anti-pattern? Ne aggiungereste qualcuno?

Intanto domattina raffinerò i destinatari delle email e sposterò gli
unit test in job separati, in modo da continuare ad avere il feedback
dei test rotti ma anche avere prima possibile una build completa da
deployare

[0]
http://www.ibm.com/developerworks/java/library/j-ap11297/index.html?ca=drs

Ciao!

Fede

--
: Federico Fissore
:   Blog : http://www.fissore.org
: Jabber : federico@...
---------+-----------------------------------------------------
     []   : "The best thing is when you mix free beer and free
   [][][] | speech 'cause then you get some really free speech"
     ||   :                                            Dick Wall

>  L'ho trovato interessante soprattutto perchè ho trovato confermati dei
>  problemi che finora erano solo sospetti, in particolare quelli che
>  nell'articolo sono chiamati "Spam Feedback" e "Bloated Build"
>
>  Vi ritrovate in qualcuno di questi anti-pattern? Ne aggiungereste qualcuno?

Aggiungerei "Unreliable Tests": quando si è nel perenne dubbio su che
cosa si è rotto, il codice o i test?

Questo succede nella maggior parte dei casi che ho visto quando i test
sono più funzionali/integrazione e sopratutto quando sono molto
complicati, sia da un punto di vista del codice di implementazione, sia
da un punto di vista architetturale (dipendenze con altri sistemi,
configurazione complessa, ecc...)

E' più un antipattern riguardante i test fatti girare dalla build, ma essendo
parte della build, alla fine ci sta

--
Gabriele Lana
contact me at info at gabrielelana dot it
http://www.gabrielelana.it - Agile methodologies and Programming
http://www.xpug.it - italian eXtreme Programming User Groups

Beh... apro le danze:

Francesco (quello Cirillo) buon compleanno!
Auguri!

:)

--
Jacopo Romei <jakuza@...>