Adoro le metodologie agili. In generale, mi piace qualsiasi cosa che ti permetta di seguire correttamente il corso di un progetto.

Tutti vorrebbero l'analisi perfetta che una volta scritta non cambia per farci degli splendidi castelli mentali e creare l'architettura perfetta... ma chiunque abbia lavorato per un pò sa che è impossibile, o comunque se succede, è poco pratica. I requisiti di qualcosa cambiano sempre nel tempo, e l'approccio agile (magari non tutto, ma comunque parti di esso)  è necessario per evitare di crollare.

Informare il cliente della propria metodologia è altresi imperativo, non si può essere agili senza l'appoggio del cliente, o meglio si può gonfiando i tempi di sviluppo per il refactoring, ma entro un certo limite e solo se il referente tecnico del cliente dorme/finge/commercia/whatever.

Ma cosa succede se un cliente abusa del refactoring? L'idea di un progetto che cresce nel tempo e che cambia requisiti è logica, l'idea di un progetto che non dico ogni giorno, ma ogni due si, cambia controlli e funzionalità, secondo me non è naturale crescita del progetto, ma mancanza di direzione. Semplicemente, il cliente non sa che cosa vuole, non l'ha ancora capito, o ha una struttura interna talmente complessa che i diversi scomparti non si capiscono...

In questi casi è importante, secondo me, non abusare del refactoring e continuare a modificare tutto solo "perchè è agile", ma fermarsi un secondo, scalare marcia, e considerare col cliente l'ipotesi che non si abbia la piu pallida idea della scopo del progetto. Questo, poi, cambierà, è ovvio, ma non per i gusti personali dell'interlocutore di turno, ma per reali necessità logiche e/o pratiche.