Spec-Driven Development (SDD): Difference between revisions
Jump to navigation
Jump to search
| (3 intermediate revisions by the same user not shown) | |||
| Line 98: | 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 141: | 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 == | ||