Puertas de aprobación
Las puertas de aprobación (approval gates) son los puntos en desarrollo guiado por especificaciones donde una persona ejerce criterio entre fases, antes de que un problema llegue a la fase siguiente y sea más caro de corregir. Hay tres puertas principales —una entre cada par de fases del núcleo— más la revisión de convergencia al cierre. Concentran la revisión humana donde la información vale más, en lugar de dispersarla durante la implementación.
Si las fases son el cuerpo de SDD, las puertas son su sistema nervioso: son los puntos donde se detectan los problemas antes de que sean caros y donde el equipo se alinea. El principio rector del método se resume en revisar en las puertas de fase, no durante la implementación. En el trabajo conversacional, quien programa aprueba microdecisiones una a una, lo que produce fatiga de aprobación; SDD reúne esa revisión en unos pocos puntos y, una vez aprobadas las tareas, la implementación se ejecuta con intervención mínima porque el contrato ya está claro.
Qué se revisa en cada puerta
| Puerta | Pregunta | Qué se comprueba |
|---|---|---|
| 1 · Requisitos → diseño | ¿Resolvemos el problema correcto? | Historias que reflejan necesidades reales, criterios verificables, alcance manejable y requisitos implícitos detectados (seguridad, rendimiento, accesibilidad). |
| 2 · Diseño → tareas | ¿El diseño es viable y coherente? | Respeta los patrones del código existente, sus decisiones están justificadas y sus dependencias y riesgos, identificados. |
| 3 · Tareas → implementación | ¿Estas tareas, en este orden, producen el diseño? | Cobertura sin huecos, dependencias correctas, prompts precisos y criterios de éxito evaluables. |
| Convergencia | ¿Lo construido coincide con lo especificado? | Es la envoltura final del flujo, y la única revisión que mira código. |
La lógica del coste del error por fase
Detrás de las puertas hay una razón económica: el coste de corregir un error crece de forma acelerada con cada fase que atraviesa. Un criterio de aceptación ambiguo se corrige en requisitos reescribiendo una frase; si llega al diseño, hay que repensar la solución; si llega a las tareas, hay que rehacer la descomposición; si llega a la implementación, hay que descartar y regenerar código. Cada minuto invertido en revisar un requisito ahorra horas de reimplementación.
Las tres primeras puertas revisan documentos de texto, y eso las hace más accesibles (participan también quienes no programan), más rápidas (leer una spec es más veloz que leer código) y más enfocadas (la pregunta «¿es esto lo que queremos?» se separa de «¿está bien implementado?», que se reserva para la convergencia). La aprobación, eso sí, es un acto y no un trámite: una puerta que se cruza sin leer no detecta nada y da una garantía falsa.
El cuello de botella de la revisión
La evidencia de 2026 añade un contrapunto. El informe de DORA identifica la revisión manual como el cuello de botella que se satura cuando la velocidad de generación de código sube: las puertas concentran la revisión y, por eso mismo, son el punto donde el sistema se atasca si la capacidad de revisar no crece al ritmo de la de generar. Una puerta mal dimensionada deja de proteger y empieza a frenar. Kief Morris plantea la cuestión desde el reparto de personas y agentes en los bucles de la ingeniería: en qué puntos la persona aporta un criterio que el agente no tiene, y en cuáles su intervención solo añade latencia.
La respuesta al atasco no es eliminar la puerta, sino descongestionarla:
- Delegar la aprobación en quien tiene criterio.
- Admitir la aprobación asíncrona, sin exigir que todos coincidan en el tiempo.
- Dimensionar las specs para que la revisión sea corta (véase Clarity Gate y Maldición de las instrucciones).
- Automatizar lo mecánico: la parte de la comprobación que no requiere criterio, como el análisis de coherencia entre documentos.
Error frecuente
Responder al atasco de la puerta eliminándola. Cuando la revisión se convierte en cuello de botella, la tentación es saltarla «por calendario», justo donde el error es más barato de corregir. El cuello de botella se resuelve con delegación, asincronía, specs más cortas y comprobaciones automáticas, no renunciando al criterio. Igual de dañino es aprobar sin leer: una puerta que no se ejerce de verdad da una garantía falsa (el capítulo del método lo llama «teatro de especificación»).
Recursos
📊 Guía didáctica SDDRecursos · Scrum Manager
🏦 SDD en equipos ágilesSkill Arena · Scrum Manager
Referencias
- DORA. (2026). ROI of AI-assisted Software Development.
- Morris, Kief. (2026). «Humans and Agents in Software Engineering Loops».
- GitHub. (2026). Spec Kit (documentación del proyecto).
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.