Definizione del modello di dati nella metodologia Agile

1

Ho sempre capito che in agile, ogni sprint riguarda l'aggiunta di una nuova funzionalità all'applicazione esistente, in modo che l'applicazione possa essere costruita in modo incrementale.

D'altro canto, quando si definisce il modello di dati, è necessario pensare a molti possibili casi d'uso e funzionalità in anticipo, in modo che il modello di dati soddisfi un'ampia gamma di essi e le prestazioni delle operazioni CRUD siano soddisfacenti. Questo di solito è un caso quando si inizia un nuovo progetto. Potrebbe essere difficile modificare il modello di dati in un secondo momento, in modo incrementale, poiché potrebbero essere associate a troppe funzionalità esistenti. In questo caso sono abituato alla metodologia waterfall.

Quindi in che modo queste due metodologie di conflitto possono essere combinate insieme nella definizione di un modello iniziale di dati? O c'è un terzo modo?

    
posta dzieciou 19.11.2014 - 20:35
fonte

2 risposte

5

Devi modellare quanto basta in anticipo per sentirti a tuo agio nell'avanzare responsabilmente. Rinvia il più possibile alla modellazione finché non ti senti più a tuo agio a differire ulteriormente.

Come sai quanto può essere rinviato responsabilmente? Esperienza.

Una premessa di base dello sviluppo Agile è che non si spreca fatica a fare cose che non forniscono valore. Ovviamente, la corretta modellazione dei dati fornisce valore e deve essere fatta.

Ma la storia ha dimostrato che provare a pianificare / modellare tutto in anticipo porta di solito a progetti che, se strettamente rispettati, non finiscono per fornire il valore che ci si aspettava.

In alternativa, se i piani dovessero cambiare, lo sforzo dedicato alla progettazione iniziale potrebbe essere stato essenzialmente sprecato e potrebbe essere stato speso per qualcos'altro.

Lo sviluppo agile è un'arte che sfrutta l'esperienza per ridurre al minimo lo sforzo sprecato rinviando responsabilmente determinate decisioni di progettazione fino a quando tali decisioni devono essere prese, e abbiamo le migliori informazioni con le quali prendere le nostre decisioni. Questo è raramente all'inizio di un progetto.

Se, nel tuo caso, ritieni che sia irresponsabile andare avanti con qualsiasi parte della tua applicazione fino all'intero modello di dati, allora non c'è nulla in Agile che ti impedisca di farlo. Ma la maggior parte dei professionisti Agile direbbe che una tale situazione si verifica raramente.

    
risposta data 19.11.2014 - 21:11
fonte
1

Questo è simile all'architettura dell'applicazione stessa. Invece di fare tutta l'architettura prima di iniziare il progetto, fai solo ciò di cui hai bisogno, e poi lo cambi, in modo incrementale.

Lo stesso vale per il modello di dati. Se stai sviluppando un sito Web di e-commerce e inizi dalla funzionalità di visualizzazione dei prodotti, avrai bisogno del modello di dati corrispondente che descrive come vengono archiviati i prodotti, ma non hai bisogno del modello di dati degli utenti, della spedizione o delle newsletter ancora.

Questo ti consente di concentrarti sul problema reale che hai ora (visualizzazione dei prodotti), mentre tieni da parte le cose che non sono ancora definite bene e possono cambiare nel tempo .

Ad esempio, il cliente potrebbe decidere alcune settimane dopo di non aver più bisogno di implementare alcuna newsletter. Se hai trascorso tre ore a progettare il modello di dati delle newsletter prima di iniziare il progetto, hai perso tre ore del tuo tempo (più il tempo necessario ora per sbarazzarsi di questa parte del modello).

Si noti che la modifica dello schema esistente in base alle piccole modifiche nel modello di dati può essere molto dolorosa (si immagini se è necessario passare gli ID dei prodotti da GUID a bigint mentre il sito Web di e-commerce è già utilizzato in produzione ). Spostarsi da database con schemi rigidi, come Microsoft SQL, a database meno rigidi, come MongoDB, può essere una soluzione.

    
risposta data 19.11.2014 - 21:27
fonte

Leggi altre domande sui tag