¿Cómo defines criterios de entrega?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Los criterios de release son las condiciones acordadas bajo las que una build puede llegar a los usuarios, decididas antes de la release para que no se negocien a la baja bajo presión. Combinan evidencia funcional, como la suite de regresión en verde y las funcionalidades nuevas verificadas, con evidencia de riesgo: sin defectos abiertos por encima de una severidad acordada, escaneos de seguridad y dependencias limpios o con excepciones aceptadas, rendimiento dentro de umbrales en un entorno similar a producción y observabilidad preparada para ver problemas. Incluyen preparación operativa: migración probada, rollback ensayado, soporte informado y la firma del interesado dueño del resultado. Lo no cumplido se arregla o se exime explícitamente por ese dueño con el motivo registrado.

Ejemplo

La lista de release de una actualización de pagos: suite de regresión en verde en la candidata, todos los defectos sev-1 y sev-2 cerrados, sin hallazgos críticos de dependencias, p95 del checkout por debajo de 400 ms en la prueba de carga de staging, paneles y alertas actualizados para los endpoints nuevos, migración aplicada a una instantánea de producción en menos de 5 minutos, rollback probado, equipo de soporte informado y firma del product owner de pagos. Un sev-2 se eximió con una solución temporal documentada y fecha de arreglo.

Errores frecuentes

• Decidir los criterios cuando la build ya está lista y ajustarlos para que encajen.
• Contar pruebas superadas como criterio sin considerar los riesgos abiertos.
• Publicar sin ensayo de rollback porque el despliegue siempre ha funcionado.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.