Esempi di stime elaborate

Come valutare una funzionalità di accesso: gli aspetti nascosti — reimpostazione della password, autenticazione a due fattori (2FA), federazione, limitazione della frequenza, sessioni — e le domande da chiarire prima che qualcuno esprima il proprio voto.

Come valutare un’integrazione SSO: il lavoro non risiede nel proprio codice, bensì nelle peculiarità del provider di identità. Le domande a cui rispondere prima di stabilire un importo.

Come valutare l’integrazione di un sistema di pagamento: ambiente di test (sandbox) e ambiente di produzione (live), rimborsi, webhook, idempotenza, ambito PCI. Il colloquio che deve avvenire prima che venga stabilito qualsiasi importo.

Come valutare una funzionalità di ricerca: pertinenza, classificazione, faceting e chi è il responsabile dell’indice. Le domande che trasformano la semplice richiesta di “aggiungere una barra di ricerca” in una vera e propria valutazione.

Come valutare un sistema di notifiche: canali, preferenze, deduplicazione e garanzie di consegna. Perché “inviare un’e-mail” si trasforma silenziosamente in un progetto della durata di sei settimane.

Come valutare il caricamento di un file: limiti di dimensione, scansione antivirus, possibilità di riprendere il caricamento, archiviazione e conservazione. Il “trascina e rilascia” è la parte più semplice; il vero problema sta nel funzionamento sottostante.

Come valutare una dashboard: fonti dei dati, frequenza di aggiornamento, fusi orari, analisi approfondita, autorizzazioni. Il grafico è semplice; è la pipeline di dati che sta dietro di esso a richiedere il lavoro vero e proprio.

Come stimare un test instabile: perché occorrono due stime, anziché una sola, e perché fissare un limite di tempo è preferibile a discutere sui punti quando la risposta dipende da ciò che si riscontra.

Come valutare un bug per il quale non è possibile riprodurre il problema: non è possibile quantificare la portata della correzione, ma solo quella della ricerca. Come definire un limite di tempo per l’indagine invece di votare su una story che nessuno può vedere.

Come valutare un calo delle prestazioni: il lavoro consiste principalmente nella diagnosi, non nella risoluzione del problema. Come quantificarlo quando la causa è sconosciuta e lo SLO è a rischio.

Come valutare un bug segnalato da un cliente: è l’account indicato nel ticket a determinare l’entità del problema. Come distinguere una correzione di una sola riga da una risposta che compromette lo sprint.

Come stimare la durata di una migrazione di database: backfill, durata del blocco, implementazione e rollback. Il comando “Aggiungi una colonna” richiede una sola riga di codice SQL; la stima si riferisce all’incirca al secondo.

Come stimare una migrazione dei dati: trasferimento dei dati tra sistemi, riconciliazione e passaggio al nuovo sistema. La trasformazione richiede un’ora; la pulizia dei dati dura un trimestre.

Come valutare l’aggiornamento di un framework: perché il passaggio a una versione principale costituisce un progetto, non un ticket, e come suddividerlo in storie di cui sia effettivamente possibile stimare la portata.

Come valutare l’aggiornamento di una dipendenza: l’aumento a coda lunga che nasconde N picchi in un unico ticket. Legga innanzitutto i log delle modifiche, quindi valuti quanto ha riscontrato.

Come valutare la portata di una revisione completa del processo CI/CD: poiché il lavoro sulla pipeline non prevede una demo, è opportuno suddividerlo in base a ciò che può essere eliminato. Il progetto della durata di un trimestre che si nasconde nel backlog sotto forma di rifattorizzazione.

Come valutare la sostituzione di un’API di terze parti: lacune semantiche, funzionamento in parallelo e presupposti insiti nelle peculiarità del vecchio fornitore. La nuova API appare solo identica.

Come pianificare l’introduzione di un limite di rate: soglie, periodi di prova, comunicazioni ai clienti. La parte di programmazione richiede mezza giornata; la vera sfida sta nel definire limiti che non suscitino lamentele.

Come valutare una modifica al sistema di progettazione: implementazione dei token, percorsi di deprecazione, copertura di Codemod e i 200 punti di chiamata che utilizzano il vecchio componente. Valutare l’impatto a valle.

Come valutare la portata di una correzione relativa all’accessibilità: i problemi di accessibilità (a11y) sono funzionalità che non sono state incluse nella versione iniziale. Perché è importante valutare la portata del problema nel suo complesso, anziché un singolo caso.

Come valutare l’implementazione di un feature flag: percentuali graduali, kill switch, metriche di controllo e la pulizia che nessuno programma mai. Un flag è un piccolo prodotto, non una semplice distribuzione.

Come stimare un picco di attività di ricerca: un picco è un intervallo di tempo definito con un risultato atteso, non una story. Come evitare che si trasformi silenziosamente nel lavoro che avrebbe dovuto essere definito nell’ambito del progetto.

Come valutare un prototipo: si tratta di un prodotto finalizzato all’apprendimento, non all’uso. Come evitare che il codice provvisorio si trasformi nel codice di produzione che nessuno aveva previsto.

Come valutare un esperimento di machine learning: si tratta di ricerca con una componente ingegneristica — il modello è semplice, il vero lavoro sta nei dati. Come definire l’entità di un budget, non una previsione.