Stima dei costi per una funzionalità di accesso
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.
Le recensioni su Login non prendono quasi mai un 3 — eppure c’è sempre qualcuno che assegna un 3.
La dicitura “Aggiungi login” appare di poco conto perché tutti i presenti nella stanza 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 situazione sembra ben definita fino a quando qualcuno non pone una delle domande riportate di seguito; a quel punto, però, 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 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 stanza
Backend: «Si tratta semplicemente di JWT, disponiamo della libreria necessaria.»
Sicurezza: «La reimpostazione della password non è “solo JWT”».
PM: «È necessario attivare l’autenticazione a due fattori (2FA) fin 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 che vale la pena 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 — oppure 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 “più avanti” 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 della seconda categoria. 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 la sessione; come condurre una sessione descrive il ciclo in quattro fasi. Si vedano gli altri esempi pratici di stima, oppure si avvii una sessione gratuita di Planning Poker e si analizzi questa storia passo dopo passo.