Stima dei tempi di implementazione di un limite di velocità

La realizzazione del codice richiede mezza giornata. L’implementazione richiede due mesi.

I limiti di velocità sono facili da implementare ma difficili da applicare. Il middleware è un modello ben noto. La parte difficile consiste nello stabilire soglie che non suscitino lamentele, e l’unico modo per farlo è misurare l’utilizzo attuale, annunciare i limiti in anticipo, monitorare un periodo di prova per individuare chi sarebbe stato bloccato, dare voce a chi si lamenta e solo allora applicare le restrizioni. Questa sequenza di operazioni richiede un certo impegno e non rientra nei tempi di uno sprint.

I team che valutano il middleware tralasciano completamente l’implementazione. I team che valutano l’implementazione ottengono una stima molto più elevata, si chiedono se sia effettivamente urgente e, di solito, decidono di suddividerla in più cicli, il che rappresenta la risposta corretta. Valutare l’intero progetto in un’unica soluzione costringe il team a una falsa scelta binaria.

Ciò che viene detto nella stanza

Backend: “Il middleware è una questione di un giorno. Disponiamo di una libreria.”

SRE: «Quali soglie? Abbiamo esaminato il p99 dei consumi attuali?»

PM: «A chi dobbiamo inviare un’e-mail prima che questo si attivi?»

Assistenza: “Cosa indica il codice di risposta 429? È previsto un nuovo tentativo?”

Titolo: “Prima la modalità di prova, o si passa direttamente all’applicazione?”

Domande da porsi prima di votare

• Abbiamo misurato il consumo di corrente ai livelli p50, p95 e p99 per ciascun cliente?
• Quali sono i valori soglia e in base a quali criteri sono stati scelti?
• Per account, per indirizzo IP, per chiave API? Combinazioni?
• Periodo di prova: quanto dura e cosa si intende per “senza sorprese”?
• Comunicazioni con i clienti: a chi inviamo le e-mail e con quanto anticipo?
• Come si presenta la risposta 429: messaggio, tempo di attesa prima di un nuovo tentativo, link alla documentazione?
• Qual è la procedura da seguire per un cliente che necessita di un limite più elevato?

Distinguiamo i vari aspetti: l’applicazione delle norme è una questione, la simulazione e la comunicazione ne costituiscono un’altra, mentre la regolazione delle soglie ne rappresenta una terza. Ciascuna di esse è di per sé significativa; l’insieme, invece, non lo è.

Si deve dimensionare l’implementazione, non il middleware. La chiave sta nel misurare, comunicare e effettuare simulazioni.

Si veda la sezione dedicata alla stima dell’implementazione di un feature flag per comprendere lo stesso meccanismo per cui “l’implementazione assorbe il lavoro”, nonché gli altri esempi di stima già elaborati. Si avvii una sessione gratuita di planning poker una volta definite le fasi.