Problemi di coordinamento tra software e team di database

Rendi gli specialisti di database parte del team anziché separarli. Gli sviluppatori di database / sviluppatori DBA di sviluppo non devono essere a tempo pieno su ogni progetto, ma devono assolutamente far parte del team, far parte degli standups quotidiani, recensioni, ecc. E avere la proprietà congiunta dei deliverable insieme al resto del team. / p>

Produce le linee guida per lo sviluppo del database in anticipo e assicurati che tutti sappiano a cosa servono e come applicarle.

Assicurati che il test con dati di dimensioni reali sia parte di ogni iterazione e di ogni ciclo di test, non solo di quelli successivi. Questo passaggio da solo dovrebbe risolvere la maggior parte dei problemi e delle tensioni che possono verificarsi tra sviluppatori e DBA.

Adottare approcci di sviluppo di database agili e iterativi. Ciò significa progettazione di database evolutiva, integrazione continua, alto grado di normalizzazione del database e un approccio rigoroso alle regole aziendali (applicare le chiavi e altri vincoli di integrità in anticipo e quindi rimuoverli in seguito se ne trovi la necessità).

Non penso che ci sia una risposta giusta o sbagliata a questa. Tuttavia, sono stato in situazioni simili in passato, e spesso la storia politica e organizzativa ha determinato chi aveva quale ruolo, piuttosto che una decisione razionale basata sui bisogni del progetto.

Ad esempio, in una squadra, ogni tabella di database doveva essere approvata da un dba; questo ha rallentato enormemente la squadra, ha reso i DBA scontrosi e sovraccarichi di lavoro, e quando abbiamo chiesto perché questo processo è stato istituito, nessuno potrebbe ricordare - così ci siamo sbarazzati di esso.

Nel tuo caso, immagino che le prestazioni del database siano una parte fondamentale del tuo successo. Il modello migliore che ho visto è quello di avere team multidisciplinari che lavorano su caratteristiche specifiche; all'interno della squadra, si elabora chi è in testa. È molto, molto più facile lavorare in una squadra in cui ogni specialismo è rappresentato (anche se solo part time) rispetto ai confini del dipartimento formale.

Nel nostro caso i DBA non dettano il design. Tuttavia, dispongono di una serie di linee guida (Azioni / Donazioni) per il team di sviluppo da seguire durante la creazione di database, la distribuzione di database o la distribuzione di script o processi SSIS o rapporti SSRS.

La natura del ruolo DBA è condivisa tra i progetti e sono per lo più sovraccarichi di richieste e questo è il problema o il problema più comune. La soluzione è sufficiente tempo di consegna e follow-up. Quanto è abbastanza ?? - Parla con il tuo DBA e conosci ..

Il team di sviluppatori ha bisogno di qualcuno con competenze simili a DBA, ma non ha bisogno di un DBA perché la maggior parte di ciò che fa il DBA non è di alcuna utilità durante il progetto di sviluppo.

I problemi usuali sono che il database viene consegnato al DBA per "tuning" prima della distribuzione, ma poi è troppo tardi. Il problema è che il DBA non ha idea di cosa debbano essere usate le tabelle, come vengono interrogate, chi userà il database e quando lo faranno. Quando trovano qualcosa su cui migliorare, spesso si scopre di aver bisogno di una riprogettazione. Molto costoso.

I problemi dall'altra prospettiva sono che i DBA che non sono coinvolti attivamente nello sviluppo non comprendono la maggior parte dei problemi che devono essere affrontati durante l'analisi o lo sviluppo e respinge la maggior parte dei problemi come "non dovrebbe accadere con analisi corretta ". Il che è vero in un certo senso, ma troppo semplicistico per essere di qualche utilità.

Girare le persone tra le diverse funzioni è un ottimo modo per trasferire le conoscenze e migliorare i metodi di lavoro di entrambi i team. Aggiunge alcune conoscenze di progetto al team DBA e aggiunge alcune competenze DBA ai team di sviluppo.

Anche se sono d'accordo con gran parte di ciò che è scritto in questo articolo, penso che i team di un singolo non siano ottimali a causa della mancanza di trasferimento di conoscenze. Ma sono d'accordo con i team di personale con persone come loro descrivono.
The Spanner: The Sviluppatore BI di prossima generazione

Il database e i team di sviluppo hanno entrambi prospettive diverse. Entrambi sono importanti e devono essere coordinati. Avere qualcuno dal team di database come parte del team di sviluppo sarebbe una buona idea. Dovrebbero venire al progetto con gli standard e la capacità di sfruttare i dati aziendali esistenti per questo progetto.

La prospettiva dei team di sviluppo sarà incentrata sulle esigenze del progetto. Il ciclo di vita dei dati all'interno del progetto è in genere misurato in ore o giorni. Dopo che i dati in molte tabelle diventano artefatti storici.

Dal punto di vista dei team di database, i dati diventano parte delle risorse aziendali. Potrebbe essere necessario mantenere i dati disponibili per anni. È il team di database che dovrà conservare questi dati e infine eliminarli. Il team di database dovrebbe avere maggiore familiarità con i problemi di conformità alle normative che si applicano ai dati.

Le questioni in esame dovrebbero stabilire se il team del software o il team del database dovrebbero avere la precedenza. Mirare al consenso è l'opzione migliore. Le due squadre dovrebbero essere preparate ad ascoltare apertamente le preoccupazioni dell'altra. Incoraggiare attivamente il team di database nel design dovrebbe essere incoraggiato. Cerca di evitare di lanciare problemi al muro.