Stima dei tempi necessari per la migrazione dei dati

La migrazione in sé è la parte più semplice. È nella fase di riconciliazione, che Lei ha tralasciato, che si nascondono le difficoltà.

Una migrazione dei dati — ovvero lo spostamento dei dati da un sistema all’altro, oppure da una struttura all’altra all’interno dello stesso sistema — si presenta come una trasformazione. Lettura dalla fonte, trasformazione, scrittura nella destinazione, deviazione del traffico. Il team vota sulla trasformazione. La trasformazione è solitamente la parte di lavoro più piccola della storia. Le difficoltà risiedono in ciò che la trasformazione non rileva: record che sembrano corretti ma fanno riferimento a dati che non sono stati trasferiti, record che sembrano errati ma che in realtà sono corretti in un modo non previsto dalle specifiche, casi limite che sono sopravvissuti solo perché il vecchio sistema li tollerava mentre quello nuovo non lo fa.

Si tratta di un problema diverso dalla migrazione di un database. Una migrazione dello schema modifica la struttura di un singolo archivio contenente già i dati. Una migrazione dei dati trasferisce i dati da un sistema all’altro, e la domanda non è «l’ALTER terminerà in tempo?» — bensì «come gestiamo le righe che non corrispondono a nessuna delle due parti?» La maggior parte del lavoro consiste nella riconciliazione, nella strategia di transizione e nel rollback. Il codice di trasformazione è la parte che si scrive più rapidamente e che si completa per ultima.

Ciò che viene detto nella stanza

Backend: «È uno script. Lettura, mappatura, scrittura. Due giorni al massimo.»

Data eng: “Abbiamo verificato quanto siano sporchi i dati di origine?”

SRE: “Qual è la modalità di transizione: ‘big bang’ o ‘dual-write’?”

Titolo: “Chi risolve i conflitti che non vengono risolti correttamente durante la migrazione?”

PM: «Quando verrà dismesso il vecchio sistema?»

La domanda del Primo Ministro è quella che dovrebbe guidare la stima. Se il vecchio sistema verrà dismesso tra un mese, è necessaria una strategia che garantisca il 100% di accuratezza; se invece rimarrà in uso parallelamente a quello nuovo per due trimestri, ci si può permettere di rimandare la gestione della “coda lunga” a un momento successivo. La stima non riguarda la trasformazione, ma la strategia.

Domande che vale la pena porsi prima di votare

Qual è la qualità dei dati di origine: puliti, sporchi o sconosciuta?
Strategia di migrazione: “big bang”, “dual-write”, “shadow read”, graduale?
Per quanto tempo i due sistemi coesisteranno? È prevista una data di scadenza?
Chi si occupa di risolvere le discrepanze nelle righe che non vengono migrate correttamente, e con quale criterio?
Qual è la procedura di ripristino nel caso in cui il nuovo sistema riceva dati errati dopo il passaggio?
Esistono consumatori a valle (report, integrazioni) che devono essere migrati in modo sincronizzato?

Se il team assegna un voto di 5 e qualcuno dice «un momento, e i registri di audit?», non si trattava di un problema di stima; si trattava piuttosto di due storie che fingevano di essere una sola. Suddividetela: la trasformazione è un ticket, la riconciliazione e il piano di transizione ne costituiscono un altro.

Votate sulla strategia, non sulla trasformazione. La trasformazione dura due giorni. La strategia riguarda l’intero trimestre.

Si veda la stima della migrazione di un database per la variante relativa alla modifica dello schema su un unico sistema, nonché gli altri esempi pratici di stima. Avviare una sessione gratuita di Planning Poker una volta delineata la strategia di transizione.