Fases del desarrollo SDD

Desarrollo greenfield: de cero a uno

La fase greenfield (0-to-1) corresponde al inicio de un proyecto desde cero. No hay código previo, no hay restricciones de arquitectura heredadas y el equipo parte de una hoja en blanco. Es la fase donde SDD aporta mayor retorno con menor esfuerzo, porque las decisiones tomadas en este punto determinan la trayectoria de todo el proyecto.

En un proyecto greenfield sin SDD, el patrón habitual es que alguien del equipo empieza a escribir código basándose en una idea general. Se elige un framework porque "es lo que conocemos", se define una estructura de carpetas que parece razonable y se comienza a construir. Las decisiones fundamentales (modelo de datos, patrones de API, estrategia de testing, gestión de estados) se toman de forma reactiva a medida que surgen las necesidades.

Con SDD, la fase greenfield sigue una secuencia deliberada:

• 1. Constitución: antes de escribir una línea de código, el equipo define las reglas de gobernanza del proyecto. Estas reglas establecen principios como "priorizar bibliotecas estándar sobre abstracciones propias" o "cada feature debe tener tests de integración antes del merge". La constitución actúa como una guía de decisiones que el agente IA respetará durante la implementación.

• 2. Especificación inicial: se describe la primera funcionalidad a construir en términos de user stories y criterios de aceptación. El enfoque es capturar la intención del producto: quién lo usará, qué problema resuelve y cómo se medirá el éxito.

• 3. Plan técnico: con la spec validada, se eligen el stack tecnológico, la arquitectura y los patrones de implementación. El plan respeta los principios de la constitución y se genera a partir de la especificación.

• 4. Implementación por tareas: el plan se descompone en tareas accionables que el agente IA ejecuta secuencialmente, validando cada una contra los criterios de aceptación.

flowchart TB
    subgraph Greenfield["Fase greenfield (0-to-1)"]
        direction TB
        G1["Constitución<br>Principios inmutables"] --> G2["Spec inicial<br>Primera funcionalidad"]
        G2 --> G3["Plan técnico<br>Stack y arquitectura"]
        G3 --> G4["Tareas<br>Desglose ejecutable"]
        G4 --> G5["Implementación<br>Proyecto funcional"]
    end

En la fase greenfield, SDD convierte decisiones que normalmente son implícitas y reactivas en elecciones explícitas y deliberadas, reduciendo la deuda técnica desde el primer día.

La trampa de la parálisis por análisis

Un riesgo de la fase greenfield es caer en la parálisis por análisis: dedicar tanto tiempo a definir especificaciones que el proyecto nunca arranca. SDD aborda este riesgo con un principio claro: la especificación debe ser lo suficientemente precisa para generar una implementación correcta, pero no más. No se busca documentar cada detalle del sistema completo, sino definir con claridad la primera iteración funcional.

La primera especificación de un proyecto greenfield suele cubrir una porción limitada del producto: el flujo más básico, el "happy path" de la funcionalidad principal. Una vez implementada y validada, se añaden iteraciones sucesivas que amplían la cobertura. Este enfoque incremental mantiene la velocidad del vibe coding (resultados tangibles rápido) con la trazabilidad del SDD (cada decisión está documentada).

Exploración creativa

La fase de exploración creativa aprovecha una capacidad única de SDD: la posibilidad de generar múltiples implementaciones a partir de la misma especificación para comparar alternativas antes de comprometerse con una de ellas.

En el desarrollo tradicional, explorar alternativas de implementación es costoso. Si el equipo quiere evaluar si un componente debería usar WebSockets o Server-Sent Events, o si el frontend debería construirse con React o con un framework server-rendered, la única forma fiable de comparar es construir ambas versiones. El coste de duplicar la implementación manual hace que, en la práctica, estas decisiones se tomen por experiencia previa o preferencia personal.

Con SDD, la especificación define el comportamiento esperado de forma independiente de la tecnología. El equipo puede pedir al agente IA que genere el plan técnico con distintos stacks y producir implementaciones alternativas sin reescribir los requisitos.

Escenarios de exploración

La exploración creativa es especialmente útil en tres contextos:

Evaluación de tecnologías: cuando el equipo debe elegir entre tecnologías para un componente crítico, puede generar implementaciones paralelas y comparar rendimiento, mantenibilidad y complejidad con datos reales en lugar de opiniones.

Especificación: "API de procesamiento de imágenes con redimensionado,
compresión y conversión de formatos"

Plan A: Python + FastAPI + Pillow
Plan B: Go + net/http + imaging
Plan C: Rust + Actix + image

Cada plan genera una implementación funcional que se puede evaluar con benchmarks, métricas de uso de memoria y facilidad de extensión.

Diseño de interfaces: partiendo de la misma especificación funcional, el agente puede generar interfaces con distintos patrones de interacción. Una versión con formularios paso a paso, otra con un flujo de wizard, otra con una interfaz conversacional. El equipo puede probar cada variante con usuarios reales antes de elegir.

Arquitectura de sistemas: para funcionalidades que podrían implementarse como parte del monolito existente o como un servicio independiente, la exploración creativa permite construir ambas versiones y evaluar las implicaciones de cada opción en términos de latencia, complejidad operativa y acoplamiento.

La exploración creativa transforma decisiones basadas en opiniones ("yo prefiero React") en decisiones basadas en evidencia ("la versión con server-rendering carga un 40% más rápido para nuestro caso de uso").

El coste de explorar

La exploración creativa no es gratuita. Generar múltiples implementaciones consume tiempo de agente IA y requiere infraestructura para ejecutar y comparar las alternativas. Sin embargo, el coste es significativamente menor que el de tomar una decisión incorrecta y descubrirla meses después.

El modelo mental adecuado es considerar la exploración como una inversión en información. El coste de generar dos implementaciones alternativas y evaluarlas durante un día es mucho menor que el de reescribir un componente completo tras descubrir que la tecnología elegida no escala para los requisitos de producción.

No todas las decisiones justifican exploración. La clave es aplicarla a las decisiones de alto impacto y baja reversibilidad: elección de base de datos, arquitectura de comunicación entre servicios, framework de frontend. Para decisiones menores (librería de validación, formato de logs), el juicio del equipo es suficiente.

Iteración brownfield

La fase brownfield es la que la mayoría de equipos de desarrollo experimentan en su día a día: evolucionar, mantener y extender un sistema que ya existe. Los proyectos greenfield son la excepción, la norma es añadir funcionalidades a codebases que llevan meses o años en producción, con decisiones heredadas, deuda técnica acumulada y restricciones operativas.

SDD resulta particularmente valioso en escenarios brownfield porque proporciona un mecanismo para documentar el contexto que el código existente no puede comunicar por sí solo. Cuando un desarrollador nuevo se incorpora a un proyecto de 200.000 líneas de código, el código le dice qué hace el sistema, pero no por qué se diseñó así ni qué alternativas se descartaron. Las especificaciones SDD llenan ese vacío.

Añadir funcionalidades a sistemas existentes

Cuando se necesita añadir una nueva feature a un sistema en producción, SDD adapta su flujo a las restricciones del proyecto existente:

• Especificación contextualizada: la spec de la nueva funcionalidad incluye explícitamente cómo debe interactuar con los componentes existentes. No basta con definir qué hace la funcionalidad, hay que definir cómo se integra con lo que ya existe.

• Plan con restricciones: el plan técnico no parte de una hoja en blanco. Debe respetar la arquitectura existente, el stack actual y las convenciones del equipo. La constitución del proyecto codifica estas restricciones para que el agente IA las respete automáticamente.

• Tareas incrementales: las tareas se diseñan para ser compatibles hacia atrás. Cada tarea implementada debe poder desplegarse sin romper funcionalidades existentes.

flowchart LR
    subgraph Brownfield["Iteración brownfield"]
        direction LR
        B1["Sistema<br>existente"] --> B2["Spec de nueva<br>feature"]
        B2 --> B3["Plan con<br>restricciones"]
        B3 --> B4["Tareas<br>incrementales"]
        B4 --> B5["Sistema<br>actualizado"]
    end

Modernización de sistemas legacy

Otro escenario brownfield habitual es la modernización de sistemas legacy. SDD ofrece un enfoque estructurado para este tipo de proyectos:

• Captura de la lógica de negocio: el primer paso es crear especificaciones que describan el comportamiento actual del sistema. Esto es crítico porque en muchos sistemas legacy, la lógica de negocio está codificada en el código fuente sin documentación alguna. El agente IA puede ayudar a analizar el código existente y extraer una especificación que documente su comportamiento.

• Definición del estado objetivo: una vez capturado el comportamiento actual, se define la especificación del sistema modernizado. Esta spec describe el mismo comportamiento de negocio con una arquitectura actualizada.

• Migración incremental: las tareas se organizan para migrar el sistema componente a componente, validando en cada paso que el comportamiento se mantiene según la especificación.

En escenarios brownfield, SDD actúa como una capa de documentación ejecutable que preserva el conocimiento del sistema existente mientras guía su evolución.

Elegir la fase adecuada

Las tres fases no son mutuamente excluyentes. Un mismo proyecto puede atravesar las tres a lo largo de su ciclo de vida, y diferentes partes del sistema pueden estar en fases distintas simultáneamente.

| Fase | Contexto típico | Profundidad de la spec | Nivel de restricciones | |---|---|---|---| | Greenfield | Proyecto nuevo, sin código previo | Media: centrada en la primera iteración | Baja: libertad para elegir stack y arquitectura | | Exploración | Decisiones técnicas de alto impacto | Alta: debe ser lo bastante precisa para generar alternativas comparables | Variable: depende del alcance de la exploración | | Brownfield | Sistema en producción que evoluciona | Alta: debe reflejar restricciones existentes | Alta: respeta arquitectura, stack y convenciones |

La profundidad de la especificación se ajusta al contexto. En un proyecto greenfield, una spec concisa que defina el happy path principal es suficiente para arrancar. En un escenario brownfield, la spec necesita detallar cómo la nueva funcionalidad interactúa con cada componente existente que se vea afectado.

La decisión de cuánta especificación es "suficiente" depende del coste de equivocarse. Si reescribir un componente cuesta una hora de trabajo del agente IA, una spec breve basta. Si un error de requisitos implica un rollback en producción que afecta a miles de usuarios, la inversión en una especificación detallada está justificada.

Transiciones entre fases

Los proyectos transicionan de forma natural entre fases. Un proyecto que comienza como greenfield se convierte en brownfield una vez que tiene usuarios en producción. Dentro de un proyecto brownfield, una funcionalidad completamente nueva puede tratarse como una mini-fase greenfield si es lo suficientemente independiente del sistema existente.

La exploración creativa puede ocurrir en cualquier momento: al inicio de un proyecto greenfield para elegir el stack, durante la fase brownfield para evaluar alternativas de migración, o incluso como parte de una feature brownfield cuando el equipo duda entre dos enfoques de implementación.

La clave es reconocer que SDD se adapta al contexto, no al revés. No existe un único flujo rígido que todos los proyectos deban seguir. Los principios (lingua franca, refinamiento continuo, feedback bidireccional, exploración creativa) se aplican siempre. La intensidad y profundidad de la especificación varían según la fase en la que se encuentre el proyecto.