SDD · Código Sin Siesta · 2026

Spec-Driven
Development

Escribir primero el contrato de comportamiento.
Menos ambigüedad, menos retrabajo, más calidad de equipo.

TDD BDD API-First OpenAPI Especificaciones

Alejandro de la Fuente

Technical Leader · NTT Data · GDNE

🌐 🐙 💼

El problema: código sin especificación explícita

Requisitos ambiguos

Historias vagas generan interpretaciones distintas entre producto, backend y frontend.

Retrabajo estructural

Implementamos rápido, validamos tarde y acabamos rehaciendo diseño y código crítico.

Tests desconectados

Las pruebas validan detalles técnicos pero no garantizan el comportamiento de negocio.

Diagnóstico: sin contrato previo, cada iteración añade incertidumbre.

Spec-Driven Development: definición operativa

SDD no reemplaza el desarrollo: ordena el flujo para que la especificación sea la fuente de verdad.

1. Capturar intención en una spec clara
2. Validar escenarios y criterios con el equipo
3. Implementar siguiendo la spec como contrato
4. Verificar que tests y comportamiento cumplen la spec

Beneficios principales

Alineación técnica y funcional

Producto y desarrollo discuten sobre escenarios concretos, no sobre interpretaciones.

Menos deuda accidental

El diseño técnico nace con restricciones explícitas y evita reescrituras tempranas.

Tests con propósito

Las pruebas cubren criterios de aceptación reales, no solo detalles internos.

Onboarding más rápido

Nuevos miembros entienden el sistema leyendo specs vivas y ejecutables.

Cuándo usar SDD

Dominios con reglas complejas (pagos, inventario, compliance).
Equipos con múltiples squads o handoffs frecuentes.
Features críticas donde un fallo tiene coste alto.
Productos con roadmap largo que requieren trazabilidad de decisiones.

Cuándo NO usar SDD

Prototipos de un día donde buscamos feedback visual inmediato.
Scripts internos de bajo riesgo y vida útil corta.
Exploraciones técnicas sin requisitos estabilizados.
Cuando la spec se usa como burocracia y no como herramienta viva.

SDD es una inversión: no aporta igual en todos los contextos.

Relación con TDD y BDD

SDD

Contrato de producto + diseño técnico como punto de partida.

TDD

Define diseño de código a partir de tests unitarios primero.

BDD

Expresa comportamiento en lenguaje ubicuo con escenarios.

No compiten: SDD enmarca y TDD/BDD pueden operar dentro de ese marco.

Ejemplo práctico: alta de usuario

Spec

Dado un email válido y no registrado, se crea usuario.
Si el email existe, devuelve conflicto 409 con código semántico.
El evento `user.created` se publica exactamente una vez.

Implementación + tests

Servicio valida reglas con Zod.
Test de contrato API para responses.
Test de integración para persistencia + evento.

Takeaways

De la intuición al contrato

01 La especificación ejecutable es el contrato: todos hablan el mismo idioma.

02 SDD reduce ambigüedad antes de escribir una sola línea de código.

03 TDD, BDD y API-First son instancias del mismo principio: spec primero.

04 El retrabajo cae cuando el equipo valida comportamiento, no código.

05 Empieza pequeño: una feature crítica, dos sprints, mide el impacto.

Recursos

🔗 Presentación publicada 🔗 Repositorio GitHub 🔗 tellmealex.dev

1 / 9