Interessante Davide. Mi piacerebbe avere opinioni su altri iscritti al forum a riguardo.

no no qualcosa non mi torna, le metodologie agili sono nate proprio per favorire le iterazioni rapide ed i cambi di design.

Non sono metodologie da comprare in toto ne' sono una nuova religione, spesso anzi basta applicarne una sotto parte per gia' essere concretamente piu' produttivi. Del resto tu stesso hai detto che fai TDD da 15 anni (che anche qua il test se lo scrivi dopo il codice va bene eh), siccome abbiamo lavorato assieme so anche che fai refactoring. In tal caso stai gia' coprendo due punti cardine dell' XP e in piu' so anche che avendo lavorato fianco a fianco con te che abbiamo fatto anche pair-programming e siamo a 3 che poi fatta con te diventa cool-programming che e' una metodologia nostra

Ora gia' cosi, senza affibbiargli un ulteriore nomenclatura siamo piu' che agili. Be non voglio andare oltre, i contesti anche nello sviluppo dei videogiochi sono diversi (r&d, tool, librerie, gioco vero e proprio...) cosi sicuramente ci sono aspetti che funzionano altri meno ma fregatene se sono state chiamate a rapporto dalle metodologie agili o che a te le abbiano presentate col powerpoint. A me per esempio mi hanno dato un pomodoro una volta,  con me non funziona ma la curiosita' e' nata ed altre cose sono venuto da se.
Il succo sta nel fare proprio solo quello che aiuta e ci sono tante altre cosette che aiutano oltre alle 3 di sopra. Posso farti mille esempi di come il refactoring diventa un dito nel culo senza unit tests o test di integrazione, ma penso che tu lo sappia benissimo anche da te, mentre sono generalmente daccordo su altri aspetti come lo scrivere i task/goal/bugs su una lavagna invece che sul matis/bugzilla di turno o non scriverli affatto.

Anzi a me tutto quello che non viene archiviato elettronicamente da un computer mi pare una perdita di informazione utile ai vari fini del caso.

giusto quindi chi non e' come lui non andrebbe neanche assunto...ahahaha scherzo dai...

infatti alludevo a cio' quando ho scritto:
"quindi meglio che niente considerato che con team enormi gli agnellini sono una necessita"

c'e' anche una categoria di programmatori che io chiamo "the princesses". Della serie "so meglio io, me la cavo da solo". Uno si deve adeguare alle metodologie usate nell'azienda dove lavora. Ovviamente libero di fare sentire la sua voce se pensa che qualcosa sia una cazzata, pero' in generale le preferenze personali andrebbero lasciate a casa. Perche' se ognuno si mette a fare le cose come piace a lui si passa la giornata a litigare e non si va da nessuna parte :p

Alla fine ogni metodologia usata e imparata e' esperienza personale, e spesso anche se all'inizio ero scettico, alla fine mi sono trovato ad apprezzare alcuni aspetti o a rivalutare certe cose che reputavo sbagliate. In generale comunque l'importante e' prendere gli aspetti migliori da ogni metodologia e farne tesoro personale IMHO.

All'inizio ero allergico al TDD, adesso per alcuni aspetti del game development sono ancora convinto che sia impraticabile, ma su certi altri aspetti l'ho rivalutato completamernte e mi ha aiutato molto sia nel trovare potenziali problemi sia dal punto di vista di design. Normalmente codice test friendly significa semplicemente codice ben strutturato. L'essere test friendly e' solo un effetto collaterale

Mi ricordo qualche tempo fa dopo avere implementato un plugin per migliorare i radiosity bakes in game mi hanno chiesto di aggiungere unit test support. All'inizio pensavo fossero pazzi, dopo 1 notte a rigirarmi nel letto per inventarmi un test che avesse senso con roba graphics related ho scritto sto test e ho trovato un bug che stava nella code base da un paio di anni, era difficilmente percettibile e solo gli artists "maniacali" si lamentavano di alcuni bakes un po' troppo bright che dovevano correggere a mano. Ebbene, il test falliva dicendomi esattamente dove era il problema e l'ho fixato in 1 minuto. Ogni tanto ricredersi positivamente fa piacere. Male che vada, sono sempre esperienze :p

Poi cmq in generale e' come dice Marco: ogni metodologia va adattata alla propria azienda. Seguire alla cieca i principi teorizzati da qualche santone non ha senso e il tipo di software prodotto e' molto importante: si deve prendere quello che puo' risultare utile al proporio settore ed applicarlo.

Poi ovvio, anche i technical directors e i producers sono umani e possono fare scelte sbagliate...c'est la vie :p

Ok. Siamo d'accordo 

Bhe se uno si sente piu figo e migliore degli altri, non dovrebbe aver problemi ad adattarsi a qualsiasi metodo no?
Vuol dire che qualsiasi metodo usato, rispetto agli altri del team sapra' dare stime migliori, completera' sempre i task in tempo, senza bug etc.