Esempi di stime elaborate

Come valutare una funzionalità di accesso: gli aspetti nascosti (reimpostazione della password, autenticazione a due fattori, 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 Vostro codice, ma nelle peculiarità del provider di identità. Le domande a cui rispondere prima di stabilire un importo.

Come valutare un’integrazione di pagamento: ambiente di test vs ambiente di produzione, rimborsi, webhook, idempotenza, ambito PCI. La discussione che deve avvenire prima di stabilire qualsiasi cifra.

Come valutare una funzionalità di ricerca: pertinenza, ordinamento, 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 trascinamento del file è la parte più semplice; il vero problema sta nei meccanismi sottostanti.

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 stabilire un limite di tempo per l’indagine anziché 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 comporta il rinvio dello sprint.

Come stimare i tempi di una migrazione di database: backfill, durata del blocco, implementazione e rollback. Il comando “Aggiungi una colonna” consiste in una sola riga di SQL; la stima si riferisce 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 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: il lavoro sulla pipeline non prevede una demo, pertanto è 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’implementazione di un limite di rate: soglie, periodi di prova, comunicazioni ai clienti. La parte di programmazione richiede mezza giornata; la vera difficoltà 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 implementate sin dall’inizio. Perché è importante valutare la portata del problema nel suo complesso, anziché considerare un singolo caso.

Come valutare l’implementazione di un feature flag: percentuali per fasi, kill switch, metriche di controllo e la pulizia che nessuno pianifica 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 integrata con l’ingegneria. Il modello è semplice, il vero lavoro sta nei dati. Come definire l’entità di un budget, non una previsione.