Principio de proporcionalidad
El principio de proporcionalidad es la regla que gobierna la aplicación sensata del desarrollo guiado por especificaciones: ajustar la intensidad del proceso al tamaño del problema. Un defecto menor no necesita una spec de cuatro fases; una funcionalidad compleja que afecta a varias partes del sistema sí. Mal calibrado, SDD se convierte en una burocracia de especificación que ralentiza en lugar de acelerar.
SDD no es un formulario que se rellena de forma mecánica. Saber cuándo no aplicarlo forma parte de dominarlo: la sabiduría ágil es contextual, y no hay práctica que sea siempre buena o siempre mala. La mayoría de los fallos del método son fallos de calibración.
El caso del mazo para la nuez
Birgitta Böckeler documentó un caso revelador. Al pedir a una herramienta de SDD que arreglara un defecto pequeño, el documento de requisitos generado convirtió la tarea en cuatro historias de usuario con dieciséis criterios de aceptación. Lo describió como usar un mazo para romper una nuez. La sobreaplicación tiene además un coste oculto que no aparece en el reloj: cuando el equipo aprende que cualquier cambio dispara el flujo completo, empieza a evitar el flujo —y con él las puertas que sí protegían—. La rigidez excesiva no produce rigor, produce atajos.
La pregunta de calibración
La heurística práctica es una sola pregunta: ¿qué ocurre si el agente toma la decisión equivocada en este punto?
- Si la respuesta es «lo corrijo en dos minutos», ese punto no necesita especificarse.
- Si la respuesta es «pierdo horas o introduzco un defecto sutil», sí.
SDD aporta valor neto cuando el cambio es sustancial, hay ambigüedad, hay riesgo, interviene más de una persona o agente, o el código debe mantenerse en el tiempo. Cuando ninguna de esas condiciones se cumple, el vibe coding sigue siendo la herramienta adecuada: un guion de un solo uso, un prototipo para una demostración o un cambio de una línea no merecen el flujo completo.
El gradiente que muestra la evidencia
El informe de DORA de 2026 refuerza el principio desde otro ángulo: el retorno de la IA es alto en trabajo nuevo y sencillo, y mucho menor en código heredado y complejo. La intensidad del proceso no puede ser la misma en los dos extremos. Donde la IA acierta casi sola, especificar mucho es un coste sin retorno; donde la IA tropieza con la historia del sistema, la spec es lo que evita que el tropiezo llegue a producción. El principio, por tanto, no solo protege del exceso: también indica dónde invertir.
Error frecuente
Confundir exhaustividad con calidad. Más fases y más criterios no hacen mejor SDD; a menudo son el mazo para la nuez. Aplicar la misma intensidad al defecto trivial y a la funcionalidad compleja genera burocracia y, después, atajos. Y olvidar que el vibe coding sigue teniendo su sitio: para guiones, prototipos y cambios triviales, especificar es un coste sin retorno.
Recursos
📊 Guía didáctica SDDRecursos · Scrum Manager
🏦 SDD en equipos ágilesSkill Arena · Scrum Manager
Referencias
- Böckeler, Birgitta. (2025). «Understanding Spec-Driven Development». Thoughtworks / martinfowler.com.
- DORA. (2026). ROI of AI-assisted Software Development.
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.