Spec-Driven Development (SDD): Difference between revisions
Jump to navigation
Jump to search
| (7 intermediate revisions by the same user not shown) | |||
| Line 56: | Line 56: | ||
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. | 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. | ||
== Herramientas del ecosistema == | |||
El ecosistema de herramientas orientadas a SDD está creciendo rápidamente. Las principales opciones disponibles en 2025-2026: | |||
{| class="wikitable" | |||
|- | |||
! Herramienta !! Descripción !! Nivel SDD | |||
|- | |||
| '''GitHub Spec Kit''' || Toolkit open source con flujo estructurado: ''Constitution → Specify → Plan → Tasks → Implement''. Compatible con Copilot, Claude Code y otros agentes. || Spec-first / spec-anchored | |||
|- | |||
| '''Kiro (AWS)''' || IDE basado en VS Code con flujo integrado de ''Requirements → Design → Tasks''. || Spec-first / spec-anchored | |||
|- | |||
| '''Tessl Framework''' || Explora el nivel spec-as-source con mapeo 1:1 entre specs y archivos de código. || Spec-as-source | |||
|- | |||
| '''BMAD Method''' || Usa agentes virtuales (Analyst, Product Manager, Architect) para generar PRDs y specs de arquitectura. || Spec-first | |||
|} | |||
Ninguna de estas herramientas es imprescindible para aplicar SDD. El enfoque puede implementarse con cualquier agente de código si el equipo escribe la spec en un formato estructurado antes de delegar la implementación. | |||
== Relación con las historias de usuario == | == Relación con las historias de usuario == | ||
| Line 80: | Line 98: | ||
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. | 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. | ||
== Relación con TDD y BDD == | |||
SDD no compite con [[TDD|TDD]] ni con [[Behavior-Driven Development|BDD]]. | |||
Los tres enfoques son complementarios y pueden aplicarse juntos: | |||
{| class="wikitable" | |||
|- | |||
! Práctica !! Foco !! Pregunta que responde | |||
|- | |||
| '''SDD''' || Especificación. Define el qué y el por qué antes de implementar. || ¿Qué debe construirse exactamente y bajo qué restricciones? | |||
|- | |||
| '''TDD''' || Calidad a nivel de unidad. El test precede al código. || ¿Esta unidad de código hace lo que debe hacer? | |||
|- | |||
| '''BDD''' || Comportamiento del sistema. Escenarios en formato Given-When-Then. || ¿El sistema se comporta como esperan los usuarios y stakeholders? | |||
|} | |||
En la práctica un equipo puede usar: | |||
* SDD para definir una funcionalidad completa, | |||
* TDD para cada tarea de implementación individual | |||
* y BDD para las validaciones de extremo a extremo. | |||
SDD actúa como capa de contexto compartido que mantiene alineados a humanos y agentes durante todo el proceso. | |||
== SDD en equipos Scrum con IA == | == SDD en equipos Scrum con IA == | ||
| Line 123: | Line 164: | ||
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. | 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. | ||
== Limitaciones == | |||
SDD tiene limitaciones que conviene conocer antes de adoptarlo: | |||
* '''Escribir buenas specs es difícil.''' Requiere claridad de pensamiento, conocimiento del dominio y la disciplina de pensar antes de actuar. En proyectos donde los requisitos raramente están completamente formulados antes de la implementación, la spec puede convertirse en un artefacto aspiracional más que operativo. | |||
* '''El overhead puede ser desproporcionado en tareas pequeñas.''' Para funcionalidades simples o correcciones de bugs menores, el proceso de especificación puede generar más trabajo del que ahorra. SDD tiene más sentido cuando la complejidad de la funcionalidad justifica la inversión previa. | |||
* '''Las specs no eliminan el no-determinismo de los modelos.''' Una especificación detallada reduce la libertad no deseada del agente, pero no la elimina. Los modelos de lenguaje pueden ignorar instrucciones, excederse en su interpretación o generar outputs que cumplen la spec literalmente pero no en espíritu. La [[Revisión humana de outputs de IA|revisión humana]] sigue siendo necesaria. | |||
== Error frecuente == | == Error frecuente == | ||
| Line 152: | Line 201: | ||
<div class="bok-tags"> | <div class="bok-tags"> | ||
[[Vibe coding]] [[Vibe engineering]] [[Agente de IA]] [[Prompt engineering]] [[Historia de usuario]] [[Definición de hecho]] | |||
</div> | </div> | ||