XP non richiede esplicitamente la creazione di un modello, ma non dice che non dovrebbe mai essere prodotto. Se lo sviluppo di un modello ti aiuta a costruire e quindi a documentare il tuo sistema, dovrebbe assolutamente essere fatto. La differenza è che Agile Modeling ha un'attenzione diversa rispetto alla modellazione del sistema in un ambiente guidato dal piano. In effetti, il sito di modellazione Agile si rivolge anche specificamente a come modelli in un ambiente Extreme .
Gli ambienti agili richiedono un approccio più snello (nello stesso senso di Lean engineering o Lean manufacturing). Alcuni degli inquilini chiave includono la riduzione dei rifiuti, la decisione tardiva e la consegna rapida. Al fine di eliminare gli sprechi, solo la documentazione richiesta viene consegnata alla granularità appropriata. Se produci un prodotto di lavoro, si prevede che il prodotto di lavoro in definitiva aggiunga valore al cliente - i rifiuti sono considerati tutto ciò che non aiuta a aggiungere valore alla persona che lo paga.
In realtà, l'articolo del blog XProgramming collegato a supporta questo:
You may well need some nicely formatted UML for your project...If and when you really need these things, then by all means you should do them. But inside your collocated Whole Team, you most probably will not need them, because the information you need will be communicated through the more effective medium of conversation.
L'articolo Martin Fowler che hai collegato a supporta anche questo:
Certainly XP de-emphasizes diagrams to a great extent. Although the official position is along the lines of "use them if they are useful", there is a strong subtext of "real XPers don't do diagrams".
Un idea centrale dei metodi agili è "individui e interazioni su processi e strumenti" . Non segui un processo o non usi uno strumento per seguire il processo o utilizzare uno strumento. Se l'attività su cui stai lavorando non aggiunge valore o se non produce qualcosa che sia utile a qualcuno (il cliente o un altro tecnico), allora non lo fai.
Martin Fowler continua dicendo:
The primary value is communication. Effective communication means selecting important things and neglecting the less important. This selectivity is the key to using the UML well. ... A common problem with the common use of diagrams is that people try to make them comprehensive.
Ancora una volta, stessa idea. Lo scopo di qualsiasi documentazione è la comunicazione. Se stai producendo cose che non ti aiutano a comunicare il sistema, perché lo stai facendo? Non concentrarti su ogni piccolo dettaglio, ma concentrati sulla comunicazione di un messaggio che fornisce informazioni utili e che aggiungono valore a qualcun altro.
Anche più avanti nell'articolo, Fowler continua a notare che uno dei problemi con gli strumenti CASE è che possono cadere fuori sincrono. Non appena il codice e la documentazione non vengono sincronizzati, il documento non aggiunge alcun valore. Farei anche un passo in più e dire che aggiunge valore negativo, poiché fornisce informazioni false e fuorvianti a chiunque tenti di usarlo per prendere una decisione. Se hai un processo per mantenere la sincronizzazione, va bene. Tuttavia, se non lo fai e lasci che i tuoi documenti non siano sincronizzati, viene visualizzata un'altra domanda: perché li hai? Chiaramente non vengono usati, altrimenti verrebbero mantenuti.
Piuttosto che altre metodologie basate sui modelli che richiedono i modelli, anche se non aggiungono necessariamente alcun valore, XP richiede di spendere tempo e risorse su cose che effettivamente aiutano a fornire valore al cliente / cliente. Se riesci a giustificare che determinati modelli effettivamente aggiungono valore al tuo progetto, allora con tutti i mezzi dovresti produrli. Tuttavia, non dovresti produrre modelli che duplicano altre informazioni o non aggiungono valore.