View source for Spec-Driven Development (SDD)

{{Meta-bok|min=5}}
''Spec-Driven Development'' (SDD), o desarrollo dirigido por especificación, es una forma de organizar el desarrollo asistido por IA en la que una spec precede y guía la implementación. En lugar de pedir código directamente a un agente de IA, el equipo define primero qué debe construirse, bajo qué restricciones y con qué criterios de verificación.

Spec-Driven Development surge como respuesta a una limitación cada vez más visible del desarrollo asistido por IA: la facilidad para generar código no garantiza que ese código sea correcto, mantenible, seguro o coherente con la arquitectura del producto.

En enfoques como el [[Vibe coding|vibe coding]], el profesional describe lo que quiere en lenguaje natural, la IA genera una solución y el equipo prueba, corrige y vuelve a pedir cambios hasta que algo parece funcionar. Este enfoque puede ser muy útil para prototipos, exploración rápida o herramientas internas de bajo riesgo. El problema aparece cuando se usa el mismo modo de trabajo para código de producción.

SDD cambia el orden del trabajo: primero se especifica, después se implementa. La spec se convierte en el contrato operativo entre el equipo humano y el agente de IA.

== Qué problema resuelve ==

La IA puede generar código con mucha rapidez, pero esa rapidez desplaza el cuello de botella hacia la revisión. El equipo ya no dedica tanto esfuerzo a escribir código desde cero, sino a entender, verificar, corregir e integrar código producido por otro sistema.

SDD ayuda a reducir esa carga porque proporciona un criterio explícito contra el que revisar el resultado. El equipo no revisa el código preguntándose “qué habrá hecho la IA”, sino comparando la implementación con una especificación previamente acordada.

En la práctica, SDD busca reducir tres problemas habituales del desarrollo asistido por IA:

* '''Ambigüedad''': cuando el prompt es vago, el agente toma decisiones implícitas que quizá no coincidan con la intención del equipo.
* '''Carga de revisión''': cuanto mayor es el volumen de código generado, más difícil resulta detectar errores sutiles.
* '''Deuda técnica''': si la IA genera soluciones plausibles pero inconsistentes con la arquitectura, el coste aparece después en mantenimiento, seguridad o evolución del producto.

== Cómo funciona ==

SDD no es una herramienta concreta ni un plugin. Es una metodología de trabajo que puede implementarse con distintas herramientas, agentes o flujos de desarrollo.

Un flujo habitual de SDD incluye cuatro momentos:

# '''Requisitos''': se define qué problema se quiere resolver, para quién, con qué comportamiento esperado y qué queda fuera del alcance.
# '''Diseño''': se describen decisiones técnicas relevantes, restricciones de arquitectura, integración con sistemas existentes, datos, APIs y criterios no funcionales.
# '''Tareas''': se divide la implementación en pasos concretos, revisables y ejecutables por un agente o por una persona.
# '''Implementación''': el agente de IA genera el código siguiendo la spec, y el equipo revisa, prueba e integra el resultado.

La clave no está en escribir documentación extensa, sino en escribir documentación operativa: lo suficiente para que humanos y agentes compartan una misma interpretación del trabajo.

== Niveles de adopción ==

No todos los equipos aplican SDD con la misma intensidad. Una forma útil de entenderlo es distinguir tres niveles:

{| class="wikitable"
! Nivel
! Cómo funciona
! Cuándo tiene sentido
|-
| '''Spec-first'''
| La spec se escribe antes de codificar, se usa para la tarea actual y puede descartarse al terminar.
| Es el punto de entrada más sencillo. Útil para equipos que empiezan a ordenar su trabajo con IA.
|-
| '''Spec-anchored'''
| La spec se conserva después de la implementación y se actualiza cuando evoluciona la funcionalidad.
| Útil cuando la funcionalidad será mantenida, extendida o revisada más adelante.
|-
| '''Spec-as-source'''
| La spec se trata como artefacto principal. El código se genera o regenera a partir de ella.
| Es el nivel más avanzado y todavía experimental en muchos contextos. Requiere mucha disciplina y herramientas maduras.
|}

La mayoría de equipos empiezan por un enfoque ''spec-first''. Pretender saltar directamente a ''spec-as-source'' puede generar más rigidez que valor si el equipo no tiene prácticas sólidas de validación, testing y revisión.

== Relación con las historias de usuario ==

SDD no sustituye a las [[Historia de usuario|historias de usuario]]. Las complementa.

La historia de usuario ayuda a expresar intención, usuario, necesidad y valor. Es un artefacto de conversación entre personas. La spec traduce esa intención a un formato más preciso, verificable y ejecutable por un agente de IA.

Una forma simple de distinguirlas:

{| class="wikitable"
! Artefacto
! Función principal
! Pregunta que responde
|-
| '''Historia de usuario'''
| Comunicar valor y necesidad desde la perspectiva del usuario.
| ¿Para quién construimos esto y por qué importa?
|-
| '''Spec'''
| Definir comportamiento, restricciones y criterios de verificación.
| ¿Qué debe producirse exactamente y cómo sabremos que está bien?
|}

En equipos con IA, una historia puede seguir siendo el punto de partida del backlog, pero las tareas que vaya a ejecutar un agente necesitan una spec suficientemente clara.

== SDD en equipos Scrum con IA ==

En Scrum con IA, las specs funcionan como puente entre los artefactos clásicos y el trabajo ejecutado por agentes.

En el [[Product backlog|product backlog]], ayudan a refinar ítems que podrían ser implementados total o parcialmente por IA. En la [[Planificación del sprint|planificación del sprint]], permiten decidir qué parte del trabajo requiere juicio humano y qué parte puede delegarse a un agente. En el [[Sprint backlog|sprint backlog]], actúan como contrato de ejecución.

También se conectan con una [[Definición de hecho|Definition of Done]] reforzada. El código generado por IA no debería considerarse terminado solo porque compila o porque el agente afirma que funciona. Debe pasar revisiones técnicas, pruebas, controles de seguridad y revisión humana.

<div class="bok-aviso">
En equipos con IA, la spec no elimina la responsabilidad humana. El agente puede generar la implementación, pero el equipo sigue siendo responsable de validar que el incremento cumple los criterios de calidad, seguridad y valor esperados.
</div>

== SDD y agilidad ==

Una objeción habitual es que SDD “suena a cascada”: requisitos, diseño, tareas e implementación antes de tener software funcionando.

La objeción merece tomarse en serio. Si SDD se convierte en documentación pesada, aprobación burocrática y bloqueo del aprendizaje, entra en conflicto con la agilidad. Pero SDD no tiene por qué aplicarse así.

La diferencia está en el uso de la spec. En un enfoque ágil, la spec no es un contrato cerrado contra el cambio, sino un artefacto vivo para reducir ambigüedad antes de delegar trabajo a una IA. Puede iterarse, dividirse, contrastarse con usuarios y revisarse conforme aparece nueva información.

El criterio práctico es sencillo: si la spec ayuda a entregar software funcionando con menos errores, mejor aprendizaje y menor deuda técnica, refuerza la agilidad. Si se convierte en un requisito documental que retrasa la validación, la debilita.

== Cuándo usar SDD ==

SDD resulta especialmente útil cuando:

* el código generado por IA va a llegar a producción;
* la funcionalidad afecta a datos, seguridad, permisos, facturación o experiencia crítica de usuario;
* existen restricciones de arquitectura que el agente debe respetar;
* el equipo trabaja sobre un producto existente, especialmente en contextos [[Brownfield|brownfield]];
* varias personas o agentes deben coordinarse sobre una misma funcionalidad;
* el coste de revisar código ambiguo es mayor que el coste de escribir una buena spec.

Puede ser excesivo cuando el objetivo es explorar una idea muy temprana, crear un prototipo desechable o validar una hipótesis en un carril rápido de aprendizaje. En esos casos, puede tener más sentido empezar con [[Vibe coding|vibe coding]] y pasar a SDD cuando la idea merezca convertirse en producto robusto.

== SDD y la IA ==

SDD cobra especial relevancia con la IA generativa porque los agentes de código son muy sensibles a la calidad del contexto. Cuando la instrucción es vaga, el agente completa huecos con patrones probables. A veces acierta. Otras veces introduce decisiones invisibles que el equipo descubre tarde.

Una buena spec reduce esa libertad no deseada. Define comportamiento esperado, límites, dependencias, criterios de aceptación, restricciones técnicas y casos borde. No convierte a la IA en infalible, pero mejora la calidad de la delegación.

En este sentido, SDD transforma el papel del desarrollador. El valor no desaparece: cambia de lugar. Gana peso la capacidad de escribir specs, diseñar arquitectura, revisar críticamente outputs de IA y decidir qué debe automatizarse y qué debe permanecer bajo control humano.

== Error frecuente ==

<div class="bok-aviso">
'''Confundir SDD con documentación en cascada.''' SDD no consiste en escribir documentos extensos para congelar el plan antes de construir. Consiste en crear especificaciones operativas, revisables y suficientemente precisas para que un agente de IA pueda ejecutar trabajo sin inventar decisiones críticas. Si la spec impide aprender, iterar o responder al cambio, se está aplicando mal.
</div>

== Recursos ==
<div class="bok-recurso">
📊 [https://scrummanager.com/website/c/info/resource.php?id=374 '''Guía didáctica SDD''']<span class="detalle">Recursos · Scrum Manager</span>
</div>
<div class="bok-recurso">
🏦 [https://scrummanager.com/skillarena/sdd-en-equipos-agiles '''SDD en equipos ágiles''']<span class="detalle">Skill Arena · Scrum Manager</span>
</div>

== Referencias ==

* Beck, Kent et al. (2001). “Manifesto for Agile Software Development”, AgileManifesto.org.
* Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR.
* Böckeler, Birgitta. (2025). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, MartinFowler.com.
* GitClear. (2025). “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”, GitClear.
* GitHub. (2025). “Spec-driven development with AI: Get started with a new open source toolkit”, GitHub Blog.
* Scrum Manager. (2026). ''SDD – Spec Driven Development en equipos ágiles''. Scrum Manager.
* Scrum Manager. (2026). ''Scrum en equipos con IA''. Scrum Manager.
* Wessling, Jens. (2025). “We Asked 100+ AI Models to Write Code. Here’s How Many Failed Security Tests”, Veracode.

== Véase también ==

<div class="bok-tags">
[[Vibe coding]] [[Vibe engineering]] [[Agente de IA]] [[Prompt engineering]] [[Historia de usuario]] [[Definición de hecho]]
</div>

<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">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 [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>

[[Category:Glosario de términos]]
[[Category:Prácticas técnicas]]