Perché lo sviluppo di Feature Driven è considerato una metodologia Agile?

Forse questo link spiegherà più dettagli. FDD è arrivato prima del Manifesto Agile, quindi non pensare sempre devi praticare XP o Scrum per essere agili o nessuno ha considerato i benefici molto prima.

Dal tuo link wikipedia:

"Its main purpose is to deliver tangible, working software repeatedly in a timely manner."

Non è questo il punto di essere agili? Come BDD, FDD non è appropriato per tutti i progetti. Potresti essere il più grande odiatore di UML sul pianeta, ma potrebbe esserci un progetto che sarà facile da gestire se ne hai qualcuno.

Guarda le ragioni / i problemi risolti da alcune metodologie. Ciò che ti aiuta ad essere agile in un tipo di progetto potrebbe trattenerti in un altro specialmente se pensi che il modo per non fare affidamento su documentazione, contratti, ecc. Sia escluderli completamente.

È la tua definizione di Agile che è sbagliato. Agile sta valutando

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Per prendere i tuoi punti specifici ...

UML is an optional tool

Sì. La maggior parte delle cose sono quando si è agili. Le schede attività sono obbligatorie in Scrum, che è una metodologia Agile, ma non sono obbligatorie per essere agili.

test is documentation test is obligatory

Questa è più una politica TDD. TDD è un'altra metodologia Agile, ma non è una parte obbligatoria dell'essere Agile.

refactoring is a consequence of the changes of the customer and it isn't discouraged.

Non penso che sia scoraggiato anche in FDD. Né è esplicitamente dichiarato. Anche il Manifesto Agile non menziona esplicitamente il refactoring.

Agile è un insieme di principi , non un insieme di metodologie. Le metodologie agili sono metodologie che incoraggiano tali principi.

Non vedo alcun modo in cui FDD non sia Agile.

Beh, non sono un esperto di FDD, ma qui ci sono le mie opinioni sull'articolo di Wikipedia:

Coloured UML has to be used (but documentation isn't necessary);

L'articolo dice che dovresti sviluppare un modello di dominio. Ciò non significa che UML sia richiesto. Immagino che la tua squadra possa decidere quale tipo di linguaggio di modellazione sia appropriato per l'attività.

Instead of pair programming the team is divided by software features

Alcuni processi agili richiedono una coppia di programmazione (XP), altri no, quindi questo non prova che FDD non sia agile.

refactoring is discouraged or, at least, isn't a task with explicit scope;

Non lo vedo è davvero scoraggiato. Ma suppongo che tu abbia ragione, la parte dell'evoluzione di un software (tramite l'applicazione di modifiche a un prodotto esistente) invece di accumulare nuove funzionalità su nuove funzionalità sembra essere ignorata nell'intero processo. Questo è ovviamente un segno di un processo non agile!

unit testing is discretionary, the team leaders can decide

Sembra un processo che si adatta alle esigenze del progetto attuale, che è decisamente agile.

the work flow has to pass through the five FDD phases

Questo potrebbe essere un segno di essere non-agile.

In sintesi, ho l'impressione che FDD cerchi di combinare alcune cose agili (come lo sviluppo iterativo delle funzionalità small ) con alcune cose non agili (processo formale con fasi). Chiamalo semi-agile se vuoi. Inoltre, si noti che lo stesso articolo di Wikipedia che chiama FDD per Agile inizia con la dichiarazione di non responsabilità "Questo articolo non cita riferimenti o fonti ...".