Sono abbastanza d'accordo. Le metodologie agili hanno degli ottimi spunti ma non possono essere prese "tal-quali" per un'intera azienda che fa videogiochi, specialmente se a un certo livello.
Vanno molto bene per progetti relativamente brevi e senza grandi sfide tecnologiche.
Tuttavia l'approccio fornisce ispirazioni utilissime: ad esempio può essere applicato con successo per alcune parti (importanti) dello sviluppo e usato come motivo ispiratore nel senso di:

• avere work package piccoli minimizzando i rischi di ritardi
• effettuare verifiche frequenti sui task e sul lavoro
• favorire l'auto-pianificazione
• incrementare il lavoro di gruppo (per questo ci sono metodologie interessanti a parte)
• favorire la flessibilità

In generale, però, le metodologie agili non nascono per i videogiochi: come ho detto molte volte, i giochi hanno una differenza enorme rispetto al resto del software, cioè che non servono a produrre "documenti" (o cmq dei risultati ben definiti).
Se è facilissimo gestire, ad esempio, l'interazione con il cliente nel caso di un sito di e-commerce, è più difficile (non ho scritto "impossibile") farlo con un videogioco, in cui innanzitutto c'è un doppio layer (publisher e cliente) e in secondo luogo non esiste un obiettivo necessariamente chiaro.
Tuttavia l'approccio agile di non avere specifiche rigide è applicabile nel senso di non avere un game-design rigido.
Strutturarsi in modo estremamente robusto e dinamico, sia a livello tecnico che di design, scrum o non scrum, e sicuramente una buona idea.
A mio parere l'importante non è tanto rispettare tutte le deadline interne e intermedie, quanto capire bene quale e dove sia il problema che causa un ritardo e reagire in modo dinamico e rapido: in questo senso anche per la ricerca l'approccio agile è sensato.

Voglio aggiungere anche una cosa impopolare.
Il modello del programmatore "Cow Boy" è sicuramente un esempio negativo in generale (cioè non va insegnato) ma, quando uno è veramente bravo, a volte bisogna lasciarlo fare " a cavoli suoi".
Mi spiego meglio: se devo insegnare a suonare la chitarra non dirò "hey, prendi la chitarra, alza il volume e lasciati trasportare dal tuo cuore" perché nel 99.99% dei casi causerò solo cacofonia, ma uno su diecimila è un Jimi Hendrix e a lui bisogna dare spazio, se ce lo si può permettere.

My two cents.

2 premesse fondamentali prima di risponderti:

1) Ho sperimentato l'introduzione dello Scrum in un progetto precedente e per noi è stato un fallimento perchè:
   a) ho sottovalutato la complessità della cosa: senza alcuna esperienza e con alle spalle un semplice studio dei docs in giro, ne derivano solo errori di gestione;
   b) probabilmente l'avrò spiegato male io (tanti concetti alle spalle del metodo sono del tutto empirici, non è semplice assimilarli ed è difficile spiegarli con chiarezza), ma sicuramente non è stato per nulla capito e quindi accettato all'interno del team ed alla fine era considerato più un peso che un sollievo.

2) E' un metodo che in sottinteso considera molte cose per scontate: tecnologia consolidata alle spalle, scadenze "versatili" o comunque "contrattabili", ma in particolar modo da solo non produce i risultati sperati senza l'ausilio del Test Driven Development usato in modo intensivo da tutto il team.

Detto questo, hai perfettamente ragione sui tuoi dubbi. Nello short term planning è efficacissimo, ma a lungo termine lo paghi se il planning iniziale non è molto, ma molto più che accurato o se non hai una tecnologia collaudata alle spalle che non richiede stravolgimenti.
Per intenderci durante un cambio di piattaforma è a dir poco un disastro se la build non viene passata attraverso una serie di test automatici che ne coprono almeno il 70% delle funzionalità: dal nulla valanghe di bug esplodono senza preavviso e tutti si domandano a cosa servono le stime se poi ci si ritrova sommersi dai bug.
Ovviamente i test automatici costano tempo per svilupparli, pertanto (classico errore che poi si paga con gli interessi) non si scrivono, affidandosi ai tempi normalmente non immediati dei tester in carne ed ossa.


Si: non è per niente adatto alla ricerca. Si: vi adatterete al metodo e non il contrario.
Tuttavia spezzo una lancia a favore dello Scrum: il metodo "raccomanda vivamente" che il 100% non lo deve dire chi si occupa del task, bensì il tester (automatico o umano) che si occupa di verificarne il funzionamento! Pertanto non dovrebbe essere il developer a dichiarare il completamento dei suoi tasks, ma solo il passaggio alla fase di verifica precedente al 100%.
Ho detto "dovrebbe"!


E' una grossa grezzata che sia stato spacciato così, poichè secondo il metodo è la percentuale di test passati la misura del lavoro fatto, non il codice eseguibile.


Esatto.

Di "agile", in questi pizzi, facciamo lo standing meeting mattutino di 10 minuti.
Utile soprattutto se c'e' qualcuno che durante il giorno non comunica molto, o comunque fra teams diversi (siamo appena una diecina pero').

Ma alla fine per fare un meeting la mattina non credo che uno debba andare a scomodare  una metodologia 8)

dipende da cosa si intende per complessita. una roba che dura molto non e' necessariamente complessa ma puo essere solo ripetitiva?
quindi si puo avere che  A e' molto piu complessa di B ma in B semplicemente ci vuole piu tempo. cosa intendi per complessita? esempio terra terra: camminare e' piu semplice di correre e per arrivare da A a B ci vuole di piu, quindi camminare e almeno 100 volte piu complesso?

ciao,
Antonio

Infatti, l'ho detto, ci vuole della gente brava per usare queste metodologie. 
Se B è meno complesso di A e ci vuole più tempo -> hai fatto qualcosa di ripetitivo -> hai usato il metodo meno furbo per implemntarlo, ovvero, essendoci codice ripetuto, potevi rifattorizzare o più semplicemente non hai usato la soluzione più semplice E se per rifattorizzare ci metti molto più di A, allora significa che B era più complesso perchè richiede più attenzione nell'essere sviluppato. 

Facendo il tuo caso:
Per andare dal tabaccaio sotto casa a piedi mettendoci 10 minuti è meno complesso di andarci in macchina in 12.
Camminare da Bologna a Milano e impiegarci giorni è molto "più complesso" di prendere il treno.

Alla fine c'ho che conta è il risultato.
 
Ovvio che dipende, perchè a una settimana dalla deadline lo sappiamo tutti che il codice diventa un po' una pattumiera e il codice ripetuto è più che accettabile, ma in generale...


L'invenzione è nell'avere review immediate. In un certo senso, e spero che i puristi mi perdoneranno, l'Agile e semplicemente il modello a spirale all'ennesima potenza.

L'altra cosa fondamentale dell'agile che è stata ancora toccata poco è: "non pensare ai probelmi che non hai". YAGNI

penso semplicemente che certi statements siano supercommonsense e che appartengono al comune pensare della vita quotidiana e che sono vecchi come il mondo.

cmnq a mio avviso il metodo non e' molto adatto alla ricerca o cose piu creative. per la parte di development puro come ho gia scritto puo andare piu che bene.

ciao,
Antonio

giusto non ricordo chi diceva che non si capisce perche si chiama common-sense dato che poi la maggior parte sembrano esserne privi:)
ciao,
Antonio