Stima dei costi per una funzionalità di accesso
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.
Le storie relative all’accesso non ricevono quasi mai un 3, ma c’è sempre qualcuno che vota 3.
La dicitura “Aggiungi login” appare di poco conto perché tutti i presenti in sala hanno già implementato una funzione di login in passato, su un prodotto diverso, sulla base di una serie di decisioni già prese. L’ambito che avete in mente è quello dell’ultima volta, non quello che state per affrontare. La storia sembra una cosa già nota fino a quando qualcuno non pone una delle domande riportate di seguito, e a quel punto non lo è più.
Il problema non è che effettuare l’accesso sia difficile. Il problema è che la discussione si conclude prima che i compromessi siano evidenti. Gli ingegneri backend si aggrappano all’idea che «abbiamo già una libreria per questo». I project manager si aggrappano allo screenshot dello scenario ideale. Chiunque abbia effettivamente realizzato il progetto di recente è colui che rompe il falso consenso, solitamente con una domanda che non figurava nel ticket.
Ciò che viene detto nella sala
Backend: «Si tratta semplicemente di JWT, disponiamo della libreria necessaria.»
Sicurezza: “La reimpostazione della password non è ‘solo una questione di JWT’.”
PM: “È necessario attivare l’autenticazione a due fattori (2FA) sin dal primo giorno, oppure si tratta di un’operazione successiva?”
Frontend: “Ci affideremo a Google e Apple, oppure svilupperemo una soluzione autonoma?”
SRE: “Qual è il limite di frequenza per l’endpoint di accesso?”
Domande da porsi prima di votare
- Esiste una procedura per la reimpostazione della password e chi è il responsabile del modello di e-mail?
- Identità federata (Google, Apple, SSO) o solo nome utente e password?
- Memoria di sessione: JWT, sessione server, entrambe, token di aggiornamento?
- Limitazione della frequenza e blocco dell’account sull’endpoint di accesso?
- L’autenticazione a due fattori (2FA) rientra già nell’ambito di applicazione o si tratta di un “in seguito” intenzionale?
- Registrazione degli audit relativi ai tentativi falliti?
La maggior parte di queste risposte è o “banale” o “merita un ticket a sé stante”. Conteggiate quelle del secondo tipo. Se ce ne sono due o più, non avete ancora una storia: avete un candidato per splitting, e il 3 che stavate per votare misura l’aspetto sbagliato.
Se il Suo team vota 3 al momento dell’accesso, la conversazione non ha ancora avuto luogo. La rimandi.
Correlati: errori comuni nel Planning Poker illustra cosa può andare storto durante una sessione; come condurre una sessione descrive il ciclo in quattro fasi. Si consultino gli altri esempi pratici di stima, oppure si apra una sessione gratuita di Planning Poker e si analizzi questa storia passo dopo passo.