Chiusura del progetto...

[cionci]

Ho ricevuto come molti di voi la mail sulla chiusura del progetto...

Volevo sapere la vostra impressione...

Io sinceramente sono disposto a portarlo avanti anche allungando i tempi di realizzazione...

Le scadenze si possono rispettare in un'ambiente lavorativo, ma difficilmente possono essere determinanti e determinate in un progetto come questo realizzato nel "tempo libero"...

Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...

Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...

Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...

Io direi di portare il codice ad un livello gestibile e dopo stabilire nuove scadenze...

[Bonfo]

Io la mail non l'ho ricevuta
Cionci, ti contato in pvt così me la passi

Pur non avendo l'idea di cosa ci sia nella mail, dico già le mie prim eimpressioni dal post di cionci.

IL PROGETTO NON VA CHIUSO.

Ecco al proposta.
Riportare il codice ad un livello gestibile.
1 task bisettimanale per ognuno.
Recuperare sulla tabella di marcia appena i tempi saranno un po' meno scuri (vacanze).
Rilasciare Diamonds alle stesse date !!!

Le difficoltà ci sono e possono capitare anche nei team seri: si ammalano di varicella i 2 programmatori delle animazioni 3D...che si fà?
Sono convinto che il calo ci sia e sia pure fisiologico considerando che siamo tutti amatori, ma per un paio di cilcli che vanno storti...mica si muore.

Il problema vero è BigGem...

Ripeto quello che ho già detto in altri thread: sono nella cacca e posso fare giusto il task bisettimanale e sarò più specifico per far capire l'entità della mia situazione personale:
28 giugno -> Robotica
5 Luglio -> Sistemi Real-Time
13 Luglio -> Calcolatori Elettronici (Mattone infinito)
e nel tempo libero cercare di finire un progetto di Metodologie di Progettazione Hardware & Software e fare, totalmente, il progetto di Elaborazione dell'Immagine.
Il tutto entro il 21 Luglio.

Secondo voi lo trovo il tempo per andare in bagno ?!?!

Insomma la testa non ce la posso mettere tranne che per cose molto self-conteined. Se qualcuno però, in relazione hai refactoring, riesce a trovare dei mini-task....io sono qua

[jappilas]

Originariamente inviato da Bonfo

IL PROGETTO NON VA CHIUSO.

.

Ecco al proposta.
Riportare il codice ad un livello gestibile.
1 task bisettimanale per ognuno.
Recuperare sulla tabella di marcia appena i tempi saranno un po' meno scuri (vacanze).

.

Sono convinto che il calo ci sia e sia pure fisiologico considerando che siamo tutti amatori, ma per un paio di cilcli che vanno storti...mica si muore.

credo anch'io
la mia impressione e' che cancellare il progetto a giugno, quando la deadline per la versione finale era a dicembre... sia quantomeno prematuro e, aggiungerei, uno zinzino impulsivo ( sbagliero' ma mi sembra che l' effetto emotivo dello sconforto per il rallentamento, prevalga sulla lucida presa di coscienza che il rallentamento sussista ma che il progetto possa comunque andare avanti, alla peggio, ma proprio nel caso pessimo, con qualche feature di meno... e soprattutto mi preoccupa che il primo a gettare la spugna sia stato il coach )

Insomma la testa non ce la posso mettere tranne che per cose molto self-conteined. Se qualcuno però, in relazione hai refactoring, riesce a trovare dei mini-task....io sono qua

idem
imho la cosa migliore e' recuperare lo sprito degli inizi, spezzare il lavoro in task molto basilari che chiunque puo' fare in un' ora (realistica) al massimo ...

[Bonfo]

Grazie jappy, ora ho letto.

Non è una mail che pone il problema, ma è solo una mail che comunica la decisione della chiusura.

2 cose:
- come al solito si potrebbe almeno parlare con tutto il team prima di decidere
- e mò chi vuole andare avanti come fa??

P.S.: come al solito queste cose capitano quando il mattachhione non può scrivere

...ahi, le mie ditine.

[Bonfo]

Originariamente inviato da cionci

[...]
Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...

Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...

Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...
[...]

Certo, poi nell'ultimo periodo anche i task non sempre erano indovinati al 100% perchè portavano sepsso problemi.
Inoltre anche il log e il playback sono stati problemi sottovalutati.

in ogni caso fichè non si capisce come andare avanti è inutile guardare indietro

[cionci]

Bonfo...io sono in una situazine simile alla tua...solo che devo studiare l'esame di sistemi operativi che comprende anche sistemi operativi real-time in 20 giorni...

Il 23 giugno ho dato il mio settimo esame (30 !!!!) contando a partire da settembre 2005...e sto cercando di arrivare al più presto a prendere la tesi della specialistica...che posso prendere a luglio solo se riesco a passare il prossimo esame...

Ho dovuto ad ogni costo dare delle priorità e fino a metà luglio purtroppo non c'è spazio per Diamonds...senza contare che a casa della mia ragazza non posso sviluppare (quindi toglici minimo 3 giorni alla settimana)...

Quindi ripeto...propongo di riorganizzare il codice...non importa quanto tempo ci
mettiamo... Quando abbiamo raggiunto il livello di pulizia e facilità di gestione che ci aggrada possiamo ripartire a darci delle scadenze...

[thebol]

mi pare ridicolo.
Si è voluto seguire una timeline lavorativa in un contesto non lavorativo.
E poi si chiude il progetto, senza discuterne.

Ripeto mi pare ridicolo.
Fra l'altro non ho ricevuto la mail, e non capisco una cosa.
Il progetto era di qualcuno? O era del gruppo?
Chi è che ha deciso sta cosa?
Si potrebbe pubblicare qua la mail?(oppure thebol[atttt]wooow[puntooo]it) thx

[thebol]

Originariamente inviato da cionci

Quindi ripeto...propongo di riorganizzare il codice...non importa quanto tempo ci
mettiamo... Quando abbiamo raggiunto il livello di pulizia e facilità di gestione che ci aggrada possiamo ripartire a darci delle scadenze...

IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task.

ripeto IMHO.

[71104]

Originariamente inviato da cionci

Io sinceramente sono disposto a portarlo avanti anche allungando i tempi di realizzazione...

NO, NO, e NO!!
ricordi quando Jocchan ci ha parlato di quel progetto stupidissimo (stupidissimo rispetto al nostro) dilungatosi per anni?? non è questa la fine che ho in mente per DC, no! il 12 Dicembre verrà rilasciata la release finale di DC, chi c'è c'è chi non c'è non c'è; quello che abbiamo fatto in tempo a mettere bene, tutto il resto pazienza, non ci sarà mai.

Le scadenze si possono rispettare in un'ambiente lavorativo, ma difficilmente possono essere determinanti e determinate in un progetto come questo realizzato nel "tempo libero"...

ma questo tra le altre cose vuole essere il primo progetto freelance e didattico sviluppato con metodologie serie e all'avanguardia; tra queste troviamo il Test Driven Development nell'ambito della programmazione e timelines ben definite nell'ambito della gestione. se rimandiamo DC continueremo a farlo ancora e poi ancora e ancora, e finirà per diventare una puttanata che non esce mai (come tanti altri progetti che si vedono); il 12 Dicembre l'utenza avrà ciò che siamo riusciti a fare.

Probabilmente molti fattori, come quello del calendario, non sono stati tenuti in cosiderazione durante la stesura delle scadenze...

altro discorso: il sistema dei task e delle storie non tiene conto delle sessioni di esami che molti universitari hanno, cioè dei famosi periodi di Settembre, Gennaio-Febbraio, e Giugno-Luglio; ma all'inizio questo non era un problema, e se adesso lo è la causa non sono gli esami di per se' o la mancanza di tempo, ma il semplicerrimo fatto che buona percentuale del nostro codice fa piuttosto schifo e devo dire che mi sto rendendo conto che in parte la colpa è anche mia: sto riguardando classi che sviluppai tempo fa in TDD, ma se le rifacessi adesso le rifarei decisamente meglio: più semplici, meno metodi inutili, e tutto in meno tempo; un esempio? GemQueue, se ricordo bene l'ho fata proprio io. per ulteriori informazioni vedere il mio messaggio allo staff.

Ad esempio doveva essere tenuto in considerazione che la partecipazione degli studenti universitari (praticamente un buon 50% dei partecipanti) nei periodi Gennaio-Febbraio, Giugno-Luglio e Settembre sarebbe stata minima...

si, ma perché? in teoria per fare un task ci vogliono 10 minuti, no? 10 minuti non sono un problema per nessuno, non mi vorrete far credere che nella vostra vita non avete neanche 10 minuti. o forse non ci vogliono esattamente 10 minuti nelle condizioni attuali del codice... no, io direi piuttosto una giornata sana per un task semplice e una settimana per uno complesso; non parliamo dei pair...

Inoltre ci sono stati altri fattori che sicuramente hanno reso il codice difficilmente manutenibile... Ad esempio i refactoring di BigGem e degli stati sarebbero dovuti avvenire molto tempo prima...

eh, fosse solo quello, ROTFL

Io direi di portare il codice ad un livello gestibile e dopo stabilire nuove scadenze...

bravissimo: di nuovo, per ulteriori informazioni fate riferimento al mio messaggio allo staff.

[71104]

Originariamente inviato da thebol

IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task.

---------_________---------''''''

meglio che editi chè sto affilando già la katana -.-'

[71104]

Originariamente inviato da thebol

mi pare ridicolo.
Si è voluto seguire una timeline lavorativa in un contesto non lavorativo.
E poi si chiude il progetto, senza discuterne.

certo, come ho detto anche a cionci: questo è un progetto che, pur essendo affrontato in un contesto totalmente freelance, vuole essere serio e usare metodi professionali in tutti i sensi, non solo nello sviluppo. è in questo che sta la sua didatticità

Ripeto mi pare ridicolo.
Fra l'altro non ho ricevuto la mail, e non capisco una cosa.
Il progetto era di qualcuno? O era del gruppo?
Chi è che ha deciso sta cosa?

il coach, no? ti pare strano? sopresa: il coach è quello che prende le decisioni
lo sai perché c'è un coach? perché deve prendere decisioni che altrimenti non si prenderebbero mai; chi non è d'accordo lo sarà col tempo.

[thebol]

Originariamente inviato da 71104

certo, come ho detto anche a cionci: questo è un progetto che, pur essendo affrontato in un contesto totalmente freelance, vuole essere serio e usare metodi professionali in tutti i sensi, non solo nello sviluppo. è in questo che sta la sua didatticità

sono d'accordo su questo, l'ho gia detto.
Ma se ci sono dei ritardi perche la gente ha esami, ce poco da fare.
Non siamo un contesto lavorativo. Questo è un dato oggettivo.
Ok le deadline, sono uno stimolo e un avvicinarsi ad un contesto lavorativo, ma non è un contesto lavorativo.

il coach, no? ti pare strano? sopresa: il coach è quello che prende le decisioni
lo sai perché c'è un coach? perché deve prendere decisioni che altrimenti non si prenderebbero mai; chi non è d'accordo lo sarà col tempo.

non sapevo che il coach avesse potere di vita o di morte sul progetto.
O forse non ho capito qual è il contenuto della mail che gira :mumble: e che non mi è arrivata.

[cionci]

Originariamente inviato da thebol

IMHO abbiamo cercato troppo la pulizia e la facilta di gestione nel codice dimenticandosi dei task.

ripeto IMHO.

La pulizia invece va cercata...e probabilmente l'abbiamo cercata poco... Prima un task occupava pochi minuti, mentre gli ultimi diverse ore...

IMHO bisogna cercare di ripulire tutto...e reimpostare altre scadenze... In modo da riuscire a ricreare altri task da 10 minuti...

71104: ma in un contesto lavorativo le ore settimanali che un team può impiegare su un progetto sono più o meno una costante... Nel nostro caso invece non lo sono...e questa cosa secondo me andava tenuta di conto...

[thebol]

Originariamente inviato da 71104

---------_________---------''''''

meglio che editi chè sto affilando già la katana -.-'

affila quello che ti pare.
E la mia opinione, e giusta o sbagliata che sia la esprimo.

[thebol]

Originariamente inviato da cionci

La pulizia invece va cercata...e probabilmente l'abbiamo cercata poco... Prima un task occupava pochi minuti, mentre gli ultimi diverse ore...

IMHO bisogna cercare di ripulire tutto...e reimpostare altre scadenze... In modo da riuscire a ricreare altri task da 10 minuti...

La pulizia và cercata, ma non va forzata. Se serve per fare un task bene, altrimenti è yangi. Ok il refactoring(quello delle bigGem è tanto grosso e dispendioso quanto utile), ma se si arriva a fare + refactoring che task, rischiamo di arrivare a dicembre senza aver completato gli obiettivi.

Poi il confine fa troppo e troppo poco è personale, e molto probabilmente si basa anche sull'esperienza che uno ha in queste situazioni(per precisare, la mia è limitata )

Per quanto riguarda i task da 10 minuti:
la complessità dell'applicazione è aumentata, secondo me è utopico aspettarsi che i task(o almeno tutti) richiedano 10 minuti(o cmq poco) per essere fatti. Sicuramente l'uso dell tdd/test/xp etc ha aiutato molto, forse avrebbe potuto fare di piu, ma la complessita è aumentata cè poco da fare. Nell'applicazione ci saranno sempre delle interazioni, si possono diminuire con le tecniche che abbiamo usato ma ne rimarranno sempre e aumenteranno man mano che aumenta la carne al fuoco.



ps.scusa a tutti per il fatto che l'email che avevo dato precedentemente non è piu valida(mi hanno chiuso l'account senza dirmi nulla) e pensavo di averne data un altra :|


pps.secondo me possiamo andare avanti cmq. Ci si conta e si vede il da farsi.
e spero in un ripensamento del coach. Un mio collega con cui ogni tanto faccio una parta, ci rimarrebbe molto male

[cisc]

Originariamente inviato da cionci

71104: ma in un contesto lavorativo le ore settimanali che un team può impiegare su un progetto sono più o meno una costante... Nel nostro caso invece non lo sono...e questa cosa secondo me andava tenuta di conto...

sono d'accordo...penso che questo sia stato un qualcosa che avremmo dovuto tenere in conto...cmq, a me sembra che ci siano ancora molte persone interessate al progetto, dobbiamo cercare di organizzarci a mio avviso in modo tale da considerare queste variabili che prima forse non avevamo tenuto in considerazione...

[71104]

Originariamente inviato da thebol

sono d'accordo su questo, l'ho gia detto.
Ma se ci sono dei ritardi perche la gente ha esami, ce poco da fare.
Non siamo un contesto lavorativo. Questo è un dato oggettivo.
Ok le deadline, sono uno stimolo e un avvicinarsi ad un contesto lavorativo, ma non è un contesto lavorativo.

era solo un esperimento; io ci credevo, e se il progetto riuscirà a riaprire ci crederò di nuovo.

non sapevo che il coach avesse potere di vita o di morte sul progetto.

te l'ho detto: sorpresa!!

O forse non ho capito qual è il contenuto della mail che gira :mumble: e che non mi è arrivata.

nonnò, hai capito benissimo: Diamond Crush è ufficialmente chiuso; diciamo chiuso per restauri, non si sa se riaprirà, ancora una volta dipende solo da noi

[71104]

Originariamente inviato da thebol

affila quello che ti pare.
E la mia opinione, e giusta o sbagliata che sia la esprimo.

farai bene a toglierti queste idee dalla testa perché su Diamond Crush non siamo in una democrazia: la democrazia è troppo lenta e non funziona; siamo in una dittatura, che è molto più veloce ed efficiente. la storia della katana è tutta scena, se non esegui gli ordini e non fai diventare quel codice un bijoux di eleganza altro che katana, vedrai che sensazione le tue ditine...

EDIT: e le tue ginocchia

[Bonfo]

Cosa velocisssima...altrimenti al mia ragazza mi strozza se mi trova qua a scrivere

I task non sono da 10 minuti, mai stati...forse da 1 ora.
E la risposta è : "sì, un ora per Diamond ce l'ho"

Il problema è che i task proposti non sempre sono stati pensati per l'ora (basti pensare che log e playback sono stati assegnati come un task unico e ancora adesso non ne siamo usciti fuori dopo un mese).
Inoltre anche i task pensati per l'ora ora richiedono molto di più perchè il codice è poco gestibile. Uno dei vantaggi edl TDD è che vedi subito i risultati e ti viene voglia di andare avanti e sei "gasato"...bene, con il codice ridotto così le bollicine spariscono appena cerchi di capire cosa fa che cosa e dove mettere le mani.

In ogni caso vedo che siamo tutti d'accordo.
Il progetto non deve morire (mi sento Stephen King ).
Allora non lo si rianima con le parole.
Facciamo vedere al coach che abbiamo le palle.
Mettiamo a posto il tutto e finiamo sti cavolo di refactoring
Poi bombardiamo Jocc di mail finchè non ci dà nuovi task

Domani mi trovate su Diamonds almeno per 1 ora.

FORZA CHE SIAMO ER MEGLIO

[Bonfo]

Originariamente inviato da 71104

te l'ho detto: sorpresa!!

Però almeno parlarne della decisone che si prenderà...

Originariamente inviato da 71104

nonnò, hai capito benissimo: Diamond Crush è ufficialmente chiuso; diciamo chiuso per restauri, non si sa se riaprirà, ancora una volta dipende solo da noi

Appunto.
DIAMOCI SOTTO E FACCIAMO CAMBIARE IDEA AL PROJECT MANAGER