Stima dell'impatto di una modifica al sistema di progettazione

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 presenta 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 continuano a utilizzare quello vecchio. La stima deve includere l’implementazione (codemod o migrazione manuale, tempistica di obsolescenza, strategia di regressione visiva); in caso contrario, il lavoro rimarrà semplicemente in sospeso per mesi, mentre i team di funzionalità se ne occuperanno quando ne avranno la possibilità.

Ciò che viene detto nella sala

Progettista: «Il nuovo token comporta una modifica di una sola riga.»

Frontend: “Quanti componenti lo utilizzano attualmente?”

Domanda principale: “Stiamo effettuando una modifica del codice, oppure sono i team funzionali a occuparsi autonomamente della migrazione?”

Domanda: “Regressione visiva: Percy? Manuale? Entrambi?”

PM: “Qual è il periodo di dismissione previsto per la versione precedente?”

Domande da porsi prima di votare

• Quanti siti di chiamata sono interessati, secondo dati effettivi anziché stime?
• Codemod o migrazione manuale? Qual è la copertura del Codemod?
• Qual è la tempistica prevista per il percorso di obsolescenza (avviso, errore, rimozione)?
• È 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 ambiente di produzione?

La modifica a monte è minima, mentre il lavoro vero e proprio consiste nella riorganizzazione a valle; pertanto, separatele: il nuovo componente costituisce una story, mentre la migrazione dei punti di chiamata ne costituisce un’altra, e la dimensione di quest’ultima si basa sul conteggio effettivo, non su 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 consultino gli altri esempi di stime già elaborate, oppure si avvii una sessione gratuita di Planning Poker una volta quantificato il lavoro a valle.