ATALAIAPaso 1Empieza por la historia
La historia de usuario y el objetivo de negocio, tal como los escribió producto.
PRODUCTOComo usuario, veo ofertas de partners y canjeo una con mis puntos.
ATALAIABien. Ahora, ¿qué no debería pasar nunca con esta historia?
Sale de la salaHistoria: canjear una oferta de partner
Paso 2Haz las preguntas no funcionales
Datos, identidad, límites, logging, fallos y abuso.
ATALAIA¿Cuántos redeems por minuto son normales para un usuario?
PRODUCTODos, quizá tres. Diez sería un bot.
DEV LEADHoy registramos el código del vale. ¿Deberíamos?
ATALAIARegistra que ocurrió, nunca el código. Un código es dinero.
Sale de la sala6 preguntas, 6 respuestas
Paso 3Escríbelos como criterios
Criterios de aceptación comprobables, no recomendaciones.
DEV LEADCriterio: como máximo 5 redeems por minuto por usuario, y luego un 429.
QATesteable. Y un caso de abuso: un bot haciendo redeem desde 50 cuentas.
DESARROLLADORUn evento de auditoría por cada redeem, sin el código del vale.
Sale de la sala6 criterios en el ticket
Paso 4Conviértelo en baseline
Las más comunes pasan a ser el valor por defecto de cada servicio nuevo.
ATALAIALos rate limits, los eventos de auditoría y las reglas de secretos pasan a la baseline del servicio.
DEV LEADAsí el siguiente servicio empieza con ellas y nadie las vuelve a discutir.
Sale de la salaBaseline: 12 reglas para cada servicio
- ATALAIA
- PRODUCTO
- DEV LEAD
- QA
- DESARROLLADOR