Stima dell'impatto di una modifica al sistema di

L’articolo fornisce una stima relativa al nuovo componente, tralasciando però i 200 luoghi in cui viene utilizzato quello vecchio.

Una modifica al sistema di progettazione ha due ambiti. Il primo è il sistema stesso: il nuovo componente, il nuovo token, la documentazione aggiornata. Il secondo riguarda i punti di chiamata: ogni funzionalità del prodotto che utilizzava la versione precedente e che deve essere migrata a quella nuova. Il primo ambito è limitato e ben definito. È il secondo, invece, a determinare che il lavoro richieda effettivamente un trimestre.

I team che implementano la modifica a livello di sistema senza un percorso di obsolescenza si ritrovano a gestire due sistemi: quello nuovo e tutte le parti che utilizzano ancora quello vecchio. La stima deve includere l’implementazione — tramite Codemod o migrazione manuale, tempistiche di obsolescenza, strategia di regressione visiva — altrimenti il lavoro rimane semplicemente in sospeso per mesi, mentre i team funzionali se ne occupano quando ne hanno la possibilità.

Ciò che viene detto nella stanza

Progettista: «La modifica al nuovo token consiste in una sola riga.»

Frontend: “Quanti componenti lo utilizzano attualmente?”

Lead: “Stiamo effettuando un codemod, oppure i team funzionali stanno procedendo autonomamente alla migrazione?”

QA: “Regressione visiva — Percy? Manuale? Entrambi?”

PM: “Qual è il periodo di dismissione della versione precedente?”

Domande che vale la pena porsi prima di votare

Quanti siti di chiamata sono interessati — secondo dati misurati, non stime?
Codemod o migrazione manuale? Qual è la copertura del Codemod?
Percorso di obsolescenza: avviso, errore, rimozione — con quali tempistiche?
È prevista una copertura della regressione visiva sugli schermi interessati?
Comunicazioni tra i team: a chi lo comunichiamo, quando e in che modo?
È opportuno effettuare un rollback qualora il nuovo componente presenti un bug che emerge solo in produzione?

La modifica a monte è minima, mentre il lavoro vero e proprio consiste nella riorganizzazione a valle; pertanto separatele: il nuovo componente costituisce una storia, la migrazione dei punti di chiamata ne costituisce un’altra, e la seconda viene dimensionata in base al conteggio effettivo — non a una stima.

Si valuti la migrazione a valle. Il nuovo token è una linea; i 200 punti di chiamata rappresentano il trimestre.

Come nel caso della stima di un aggiornamento del framework, la modifica a monte è minima e il lavoro consiste nella riorganizzazione a valle. Si vedano gli altri esempi di stime già elaborate, oppure si avvii una sessione gratuita di Planning Poker una volta quantificato il lavoro a valle.