Agile / XP e l'approccio a strati [chiusa]

Question

Può Agile / XP andare insieme con approccio a più livelli?

Nel caso Agile / XP andare insieme con approccio a più livelli?

Rompere il codice sorgente in strati richiede sforzi supplementari e, quindi, aumenta lo sviluppo in tempo in modo significativo.

NB: Con 'Layers' Voglio dire assemblee separate con POCO, DA, etc

.

Answer 1

Agile / XP è un approccio alla gestione dei vostri attività di progetto, deliverable e scadenze.

Layered applicazioni (N-tier) sono un modo per migliorare la manutenibilità, scalabilità, e la possibilità per i membri del team di aree separate di responsabilità.

Non hanno molto a che fare con l'altro, se non che entrambi richiedono un ulteriore investimento nel tempo se non hai familiarità con ciascuno. Entrambi tendono a migliorare la qualità del vostro progetto, se usato correttamente, rispetto alle alternative tradizionali.

Answer 2

Mi sembra, invece, che l'avvertimento agile "Non avrà bisogno It" Non è quello di evitare la complessità del tutto, ma per evitare di aggiungere complessità inutili. Infatti, uno dei vantaggi di unit testing è di istituire una disciplina in cui è possibile senza paura refactoring in modo roba finisce a cui appartiene, piuttosto che dove si può avere iniziato.

Quindi, il punto non è quello di evitare strati (o livelli, se è necessario) -. Il punto è quello di evitare gli strati che succhiano

Answer 3

I due sono completamente ortogonali.

In XP si sviluppa la funzione di sistema per caratteristica. Quando si aggiungono le caratteristiche si refactoring continuamente il sistema per garantire che la sua implementazione è il più chiaro possibile. Livelli di solito cadono fuori da quella refactoring. Così come livelli se tale architettura è appropriato, o altre strutture architettoniche larga scala come SEDA o di riposo.

Answer 4

Credo che vera questione qui è dovuto sviluppatori diviso da strati su una di squadra dovrebbe avere un dev html, js uno sviluppatore, un livello persona di mezza, una persona sistema di messaggistica, e un DBA lavorando tutti insieme per costruire un modulo CRUD, o si dovrebbe costruire per caratteristica e lasciare che una persona possiede il filo. Quest'ultimo è preferibile in agile- generalisti specializzati sono preferiti agli specialisti.

Answer 5

E 'sensato avere diversi team che lavorano insieme su un progetto Agile? Sì: Ho lavorato su un progetto su larga scala con più di 200 sviluppatori in tutto oltre 15 squadre. C'erano circa 20 o 30 servizi in tutti.

Può questo essere fatto con squadre specializzate? Non proprio.

Possono i membri delle squadre hanno specializzazioni? Sì, ma si ha realmente bisogno generalisti con punti di forza in alcune aree piuttosto che persone che conoscono una sola cosa e non toccare niente altro.