Emanuele says:
wow..ci siete tutti?
PierG - http://pierg.wordpress.com says:
beh .. io ci sono
Stefano Ottaviani says:
presente!
Vito Arconzo (...con Flavio nel cuore!) says:
anch'io
MatteoB says:
io idem!
makka says:
pure io...
Emanuele says:
tra un attimo iniziamo
Alfio Raciti - Al Jae says:
io ci sono, ciao a tutti
Hotdidoo says:
here i am
Alessandro Melchiori says:
eccomi!
Marcello says:
anche io
Hotdidoo says:
k
Vito Arconzo (...con Flavio nel cuore!) says:
ciao a tutti
Tiziana says:
eccomi
Emanuele says:
una nota per tutti...siccome siamo in tantini, non sarà facile tenere traccia delle conversazioni, quindi vi prego di indicare a chi è indirizzato il messaggio preponendo il destinatario, tipo
(luKa) aka Luca Minudel says:
presente, ciao a tutti
Emanuele says:
[luka] questo messaggio è per luca
PierG - http://pierg.wordpress.com says:
Ciao Luka
Emanuele says:
chiaro?
Emanuele says:
MatteoB says:
yes
Marcello says:
ok
Alessandro Melchiori says:
ok
Vito Arconzo (...con Flavio nel cuore!) says:
[emanuele] chiaro
Tiziana says:
ok
Alfio Raciti - Al Jae says:
y
(luKa) aka Luca Minudel says:
[PierG] Ciao
Roby has been added to the conversation.
PierG - http://pierg.wordpress.com has left the conversation.
PierG - http://pierg.wordpress.com has been added to the conversation.
MarcoAbis has been added to the conversation.
Emanuele says:
ok, dovremmo esserci tutti
PierG - http://pierg.wordpress.com says:
[Marco] ciao Marco
(luKa) aka Luca Minudel says:
Marco Abis, PierG, è una chat di super star
MarcoAbis says:
'sera
PierG - http://pierg.wordpress.com says:
Roby says:
wow ciao a tutti
Emanuele says:
il tema della serata sono "le metodologie Agili", tema vasto quindi cercheremo di focalizzarci su alcuni temi sia tecnici che non
Emanuele says:
tra di noi ci sono persone che applicano queste metodologie giornalmente altri che le hanno solo sentite nominare
Emanuele says:
la scorsa volta (per chi c'era) era sorta la questione su come far digerire ai capi ( o ai clienti) queste tematiche, visto che sembra che sia molto più in voga un'altra metodologia....molto meno agile
PierG - http://pierg.wordpress.com has left the conversation.
Emanuele says:
quindi chiedo a chi usa XP o altro...gli è stata imposta, l'ha imposta o è nata come naturale?
MarcoAbis says:
parli di capi e PierG scappa
Emanuele says:
Emanuele says:
[marco] appena torna online lo tiro dentro
(luKa) aka Luca Minudel says:
chiedi se XP è stato imposto ?
Emanuele says:
si...cioè come avete iniziato ad usare xp?^
Alfio Raciti - Al Jae has left the conversation.
Not all participants can view handwriting, so your messages will be sent as text
(luKa) aka Luca Minudel says:
quando ho iniziato a lavorare in un team totalmente nuovo è stato facile, serviva un metodo e quindi
(luKa) aka Luca Minudel says:
siccome gli altri non avevano esperienza ho adottato alcune pratiche di XP. questa è una esperienza.
Alessandro Melchiori says:
[luka] ma tu conoscevi già questa metodologia (presumo) e hai dato tu le direttive...
Marcello says:
[emanuele] scusa emanuele io mi chiedo innanzitutto perchè XP invece di scrumm o altro. come si arriva a scegliere in primo luogo il metodo specifico ?
Alfio Raciti - Al Jae has been added to the conversation.
(luKa) aka Luca Minudel says:
[Alessandro Melchiori] in quel caso ero il "+ vecchio" e ho guidato il team in un certo modo.
Alessandro Melchiori says:
[luka] non è facile far adottare tecniche che all'apparenza possono sembrare controproducenti e che sembra tendano a dilatare i tempi di sviluppo...
MatteoB says:
[luka] come facciamo a convincere il + vecchio che è un'ottima metodologia?
(luKa) aka Luca Minudel says:
[Alessandro Melchiori] come dicevo in quel caso è stato facile, prima c'era il vuoto
Roby says:
penso che il problema principale e che per capire i reali benefici ci vuole un po' di pratica
Emanuele says:
[Marcello] Xp è la metodologia più diffusa, credo che ognuno scelga quella che più si addice al suo modo di lavorare
Alessandro Melchiori says:
[luka] io parlo per esperienza personale e soprattutto non solo di Metodologie Agili...anche per l'architettura (ma quale?), design (pattern e non), unit test...non è facile inculcare un buon modo di lavorare!
Emanuele says:
[Marcello] e poi non ho conosciuto nessuno che usa XP, SCRUM, ecc....in modo rigoroso
(luKa) aka Luca Minudel says:
[MatteoB ] il primo step è avere la fiducia del "+ vecchio" poi magari iniziare da una pratica alla volta, quella che in quel momento porta + benefici
Alessandro Melchiori says:
[luka] ultimamente sto seguendo un progetto (sono entrato in corsa) che non ancora arrivato a metà della sua vita sta già esplodendo...ogni modifica comporta uno stravolgimento quasi totale del codice già scritto...
Roby says:
[luka] nonostante siano sponsorizzati da esponenti di rilievo internazionale c'è molta diffidenza, almeno nella mia esperienza in 3 società di software non ho mai trovato persone interessate
(luKa) aka Luca Minudel says:
[Alessandro Melchiori] più che inculcare funziona insegnare con l'esempio, con pazienza, e coinvolgendo le persone senza trascinarle - come un maestro di sci o di mountain bike
Maurizio @Roma has been added to the conversation.
Alessandro Melchiori says:
[luka] sì inculcare è un po' forte come termine...
MatteoB says:
[luka] c'è uno "schema" da seguire per apprendere step by step la metodologia?
(luKa) aka Luca Minudel says:
Marco Abis ha lavorato in molti team nascenti, mi piacerebbe sapere lui cosa ne pensa , come iniziare e come convincere
Roby says:
[luka] bhe si puo' partire con le pratiche individuali e poi passare a quelle di team che mi sembrano + complesse
MarcoAbis says:
eccomi
Alessandro Melchiori says:
[luka] certe volte però se non si è decisi (ecco perchè inculcare) si rischia di farsi sovrastare da scelte di altri
makka says:
[marco] qual'è secondo la tua esperienza il numero min. di persone persone per formare un team "agile"
(luKa) aka Luca Minudel says:
[MarcoAbis] tu cosa ne pensi?
MarcoAbis says:
vivo due situazioni opposte: team in cui sono gli sviluppatori a voler provare un metodo Agile ed il management che non ne vuole sapere e team a cui non interessa ma il management vuole "essere Agile"
MatteoB says:
[ale melchiori] sopratutto se sei il solo che propone ed è convinto dei benefici della metodologia
Alessandro Melchiori says:
[matteoB] mi hai capito alla perfezione
MarcoAbis says:
in ogni caso
Alessandro Melchiori says:
[matteoB e luka] il problema sta a monte...ad una ignoranza (in senso buono) di fondo delle tecnologie che si stanno utilizzando e delle possibilità che tali tecnologie mettono a disposizione!
Marcello says:
[Marco Abis] il problema è che il management potrebbe intendere il termine agile a suo modo
MarcoAbis says:
[Marcello] si, il 90% dei casi
MarcoAbis says:
MarcoAbis says:
l;unico modo che abbia una qualche possibiilita' di successo duraturo e' identificare il maggior problema condiviso da tutti (team e management) e partire attaccando quello
arianna_vezzali@hotmail.com has been added to the conversation.
Emanuele says:
[Tutti] Arianna è in realta Piergiorgio
MarcoAbis says:
ma per farlo, oltre alle "sensazioni" della gente (e situazioni poco piacevoli come lavorare 15 ore al giorno 7 giorni a settimana) e' necessario poter misurare la situazione
(luKa) aka Luca Minudel says:
[Roby] è quello lo schema che ho usato, perché ho iniziato da solo
arianna_vezzali@hotmail.com says:
Ringrazierò personalmente zio bill a redmond il mese prossimo!
MarcoAbis has left the conversation.
Emanuele says:
[Tutti] stasera msn è un po' pigro
arianna_vezzali@hotmail.com says:
[tutti] gli usa sono svegli a quest'ora ... prossimo orario della chat 9 di matina
(luKa) aka Luca Minudel says:
[Pierg-Arianna] e tu come hai iniziato il team a XP, l'hai imposto, propossto, promosso ?
arianna_vezzali@hotmail.com says:
[Luka] Ho dato un calcione iniziale
arianna_vezzali@hotmail.com says:
[Luka] ho messo in moto
(luKa) aka Luca Minudel says:
[Pierg-Arianna] come hai convinto il capo e poi gli sviluppatori ?
arianna_vezzali@hotmail.com says:
[Luka] e la benza l'anno poi messa 2 persone valide e un team affiatato
arianna_vezzali@hotmail.com says:
[Luka] Il capo l'ho scelto -assunto
arianna_vezzali@hotmail.com says:
[Luka] Il team lo abbiamo un po' 'tirato'
Marcello says:
[tutti] non è che il modo migliore per fare accettare i metodo agili e farlo dire ad un consulente esterno ? se lo dice lui !!!
arianna_vezzali@hotmail.com says:
[Luka] e poi si è scremato da solo
Emanuele says:
[Tutti] Tra di voi c'è qualche consulente? Avete mai provato a proporre certe pratiche "agili" hai vostri clienti? A me capita che ti prendano per pazzo!!
arianna_vezzali@hotmail.com says:
[Emanuele] E' una cosa troppo intima
arianna_vezzali@hotmail.com says:
[Emanuele] perchè possa venire 'da fuori'
MatteoB says:
[marcello] però il consulente lo paga il capo e il capo come lo convinci che lui viene a far del bene?
(luKa) aka Luca Minudel says:
[Pierg-Arianna] e il capo del capo del capo, hai dovuto convincerlo ?
arianna_vezzali@hotmail.com says:
[emanuele] da fuori può venire la scintilla
Maurizio @Roma says:
[Emanuele] Io sono consulente, e sono d'accordo con te
Emanuele says:
[PierG] ok, esatto...la scintilla, invece molte le vedono come perdita di tempo e non gli danno un'opportunità
arianna_vezzali@hotmail.com says:
[Luka] Mi ha dato fiducia: sono fortunato
Alessandro Melchiori says:
[Ema] non c'è bisogno di essere consulenti per essere presi per pazzi...come tu ben sai io è da un pezzo che faccio notare certe cose (da dipendente) e mi stanno crocifiggendo (in senso metaforico, ovviamente)
arianna_vezzali@hotmail.com says:
[Emanuele] Vero ...
arianna_vezzali@hotmail.com says:
[Tutti] fatemi dire comunque che credo sia MOLTO più complicato convincere un developer che un manager
Alessandro Melchiori says:
[Ema] comunque immagino quale possa essere la reazione a certe proposte...
Marcello says:
[emanuele] allora il movimento deve partire necessariamnete dal team di sviluppo . io non credo che ci siano molti manager che capiscano i vantaggi di usare metodi agili
arianna_vezzali@hotmail.com says:
[Tutti] Il developer ci mette la sua professionalità, la sua anima e io suo SUPER-ego
Emanuele says:
[PierG] io sono un tecnico, quindi i miei consigli si basano più sugli aspetti tecnici , ad esempio a me è molto caro il discorso degli Unit Test...pochi ci provano
Alessandro Melchiori says:
[Arianna...PG] perchè?
arianna_vezzali@hotmail.com says:
[Tutti] il manager lo convinci con le metriche
Alfio Raciti - Al Jae says:
[Tutti] secondo me si potrebbe fare a piccoli step, nel senso che se si inizia con una metodologia del tipo scrum dove in qualche modo sei obbligato a dare dei risultati 'tangibili' con tempi 'determinati' le barriere del capo si abbassano.
arianna_vezzali@hotmail.com says:
[tutti]metriche == palanche (come si dice dalle mie parti)
MatteoB says:
[ema] te come singolo sviluppatore che pratiche della metodologia usi? UnitTest poi?
(luKa) aka Luca Minudel says:
[PierG + Abis] come diceva Marco Abis, con le metriche
Roby says:
[PierG] proprio riguardo gli unit test , la cosa che mi sciocca di + e che non riesco a convincere i colleghi che passano 4/5 della giornata a risolvere problemi con il debugger davanti ...
arianna_vezzali@hotmail.com says:
[tutti] lo unit test non è una prerogativa delle metodologie agili
Emanuele says:
[Tutti] Marco non riesce a riconnettersi
Marcello says:
[arianna_vezzali] mmm io non credo nei metodo agili il capo il manger deve far parte integrante delle decisioni e del ciclo di sviluppo come lo convinci ad eesere parte del metodo ?
Roby says:
[tutti] c'è qualche testo o "diario" che parla di queste esperienza in un caso reale ?
arianna_vezzali@hotmail.com says:
[Marcello] Non necessariamene deve essere parte ... tu portagli i risultati e lui è felice
arianna_vezzali@hotmail.com says:
[Roby] Noi siamo un caso reale da 3 anni
(luKa) aka Luca Minudel says:
[Roby] è una domnda che sento spesso, non lo so, magari provare a far parte di un team agile ti darebbe le risposte che cerchi
Marcello says:
[arianna_vezz tutti] non sono convinto . cosa ne pensate il capo non deve far parte del ciclo ? ad esempio la data di rilascio deve sceglierla lui !!!
Emanuele says:
[MatteoB] io cerco di coinvolgere il cliente, scrivo le "storie" e valuto con lui (quando possibile) quali vanno fatte prima, non faccio pair-programming
(luKa) aka Luca Minudel says:
[Marcello ] nei metodi agili, gli Svi stimano le carte, il cliente sceglie quale implementare prima
arianna_vezzali@hotmail.com says:
[Marcello] un manager o un cliente possono scegliere una data e io gli dico cosa ci sta dentro, o un set di feature e io gli dico la data. PUNTO.
Alessandro Melchiori says:
[Arianna?] ma in che fantastico mondo vivi?
Alessandro Melchiori says:
[Arianna?] nel mio caso una cosa del genere non è fattibile!
arianna_vezzali@hotmail.com says:
[Alessandro] credo sia una questione di professionalità: o iniziamo a essere dei professionisti o ci prenderanno sempre a calci
arianna_vezzali@hotmail.com says:
[Alessandro] chiaro che in cambio devi essere PRECISO nelle stime, CONTINUO nei rilasci, OTTIMO nella qualità .. altimenti risulti solo poco collaborativo
Alessandro Melchiori says:
[Arianna?] Hai perfettamente ragione...ma quando davanti a tutto vengono messe solo le "metriche" non si va da nessuna parte!
Marcello says:
[arianna] essere professionali significa imporre una data ? io non credo il business lo decide il cliente o il capo quindi decide lui. Noi sencondo il metodo usato gli diremo cosa può essere fatto .
arianna_vezzali@hotmail.com says:
[Marcello] OTTIMO che il cliente definisca una data E il tuo dovere è dirgli COSA riesci a fare per quella data.
Roby says:
[Alessandro] penso che non si possa essere molto precisi, ma vedi per esempio Planning Game, è possibile ristimare, ad ogni iterazione, le storie da completare tenendo conto dell' effort relativo alle precedenti stime. questo modo di fare mi piace molto e mi dà + sicurezza
Alessandro Melchiori says:
[Arianna?] il problema si presenta quando chi non fa decide cosa si deve fare per una certa data...mi sono spiegato?
arianna_vezzali@hotmail.com says:
[Roby Alessandro] si può essere MOLTO precisi ... e Luka può aiutarvi in tal senso
arianna_vezzali@hotmail.com says:
[Alessandro] Certo E se nessuno inizia a dire di NO ... c'è poco da lamentarsi.
Roby says:
[arianna] io in 5 anni di progetti , non sono mai riuscito a fare una stima azzeccata alla prima stesura
Stefano Ottaviani says:
[Marcello e Alessandro] sono d'accordo con PierG-Arianna, e dato che si parlava di testi, riguardo alle stime posso consigliare un libro per tanti versi nel mio caso è stato 'illuminante', e sicuramente aiuta ad avere idee + precise: Software Estimation di McConnell (trovate una recensione qui:
Stefano Ottaviani says:
http://dotnetmarche.org/blogs/recensioni/archive/2006/10/04/Software-Estimation_3A00_-Demystifying-the-Black-Art.aspx
arianna_vezzali@hotmail.com says:
[Tutti] Mi piacerebbe sapere l'esperienza di chi non sta scrivendo: chi sceglie le date?
MatteoB says:
[pierg] capo + cliente
arianna_vezzali@hotmail.com says:
[Roby] Naturale ... e immagino farai rilasci brevi, ti misurerai, migliorerai le tue stime e dopo un tempo ragionevole sarai MOLTO MOLTO preciso. Giusto?
Maurizio @Roma says:
[arianna_vezz] sempre il cliente
Emanuele says:
[Arianna?] Io cerco sempre la collaborazione del cliente e di fissare insieme a lui le date facendogli capire che tot richieste possono essere fatte in tot tempo
arianna_vezzali@hotmail.com says:
[Tutti] Ottimo e molto sano: la data la definisce il cliente che conosce il suo business. Potete decidere COSA metttere dentro per quella data??
Alessandro Melchiori says:
[Arianna?] ma anche io sono daccordo...se le stime le faccio io che devo sviluppare, mi baso su ciò che c'è da fare sulle mie (magari poche) conoscenze e in base a quello vi posso assicurare che le stime sono al più azzeccate
Maurizio @Roma says:
[arianna_vezz] a volte si, a volte no
arianna_vezzali@hotmail.com says:
[Emanuele] La collaborazione è la chiave: customer collaboration over contract negotiation
arianna_vezzali@hotmail.com says:
[emanuele] cito l'agile manifesto .. inizio ad invecchiare
Roby says:
[arianna] con clienti piccoli quasi sempre io, tentando di far capire che le stime non sono mai certe e che si possono misurare di volta in volta, con clienti grossi vengono fatte sempre da persone non tecniche che sbagliano alla grande e si chiede agli sviluppatori di fare straordinari ....
Maurizio @Roma says:
[Roby] parole sacrosante
Emanuele says:
[Arianna?] Non so se sbaglio ma io cerco di far capire al cliente (per quanto possibile) cosa vuol dire scrivere un pgm, con alcuni ci si riesce bene
Alessandro Melchiori says:
[Arianna?] c'è un brutto termine che gira ultimamente in ufficio sulla posizione che i manager stanno assumendo verso i clienti...
Roby says:
[Emanuele] purtroppo spesso non è possibile e bisogna cercarsi un proxy del customer se si è fortunati
arianna_vezzali@hotmail.com says:
[Roby] I see ... e credo che la misura possa dare una mano anche al cliente grosso a capire cosa sta sbagliando: se la tua risposta è sempre 'belin, in quel tempo non ce la faccio' ... fai solo il brontolone
(luKa) aka Luca Minudel says:
[Roby] se servono gli straordinari per la prima implementazione allora x la manutenzione - evoluzione serve l'esercito
arianna_vezzali@hotmail.com says:
[Alessandro] che parola?
arianna_vezzali@hotmail.com says:
[Roby - emanuele] un proxy del customer (anche all'interno del team) è comunque una soluzione che serve al team per tenere la direzione: meglio così che ognuno interpreti priorità e requisiti come gli gira quel giorno
Alessandro Melchiori says:
[Arianna?] non è una parola...diciamo che è un angolo, l'angolo retto...non si può, per la solita paura di perdere cliente (e quindi metriche, mi piace ) dire sempre sì
arianna_vezzali@hotmail.com says:
[Alessandro]
arianna_vezzali@hotmail.com says:
[Alessandro] e dire che ero forte in trigonometria
Alessandro Melchiori says:
[Arianna?] si fa lavorare male il team, si scoraggiano gli sviluppatori e si tende a demotivarli creando un circolo vizioso...
Alessandro Melchiori says:
[Arianna?]
(luKa) aka Luca Minudel says:
[Alessandro Melchiori ] tieni conto che alcuni clienti è meglio perderli x trovarne di migliori, quando i primi porteranno il progetto all'irrimedianile insuccesso
Emanuele says:
[Tutti] non vorrei scatenare un flame, ma tante volte si sente dire che "per stare nei tempi" si scrive un programma che + o - va senza puntare alla qualità, voi che ne dite? Io penso sia meglio togliere feature piuttosto che dare cose che non funzionano.
arianna_vezzali@hotmail.com says:
[Emanuele] Io dico che un debito tecnico è una cosa da NON fare
arianna_vezzali@hotmail.com says:
[Emanuele] E pago molto bene le persone che sanno scegliere QUANDO è il caso di fare un debito
Marcello says:
[emanuele] sono d0accordo tra latro non è proprio uno dei cardini dei metodo agili ?
Maurizio @Roma says:
[Emanuele] Lo penso anch'io, ma a volte è necessario scendere a compreomessi
Alessandro Melchiori says:
[luka] anche io lo credo ma certi clienti che portano tanti, ma tanti soldi (o metriche, chiamale come vuoi) sono difficili da abbandonare
MatteoB says:
[ema] io sono d'accordo!! Chi comanda (nel mio caso) no...meglio consegnare e poi si vedrà!
Tiziana says:
[PierG] le date sono definite dal responsabile sviluppo in accordo con la direzione....
(luKa) aka Luca Minudel says:
[Emanuele ] il cliente chiede feature subito e poi ha bisogno di continuità (evoluzione del prodotto), questa è una motivazione per fargli accettare la qualità
arianna_vezzali@hotmail.com says:
[Tutti] La NON qualità si paga SEMPRE: un prodotto scarso prima o poi fa perdere il cliente
Tiziana says:
[PierG] daccordissimo
arianna_vezzali@hotmail.com says:
[Tiziana] Mi sembra di capire che lavori per un cliente 'interno' allì'azienda ... giusto?
Alessandro Melchiori says:
[ema] in un mondo ideale non si dovrebbe mai tralasciare la qualità per la quantità...in un mondo ideale!
Marcello says:
[matteob] così si fa presto a creare spaghetti code e l'applicazione divente presto non manutenibile
(luKa) aka Luca Minudel says:
[PierG] confermo, ho visto software house chiudere xKè il loro prodotto è crollato a forza di poca-qualità
arianna_vezzali@hotmail.com says:
[Tutti] Io cedo che scrivere codice BUONO, no ncosti di PIU' che scriverlo male. Credo sia una alibi di programmatori poco preparati soprattutto nel design
Alessandro Melchiori says:
[Arianna?] esatto
Tiziana says:
[PierG] non ho capito cosa intendi
MatteoB says:
[marcello] infatti!!
arianna_vezzali@hotmail.com says:
[Tiziana] hai un cliente interno alla tua azienda?? cioè scrivi sw per altri reparti o per il 'mercato'?
Roby says:
[tutti] quali metriche / tool di metriche utilizzate ?
Marcello says:
[arianna] sono d'accordo i metodi agili sono soprattuta fatti dalle persone , LE PERSONE devono essere di qualità !!!
arianna_vezzali@hotmail.com says:
[Marcello] BINGO!
Hotdidoo says:
[tutti] scusate, ma il tema della serata non era "le metodologie Agili"? mi sa che ci si sta facendo prendere dall'emotività del quotidiano...
(luKa) aka Luca Minudel says:
[Roby] alcuni tool fatti da noi, poi anche Ndepend2 e vil
Emanuele says:
[Arianna?] Il problema della preparazione del team è un altro tema che mi interessa. Vedo in XP un problema con team poco preparati sul design del codice, cioè mi sembra che funzioni bene se il team è in gamba ma fallisca se ci sono alcuni elementi poco validi...sbaglio?
arianna_vezzali@hotmail.com says:
[Roby] Odio rispondere così ma ... la scelta delle metriche è una cosa intima del team: dipende dagli obiettivi che ti dai
Tiziana says:
[PierG] io sono il responsabile dll'area e viene creato software per clienti esterni
arianna_vezzali@hotmail.com says:
[Emanuele] La coesione del team è importante e un team eterogeneo è sicuramente motivo di rallentamento
arianna_vezzali@hotmail.com says:
[Tiziana] OK .. ho preso un granchio Scusa
Marcello says:
[emanuele] secondo me non sbagli . la qualità della preparazione delle persone del team è fondamentale nei metodi agili per me !
(luKa) aka Luca Minudel says:
[Roby] quoto PierG, gli obiettivi prima ancora dei tool di metriche
Tiziana says:
[PierG] niente...
Roby says:
[ema] penso che in quel caso possa essere motlo utile avere una "build machine" preconfigurata tipo BUILDIX in modo da non dover perdere tempo con le fasi di configurazione etc.. e partire subito ad integrare il codice
arianna_vezzali@hotmail.com says:
[Roby] he he .. sarebbe felice MArco se riuscisse a collegarsi
Tiziana says:
[emanuele] spesso il team può rovinare un progetto che parte con i migliori presupposti di qualità
(luKa) aka Luca Minudel says:
[Marcello] direi che in un team agile la qualità delle persone può essere usata al meglio
Roby says:
[luka] anche io la penso cosi' , pero' le metriche sono importanti per tenere sotto controllo il codice e facilitare il refactoring
arianna_vezzali@hotmail.com says:
[Tiz ema] e comunque il processo di creazione di un buon team .. è un processo lungo ma si può vincere!
arianna_vezzali@hotmail.com says:
[tiz ema] agile o NON agile: chiaro che nell'agility il concetto di team e TUTTO .. quindi è più 'importante'
Roby says:
[arianna] se a cercare di adottarlo è una pesona con "poter" per esempio capo progetto e molto + semplice creare il team
Tiziana says:
[PierG] ne sono convinta e spesso è il resto del team a limare i problemi e dare comunque una soluzione
Emanuele says:
[Tiziana e Arianna] esatto e questo talvolta mi preoccupa. Quando sono da un cliente e gli propongo certe soluzioni di design e architettura, talvolta devo semplificare perchè so che cosi non arriverà da nessuna parte...a meno che sia sempre li io a bacchettarli!
Marcello says:
[luka] ok le metriche. ma secondo me è in primo luogo fondamnetale fare del buon design. le metriche buone sono una conseguenza o no ?
Maurizio @Roma says:
[arianna_vezz] molto spesso, però, parlo per esperienza personale, un team non viene creato scegliendo le persone migliori, ma quelle che costano meno
(luKa) aka Luca Minudel says:
[Roby] ok, e che obiettivi ti dai? prima la leggibilità? o dalla modificabilità? o dalla affidbilità? cioè prima gli obiettivi poi le metriche
Hotdidoo has left the conversation.
Roby says:
[luka] possono essere un indicatore per camiare le cose, soprattutto se si lavora in team che non possono fare pair
Tiziana says:
[ema] concordo
PierG (incarnato in Arianna ) says:
[Maurizio] diciamo che il 'migliore' nel caso dell'agility ha una connotazione leggermente diversa
PierG (incarnato in Arianna ) says:
[Maurizio] Le doti primarie da cercare sono 'altre': non ci serve il super guru di qualche tecnologia .. ci servono dei VERI team player
(luKa) aka Luca Minudel says:
[Marcello-Roby] le metriche possono essere un indizio, come una analisi statistica, suggeriscono ma la "scoperta" spetta alla persona
PierG (incarnato in Arianna ) says:
[Maurizio] e dei buoni designer
makka says:
[Arianna] buoni designer = quasi guru?
Roby says:
[luka] per esempio mcCabe pesso sia quella che mi è stata + utile per fare refactoring su codice mai visto
Marcello says:
[makka] non credo basta una buona preparazione di base
(luKa) aka Luca Minudel says:
[Maurizio] quando il progetto è complicato e rischia di crollare , dopo qualche brutta esperienza accett
PierG (incarnato in Arianna ) says:
[makka] no .. buoni designer: qualcuno che capisca, ad esempio, perchè da noi NON puoi fare check in se hai messo un IF nel tuo codice
makka says:
[marcello] preparazione di base si ma MOLTO ampia però
(luKa) aka Luca Minudel says:
[Maurizio] diventa sensato spendere anche di più, e questo lo capisce anche il cliente
Maurizio @Roma says:
[luka] non sempre, purtroppo
PierG (incarnato in Arianna ) says:
[Tutti] Oltrea a Tiziana .. abbiamo dei manager in ascolto??
Marcello says:
[makka] per preparazione di base intendo : buona conoscenza della OOP, degli strumenti, della piattaforma etc. insomma quello che serve per fare buon design
makka says:
[Arianna] quella dell'IF mi sembra quasi un'esagerazione...
(luKa) aka Luca Minudel says:
[Roby] se cercavi la semplicità degli algoritmi si, se cervavi la semplicità delle classi, la lunghezza dei metodi poteva essere più utile (è solo un esempio per dire che se scegli prima l'obiettivo ti è più facile scegliere la metrica e interpretare i risultati)
PierG (incarnato in Arianna ) says:
[makka]
makka says:
[marcello] per capire bene OOP bisogna aver picchiato tanto la testa sul codice...
(luKa) aka Luca Minudel says:
[Maurizio] allora quella è una customer smell , il refactoring onsigliato è ... cercati un altro cliente + avveduto
Maurizio @Roma says:
[luka] infatti hai ragione, solo che capisci che il cliente è così solo quando già ci sei dentro!
Marcello says:
[makka] ok ma questo è un nodo cruciale . come è che i buoni framework sono ben strutturati seguento la OOP ? loro ci riescono ! quindi .
(luKa) aka Luca Minudel says:
[PierG-Ariann] Progettista-Resp.Tecnico (coach)
Alessandro Melchiori has left the conversation.
(luKa) aka Luca Minudel says:
tutti developer, nessun manager ?
makka says:
[Marcello] io penso che l'esperto possa fare la differenza
makka says:
[Marcello] però nel team agile deve usare una veste MOLTO umile
PierG (incarnato in Arianna ) says:
[Makka Marcello] Io penso che un team coeso possa fare la differenza. Un buon mentore MOLTO utile. Un 'esperto' ... dipende.
Emanuele says:
[Arianna Tiziana] Voi che siete i 2 _M_anager. Avete una formazione tecnica oppure no? e come vi siete fate convincere che "agile è bello"?
Roby says:
[makka] leggo molto i sorgenti di tool open source "spring , hibernate, enterprise library "... etc e rimanevo molto impressionato sulle differenze di stile con il mio codice, da quando cerco di far emerge il design questo gap si stà via via eliminando,questo per dire che si è necessario avere buone conoscenze di OOP OOA OOD etc... pero' si puo' partire con codice meno sofisticato per poi migliora
Emanuele says:
[Makka] penso che + che umiltà ci vuole carisma per convincere gli altri
PierG (incarnato in Arianna ) says:
[Emanuele] Io ho datto il developer per anni. SOno sempre stato un appassionato del COME si fanno le cose, piuttosto che del COSA si fa. Mi sono trovato in una realtà dove l'agility era l'UNICA soluzione e booonnnn
Tiziana says:
[Ema] Io sono prima di tutto un senior developer e sono diventata responsabile ...è l'esperienza che mi ha convinto
PierG (incarnato in Arianna ) says:
[Tiziana] In che zona è la tua azienda?
Tiziana says:
puglia bari per la precisione
Emanuele says:
[Arianna Tiziana] Ok, siete entrambi ex-tecnici...non credete che questo abbia influenzato la vostra direzione? per un non-tecnico penso sia mooolto diverso, voi avete la sensibilità sul problema del codice, un non tecnico capisce a malapena cosa facciamo
PierG (incarnato in Arianna ) says:
[emanuele] Per un NON tecnico credo sia ancora più facile perchè NON entra nel merito. Porta i risultati e lui sarà felice
Marcello says:
[roby] meno sofisticat o ? anche l'applicazione non troppo complessa richiede l'applicazione di principi senza i quali non crei le basi per una buona gestione del progetto soprattutto della sua manutenzione nel tempo.
PierG (incarnato in Arianna ) says:
[Tiziana] Non sei in webshell ... vero?
Tiziana says:
[PierG-Ariann] sono assolutamente daccordo anche se in realtà è una questione spesso di come si spiegano le cose ai non tecnici...se ci sono argomentazioni non c'è nulla che tenga...
makka says:
[Roby] se fi fosse un ottimo dev nel tuo team saresti obbligato a fare quello che dici
Tiziana says:
no
(luKa) aka Luca Minudel says:
[Emanuele] un ex tecnico corre il rischio di vuole decidere al posto del team. la differenza vera la fa se uno è bravo o meno
makka says:
[Roby] facendo refactoring in pair con lui impareresti molto
Tiziana says:
[ema] concordo...
Emanuele says:
[arianna] beh non so...spiegaglielo tu che in pair-programming si produce codice migliore e che scrivere i test non è tempo buttato...io lo facevo di nascosto
PierG (incarnato in Arianna ) says:
[Tiziana] Siete una azienda fatta di team agili o siete una azienda in cui c'è anche un team agile (il tuo)?
PierG (incarnato in Arianna ) says:
[ema] direi che più che di 'nascosto' .. facevi il tuo mestiere per dare ottimi risultati .. che è quello che si aspetta da te
(luKa) aka Luca Minudel says:
[TUTTI] Qualche domanda per conosceri
(luKa) aka Luca Minudel says:
conoscerci
(luKa) aka Luca Minudel says:
[tutti]
chi di noi fa parte di un team che è o sta diventando agile?
PierG (incarnato in Arianna ) says:
[luka] presente!
Emanuele says:
[luka] io ci provo giorno per giorno..talvolta solo talvolta in team
Marcello says:
[marcello] ci proviamo
MatteoB says:
[luKa] io ci provo a diventare agile!
Tiziana says:
[luka] si fa il massimo per essere team agile
Roby says:
[roberto valenti] solo , ora lavoro in un team che usa una metodologia che si riferisce a MSF cmq cerco di adottare le metodologie agili "sottobanco"
(luKa) aka Luca Minudel says:
[Tutti] chi di noi adotta principalmente in modo personale una o più pratiche (tdd, refactoring, cont.integr.)?
(luKa) aka Luca Minudel says:
senza far parte di un team agile
makka says:
[luka] TDD, una volta provato non puoi + farne a meno
PierG (incarnato in Arianna ) says:
[Tiziana] Siete una azienda fatta di team agili o siete una azienda in cui c'è anche un team agile (il tuo)?
makka says:
[luka] e poi via di refatoring quando serve
PierG (incarnato in Arianna ) says:
[makka] E poi ti lamenti dei nostri IF!!! TALEBANO DEL TDD
Roby says:
[roberto valenti] dovevo scrivere adesso ... cmq TDD, Refactoring , Planning User Story, Pomodoro, Metriche
Emanuele says:
[luka] principalmente TDD, refactoring, Small release, Coding Standard
Tiziana says:
[PierG] tendenzialmente la prima ...ma in alcuni casi è molto difficile
(luKa) aka Luca Minudel says:
[Tutti] c'è qualcuno che ha sentito parlare dei metodi agili e non gli ha ancora provati sinora?
MatteoB says:
[luKa] io ho provato solo (poco) TDD
makka says:
[Roby] qualche suggerimento per imparare a creare User Story in modo corretto?
Emanuele says:
[Tutti] Apro una parentesi sul TDD...non vi sembra che un "difetto" del TDD è quello di ottenere tante belle classi ben disegnate e ben testate ma poco integrate? Spesso mi capita di dover fare un punto della situazione su ciò che ho scritto per vedere se l'integrazione dei vari pezzi sta in piedi. E' un problema solo mio?
Roby says:
[makka] prova a leggere questo paper http://www.xplabs.it/fc2.html
PierG (incarnato in Arianna ) says:
[Roby] he he .. il mitico Cirillo
(luKa) aka Luca Minudel says:
[Emanuele] è la sensazione che ho quando ho il sistema tanto disacoppiato
Roby says:
[PierG] già pero' non si comporta bene come customer nel progetto aggregator del milano-xpug , ci cazzia e basta
Alessandro Melchiori has been added to the conversation.
makka says:
[Roby] ovviamente già letto ... le primizie non si lasciano scappare
(luKa) aka Luca Minudel says:
[Emanuele] in primis mi aiuto usando bene namespace e nomi delle classi molto significative e delle metafore che descrivono bene come mettere insieme i pezzi
MatteoB says:
[luKa] cosa intendi per metafore che descrivono...?
makka says:
[Roby] Però il pomodoro mi sembra generico alla gestione del proprio lavoro. Io cercavo qlc che mi aiutasse a scomporre le richieste del cliente in US
Roby says:
[makka][ ok, allora ti consiglio di dare un occhiata al XP Game del mitiko pascal http://www.xp.be/xpgame/description.html
(luKa) aka Luca Minudel says:
[Emanuele] una metafora, sicuramente nel gergo informatico conosi quella delle code e dei semafori, in gergo di GUI conosci le metafore delle finestre e dei menù,
(luKa) aka Luca Minudel says:
[MatteoB ] una metafora, sicuramente nel gergo informatico conosi quella delle code e dei semafori, in gergo di GUI conosci le metafore delle finestre e dei menù
makka says:
[Roby] thk. Domani leggero con attenzione
(luKa) aka Luca Minudel says:
[MatteoB ] puoi inventarti una metafora che descrrive come le tue classi collaborano tra loro
Emanuele says:
[Arianna e Tiziana] Chiedo ancora a voi che avete una visione dall'alto. Quali sono i principali ostacoli che avete trovato non appena partiti con XP ?
MatteoB says:
[roby] il link che hai indicato (XP Game) è utile solo per chi lavora in team o no?
(luKa) aka Luca Minudel says:
[Emanuele] poi ho visto usare gli unit test non solo come test dello "stato" ma anche come test dell'interazione ossia come le classi collaborano tra loro , e questo aiuta a disegnare la coesione
makka says:
[Arianna e Tiziana] ...ed aggiungo cosa via ha spinto a continuare cmq dopo i primi ostacoli
Emanuele says:
[luka] esatto anche io faccio cosi...ogni tanto fermo il flusso red-green.refactor per scrivere alcuni test di integrazione
PierG (incarnato in Arianna ) says:
[Tiz luka] Mi piacerebbe condividere meglio le vostre esperienze di manager. Per non andare fuori tema qui mi mandate i riferimenti su piergiorgio.grossi@gmail.com che ne parliamo in futuro?
Roby says:
bhe diciamo che è + utile per chi lavora in team ma io per esempio ho preso spunto sul come dare dei punteggi di importanza alle storie e cercare di dare la precedenza
PierG (incarnato in Arianna ) says:
[makka] nel nostro caso ... la disperazione: non credo ci sia altro modo visto il tasso di cambiamento e il ritmo
PierG (incarnato in Arianna ) says:
[makka] ritmo = ritmo dei nostri rilasci
Roby says:
[tutti] non so' che darei per poter lavorare in un team agile "alla luce del sole"
PierG (incarnato in Arianna ) says:
[emanuele] i principali ostacoli sono stati i programmatori poco preparati
PierG (incarnato in Arianna ) says:
[roby] he he .. sembra l'alcolisti anonimi
Tiziana says:
[Ema] sinceramente l'XP è stata una naturale evoluzione data dalle esperienze di sviluppo...il rapporto diretto col cliente e le scelte fatte sono state sempre più produttive rispetto ad avere sottomano un documento che nessuno ha mai rispettato nè nei tempi nè nel dettaglio...
(luKa) aka Luca Minudel says:
[Emanuele] iterazione (non integrazione) intendo quelli che testano che chiamando un metodo vengono coinvolti altri oggetti e chiamati altri metodi.
makka says:
[PierG] "programmatori poco preparati" = ad XP o tecnicamente ?
Tiziana says:
[PierG] volentieri
Emanuele says:
[PierG] lo sospettavo...infatti come dicevo prima anche io noto il problema. E dal punto di vista "umano". Nessuno a remato contro? (del tipo: sono 20 anni che faccio cosi e adesso questo viene a dirmo come devo fare)
(luKa) aka Luca Minudel says:
[Roby] sei un carbonaro dell'agile
Emanuele says:
[luka] ok...capito
Roby says:
[luka] bella
PierG (incarnato in Arianna ) says:
[makka ema] poco preparati == poco propensi a mettersi in gioco, a confrontarsi con il team, a rendere evidente il proprio valore con le metriche, a condividere il codice
PierG (incarnato in Arianna ) says:
[makka ema] .. POI ... è venuto il problema tecnico
makka says:
[PierG] questi lavorano ancora nel tuo team ?
PierG (incarnato in Arianna ) says:
[makka ema] Quello che ho imparato in questi anni è che il fattore critico di successo NON è MAI una questione di tecnologia
PierG (incarnato in Arianna ) says:
[makka] pochi
Roby says:
[PierG] io penso di lavorare in un team con 3 stelle ognuno lavora a modo suo e non dà molto retta a gli altri, faccio molta difficoltà a convincerli ... volevo creare un moto per fare i test di accettazione con fit per far vedere qunto è utile ... sperem
PierG (incarnato in Arianna ) says:
[roby] Azzz .... in bocca al lupo!
Roby says:
[PierG] è l' ultima carta ...
PierG (incarnato in Arianna ) says:
[roby] .. una carta MOLTO difficile (qui ci sono anche dei problemi tecnici oltre a degli ENORMI problemi culturali)
makka says:
[Tutti] Cosa ne pensate degli strumenti per supportare un progetto agile? Quali i primi necessari?
PierG (incarnato in Arianna ) says:
[makka] source code control, excel, qualcosa per build automatica
Roby says:
[tutti] ultimamente ho frequentato anche il newsgroup java, forse è solo una mia impressione ma nella comunity di ugi mi sembra che una piccola percentuale delle persone sono interessate alle metodologie agili
PierG (incarnato in Arianna ) says:
[roby] la community di UGI e tecnology centrica: basti vedere che 1/5 dei post sono sul passaggio di certificazioni. Normalmente chi è technology driven ha altri interessi
(luKa) aka Luca Minudel says:
[makka] anche la carta , crc e user story di carta da maneggiare x alcune persone aiutano a capire il processo, e sono facili/economiche da avere
makka says:
[PierG] ma per build automatica intendi anche batteria di test , code coverage , ecc.
Emanuele says:
[Roby] è una cosa che ho notato anch'io, il mondo Ms su queste tematiche deve ancora crescere, credo sia una questione di cultura
Roby says:
[makka] Framework Unit Test , Source Control (es SVN), Cruise Control, Selenium [per app web], Fit / Fitness, Tool di metriche/code coverage con report da creare sul server
(luKa) aka Luca Minudel says:
[Roby] ho iniziato ad imparare le pratiche di XP ascoltando dal mondo java
PierG (incarnato in Arianna ) says:
[makka] one step up: già sono felice se tutte le notti si fa un get latest e si builda senza errori (compresa la creazione del kit di installazione)
(luKa) aka Luca Minudel says:
[Roby] Fit / Fitness in versione x .NET giusto ?
Roby says:
si, io sto lavorando sia in Java che in .NET
makka says:
[PierG] dici che avere anche solo una build sempre compilabile è un vero plus ?
Roby says:
[luka] per le app web è molto utile Selenium, in quanto i test puo' farli anche il customer
Tiziana says:
[PierG] prima di tutto strumenti di comunicazione e condivisione usiamo Sharepoint per le comunicazioni e per la condivisione della comunicazione, Source Control, stato dei lavori...gestione bugs
PierG (incarnato in Arianna ) says:
[makka] è FONDAMENTALE
Roby says:
[makka] sono convinto che sia un grandissimo valore aggiunto , soprattutto se è già preparata tipo BUILDIX
(luKa) aka Luca Minudel says:
[Roby] interessante
PierG (incarnato in Arianna ) says:
[tutti] a proposito di perchè il mondo MS è più 'indietro' sulle metodologie agili, ho fatto proprio stamattina un post sul blog pensando a VB6 http://pierg.wordpress.com/2006/12/19/the-language-makes-the-difference/
makka says:
[Roby] aspettando una versione CC.NET
(luKa) aka Luca Minudel says:
[makka] e ... come tool di comunicazione-condivisione stavo dimenticando il ... wiki !!!
Roby says:
[makka] aspettando ?
Emanuele says:
[Tutti] direi che per iniziare è fondamentale anche una bella cena (o meglio un weekend in barca) con tutto il team...per creare affiatamento
PierG (incarnato in Arianna ) says:
[emanuele] se ci metti la barca, vengo a fare il mentore
(luKa) aka Luca Minudel says:
[emanuele] se ci metti le ragazze vengo anche a fare il mozzo
Roby says:
[luka] giààà http://trac.edgewall.org/
makka says:
[Roby] mi sbaglio o CruiseControl che c'è in BUILDIX è quello per Java?
(luKa) aka Luca Minudel says:
[Roby ] wiki + source ontrol , ne ho sentito parlare ma non l'ho mai provato
MatteoB says:
[tutti] la Continuos Integration è utile anche per un singolo sviluppatore?
Roby says:
si, pero' c'è la versione CC.NET, sul blog di simone chiaretta ogni tanto posta qualcosa
PierG (incarnato in Arianna ) says:
[matteob] credo sia una utilissima 'autoregolamentazione' in ogni caso
Roby says:
[matteoB[ si, anche se è molto + utile in team
PierG (incarnato in Arianna ) says:
[matteob] uno dei GROSSI vantaggi che ti dà è quello che ti porta a SPEZZARE
(luKa) aka Luca Minudel says:
[MatteoB] quando hai 2 o più progetti e non stanno tutti nella stessa solution (basta un click per compilarli assieme eun click per lnciare tutti i test) secondo me si
Roby says:
[makka] forse ora che Xp è gratis su macchina virtuale si potrebbe creare una Buildix.NET , sicuramente Marco ne saprà qualcosa ...
PierG (incarnato in Arianna ) says:
[roby] he he .... Marco secondo me .Net lo schifa un pochino
PierG (incarnato in Arianna ) says:
(ma che italiano scrivo!! ! )
makka says:
[PierG] ma il suo boss...
Roby says:
[matteoB] pensa ad uno scenario dove hai 2000 unit test e inoltre c'è la ricreazione del db prima di avviarli, poi tutte l' esecuizione dei tool di acceptance test, metriche etc... non vorrai mica farli tutti sul tuo pc !!!
PierG (incarnato in Arianna ) says:
[makka] ?
MatteoB says:
[roby] mi hai convinto
makka says:
[PierG] con CC.NET la società si fa MOLTA publicità grautita
makka says:
[PierG] ... gratuita
Stefano Ottaviani says:
[tutti] parlando da persona che non ha mai avuto modo di provare sul campo metodologie agili, nei confronti del cliente, in fase di trattativa, come fate a convincerlo a scegliere la vostra soluzione sviluppata con metodologie agili, i cui costi non sono ben precisi da subito (come quando si va dal dottore, se ho ben capito!)...
Stefano Ottaviani says:
...rispetto ad altre soluzioni concorrenti, sviluppate con metodologie classiche, che almeno all'apparenza gli verranno a costare un prezzo ben definito? quali altre difficoltà vengono incontrate nei rapporti con il cliente, in genere?
PierG (incarnato in Arianna ) says:
[stefano] argomento interessante ... abbiamo un altro manager
PierG (incarnato in Arianna ) says:
[stefano] è necessario creare TRUST
Stefano Ottaviani says:
ed inoltre, PierG, voi sviluppate principalmente soluzioni ad uso vostro interno....o ti sono capitate anche esperienze di sviluppo per clienti 'esterni'?
(luKa) aka Luca Minudel says:
[Stefano Ottaviani] se si gode di un po di fiducia o di credito si può suggerire al cliente di provare con un progetto piccolo e mostrargli che funziona
PierG (incarnato in Arianna ) says:
[stefano] interno
Roby says:
[stefano] io non ci sono ancora riuscito perfettamente, sono fortunato quando il cliente sà che fare un software non è come costruire una casa e quindi sà che le stime sono indicative e che non possono essere mai assolute
(luKa) aka Luca Minudel says:
[Stefano Ottaviani] se il cliente ha già preso parte ad altri progetti potrebbe ver capito che i piani fatti ad inizio contratto possono portare nella strada sbagliata
Emanuele says:
[stefano] io cerco di stimare il software a pezzi, in questo caso il margine di errore si riduce.
PierG (incarnato in Arianna ) says:
[stefano] per esperienza personale il cliente interno è PEGGIO di quello esterno: con quello esterno 'almeno' hai un contratto
Stefano Ottaviani says:
'manager' è una parola grossa...ma diciamo che mi occupo anche di questi aspetti!
makka says:
[stefano] fare un software è un processo iterativo non industriale, nulla di preconfezionato che costa x e basta
Tiziana says:
[Stefano]...il cliente invece ti assicuro ha la sensazione della cura dei particolari viene quasi coccolato dal trovare insieme l'accordo per la definizione del software...e così lo metti anche in condizione di conoscere esattamente il peso di ogni singolo modulo sviluppato
PierG (incarnato in Arianna ) says:
[Tutti] OK ragazzi, ho una certa età e un bimbo di 2 anni che domani mattina alle 6:30 vuole la sua dose mattutina di latte. Vi saluto, Vi ringrazio molto per la serata. Ringrazio Emanuele (a cui faccio i compliementi per la foto molto 'stilish'). Sono chiaramente a disposizione per chi vuole chiarimenti: piergiorgio.grossi@gmail.com
PierG (incarnato in Arianna ) says:
[tutti] Chi invece mi conosce già .. può scrivermi al mio indirizzo di ufficio
Emanuele says:
[PierG] ciao Pier, grazie per aver partecipato, ci risentiamo
Roby says:
[stefano] penso che la cosa migliore si a fare le stime con il cliente ed a ogni iterazione conclusa tirare le somme e decidere il dafarsi , so' che è uno scenario difficile, in questo caso applico delle stime personali e cerco di farle notare al capo progetto / cliente direttamente
Tiziana says:
[PierG] ciao è stao un piacere
(luKa) aka Luca Minudel says:
[PierG] ciao
Roby says:
[PierG] ciao è stato un grandissimo piacere
MatteoB says:
[PierG] ciao! grazie per aver condiviso la tua esperienza!!
Stefano Ottaviani says:
[PierG] ciao...e grazie a te!
Maurizio @Roma says:
[tutti] Scusate, ma mi sembra di capire che voi sviluppate tutti per software house, o per progetti interni. Io sono un consulente, e posso assicurare che in consulenza il fattore tempo è decisivo, della serie al cliente non importa nulla come viene fatto un software, ma solo il rispetto dei tempi di consegna
(luKa) aka Luca Minudel says:
[Maurizio] ho usato alcune pratiche dei metodi agili anche come consulente, non fosse altro che mi garantiva di avere una sensazione più reale dello stato di avanzamento
Roby says:
[maurizio] io lavoro per una società di consulenza ... e per questo che faccio cosi' fatica ...
PierG (incarnato in Arianna ) says:
[Maurizio] Secondo te ad un cliente 'di sw house' o 'interno' invece interessa qualcosaltro?? Fidati ... il cliente vuole sempre una cosa di GRANDE qualità (come percepita da lui), in tempo ZERO, e ad un costo RAGIONEVOLE (come percepito da lui)
(luKa) aka Luca Minudel says:
[Maurizio ] in questo caso stand-up e user story sono stati i primi strumenti
makka says:
[Tutti] Anch'io mi congedo. E' stata veramente una bella chiacchierata .. buona notte a tutti
Emanuele says:
[makka] ciao makka
(luKa) aka Luca Minudel says:
[makka] Ciao
MatteoB says:
[luka] non sono esperto cosa sono gli stan-up? hai qualche link in merito?
Tiziana says:
[maurizio] sta al consulente o al responsabile spiegarne il significato ed i benefici in maniera efficace....insomma bisognerebbe saper vendere la qualità...anche perchè a volte costa meno....
MatteoB says:
[makka] ciao!
(luKa) aka Luca Minudel says:
[MatteoB] si, non qui a portata di mano, scrivimi sul blog (http.//blogs.ugidotnet.org/luka)
Maurizio @Roma says:
[Tiziana] facile a dirsi, ma ti assicuro che in certe realtà (grosse) non è proprio così. Sono d'accorso con te, comunque
MatteoB says:
[luka] ok!
(luKa) aka Luca Minudel says:
[MatteoB] sono brevi riunioni al mattino in cui ogniuno dice cosa ha fatto ieri, cosa farà oggi, se ha problemi da risolvere e ha bisogno dell'aiuto di qualcuno, se è in ritardo.
Tiziana says:
[maurizio] è proprio con le grosse realtà che si deve e può fare leva sulla qualità..perchè un software a quei livelli deve essere una garanzia e se si sa porre la questione sotto questi termini...credimi è molto meglio
Emanuele says:
[Tutti] credo che un buon livello di trasparenza con il cliente faccia guadagnare fiducia e si riesca anche a lavorare meglio, cercare di fargli capire in cosa consiste il lavoro
Tiziana says:
[ema] concordo
Tiziana says:
[ema] e spesso sa valutare anche quali necessità sono reali e quali meno
Maurizio @Roma says:
[Tiziana] Vorrei farti fare un giro nella "grossa" realtà in cui sono io adesso e ti verrebbero seri dubbi, credimi
Emanuele says:
[Tutti] in fin dei conti bisogna "amare" i propri clienti e avere passione per il loro problema, solo cosi possiamo dare buoni risultati
Alessandro Melchiori says:
[ema] prima di tutto bisogna trovarli
Tiziana says:
[maurizio] ...ci sono anch'io in realtà simili ma alla fine sei tu che devi saper girare la frittata.
Emanuele says:
[Alessandro] beh certo...ma ce ne sono tanti in cerca di aiuto
(luKa) aka Luca Minudel says:
[Alessandro Melchiori] la sensazione che ho è che nel mercato c'è una richiesta di informatici di qualità superiore all'offerta
Alessandro Melchiori says:
[ema] sperom! ops...speriamo per i non bresciani!
Maurizio @Roma says:
[Tiziana] la tua realtà è sicuramente diversa da quella in cui vivo io, credimi, (sono anch'io di Bari )
Roby says:
[tutti] in questo link http://www.quinary.com/pagine/innovation/res_frame.htm ci sono alcuni paper relativi ad esperienze XP del team di quinary
Tiziana says:
[maurizio] beh certo che ti credo lo immagino ma credo che soprattutto in quelle realtà lo sforzo di fare comunque quello che ci dice la ns testa debba essere maggiore.
Tiziana says:
[maurizio] non ci conosciamo vero?
Maurizio @Roma says:
[Tiziana] parlo così perchè conosco l'azienda dove lavori e conosco la mia realtà lavorativa attuale
Maurizio @Roma says:
[Tiziana] forse tramite .netside
(luKa) aka Luca Minudel says:
[Roby ] link interessante, se lo leggi fammi sapere come lo trovi
Tiziana says:
[MAURIZIO] ok ho capito chi sei...
Maurizio @Roma says:
[Tiziana] già, l'unico Maurizio di .netside
Tiziana says:
[Maurizio] magari inviami il tuo account msn se ti va
Roby says:
[luka] per ora ho letto solamente quello relativo al cliente bancario
Maurizio @Roma says:
[Tiziana] certo, maurizio.tammacco@virgilio.it
(luKa) aka Luca Minudel says:
[Roby] e come l'hai trovato ?
(luKa) aka Luca Minudel says:
[Roby] chiaro? interessante?
Emanuele says:
[Tutti] ok ragazzi (e ragazze) direi che è stata una bella chiacchierata e spero che tutti abbiano avuto qualche spunto su cui riflettere e magari la scintilla per iniziare domani mattina con un metodo più "agile".
Emanuele says:
[Tutti] io mi congederei
Roby says:
[luka] molto interessante, parla del planning e delle iterazioni , mostra spezzoni del foglio excel usato per le stime da cui ho preso spunto per farne uno mio
Tiziana says:
[Tutti] vi saluto alla prossima
Emanuele says:
[Tutti] Colgo l'occasione per augurare a tutti buone feste e se vi va possiamo ritrovarci a gennaio per parlare di un altro tema....attendo vostre proposte.
(luKa) aka Luca Minudel says:
[Emanuele] ank'io
Alessandro Melchiori says:
[ema + tutti] vi saluto anch'io...grazie per la compagnia
Maurizio @Roma says:
[tutti] postiamo qualcosa sul blog, cosi si sparge la voce
(luKa) aka Luca Minudel says:
Saluti a tutti & buone feste - per contatti e info http://blogs.ugidotnet.org/luka
(luKa) aka Luca Minudel says:
P.S. Ema , metterai a disposizione il log della chat ?
MatteoB says:
[ema] ciao alla prossima!
Emanuele says:
[luka] si lo metterò sul mio blog
Roby says:
[luka] si mi è sembrato molto chiaro
Maurizio @Roma says:
[luka] ciao luka, molto interessante il tuo blog
MatteoB says:
[luka] ci "sentiamo " domani via blog per i link
Emanuele says:
[MAtteoB] ciao matteo
MatteoB says:
[tiziana] ciao, grazie di aver partecipato!
Roby says:
[tutti[ per chi ha voglia di parlarne di tanto in tanto questo è il mio contatto msn : valentirob@hotmail.com
MatteoB says:
[ale] ciao alessandro!
Alessandro Melchiori says:
[matteoB] ciao...