M6Tu método PIE integrado con SDD

Semana 4 de 4 Carga 4 horas Entregable Tu SDD Playbook personal

6.1 Dónde estás al llegar aquí

Si has completado los módulos anteriores, tienes:

El modelo mental de SDD interiorizado (M1)
La capacidad de escribir specs completas y precisas (M2)
Un entorno configurado como sistema (M3)
El ciclo completo ejecutado al menos una vez con resultado real (M4)
La capacidad de gestionar sistemas complejos con árboles de specs (M5)

El M6 no añade técnica nueva. Añade integración e identidad de método. El objetivo es que SDD no sea "una cosa más que haces" sino la forma en que trabajas.

6.2 PIE y SDD: la integración natural

PIE es el contenedor. SDD es la mecánica de precisión dentro de cada fase.

Tu método PIE (Protocolo de Instrucción Estructurada) tiene tres fases: Planificar → Implementar → Evaluar

SDD encaja en ese marco de forma directa:

PLANIFICAR
  └── Convertir requisito en spec (M1, M2)
      Revisar spec con checklist (M4)
      Actualizar árbol de specs del proyecto (M5)

IMPLEMENTAR
  └── Entregar spec a la IA con protocolo de confirmación (M4)
      Supervisar que la IA sigue la spec (M4)
      Orquestar pasos si la feature es compleja (M4, M5)

EVALUAR
  └── Validar contra criterios de la spec (M4)
      Documentar resultado en historial de la spec (M5)
      Actualizar estado en árbol de specs (M5)
      Identificar specs nuevas que emergen del trabajo (M4, M5)

PIE es el contenedor. SDD es la mecánica de precisión dentro de cada fase.

6.3 Tu flujo de trabajo diario con SDD

Esta es la rutina que deberías tener después del curso:

Al empezar una sesión de trabajo

1. Abrir el árbol de specs del proyecto (ai/specs/)
2. Revisar el estado: ¿qué está en progreso? ¿qué está pendiente?
3. Elegir la task spec de la sesión
4. Verificar que el CLAUDE.md está actualizado
5. Entregar spec a la IA con el protocolo de confirmación

Durante la implementación

6. Supervisar que la IA sigue la spec
7. Reconducir si hay desviaciones (nunca editar código manualmente para compensar)
8. Tomar nota de lo que emerge fuera de scope

Al cerrar la sesión

 9. Validar contra criterios de la spec
10. Actualizar estado de la spec (en progreso → completada, o anotar bloqueante)
11. Crear specs nuevas para lo que emergió fuera de scope
12. Ejecutar /worklog o /handoff si usas esos comandos

Este flujo parece pesado al principio. Con práctica, las fases 1-5 toman menos de 5 minutos. El tiempo ahorrado en la implementación y validación lo recuperas con creces.

6.4 SDD en contextos corporativos restringidos

Los contextos corporativos suelen tener restricciones que condicionan cómo aplicas SDD:

Restricciones conocidas

Herramienta aprobada: GitHub Copilot (Claude) en VSCode
No puedes instalar Claude Code CLI directamente en entorno corporativo
El portapapeles tiene restricciones → usas Gmail como puente

Cómo adaptar SDD a esas restricciones

Las specs viven en Confluence o en el repo
Si el proyecto vive en un repo controlado, la carpeta ai/ va en el repo. Si no tienes control del repo, usa Confluence o Notion como carpeta de specs y enlaza desde el CLAUDE.md.

El CLAUDE.md va en .github/copilot-instructions.md
GitHub Copilot lo consume automáticamente desde ahí. Si ya lo tienes en algún proyecto, generaliza ese patrón a todos los demás.

Los slash commands van en .github/copilot-instructions.md
Ya tienes /worklog, /db-change, /handoff, /auditoria-codigo. Añade /spec y /validate al conjunto.

El puente Gmail
Para features complejas donde necesitas pasar contexto entre Claude.ai y Copilot:

Escribes la spec en Claude.ai (aquí, con ayuda si la necesitas)
Te la envías por Gmail a tu correo corporativo
La pegas en Copilot como contexto de la sesión

Este flujo no es ideal pero es funcional con las restricciones actuales.

Oportunidad: SDD como extensión de PIE en presentaciones internas

Ya tienes tu método validado en proyectos reales. SDD es la capa técnica de PIE que faltaba. La próxima vez que presentes avances, puedes mostrar:

Árbol de specs de un proyecto cliente real
Ciclo completo documentado de una feature
Métricas de sesiones: specs creadas vs. implementadas vs. validadas

Eso transforma PIE de "método de trabajo con IA" a "sistema de desarrollo verificable". Mucho más sólido para cualquier audiencia técnica o directiva.

6.5 SDD en proyectos personales

Para tus proyectos propios (gowy.es, Recepcionista Digital, CFO Personal, etc.) tienes libertad total. Aquí SDD puede ir al máximo.

Recomendación de priorización

No apliques SDD a todos tus proyectos a la vez. Eso es dispersión. Elige uno como proyecto piloto para interiorizar el método completamente. Cuando funcione ahí sin fricción, lo extiendes a los demás.

Criterio de elección del proyecto piloto:

Tiene features pendientes concretas (no solo ideas)
Lo abres al menos 2-3 veces por semana
Tiene potencial de llegar a producción en 1-2 meses

Con esos criterios, gowy.es o Recepcionista Digital son candidatos más sólidos que GuardianAI o Crónicas de la Simbiosis en este momento.

6.6 Tu SDD Playbook personal

El entregable final del curso es tu Playbook: un documento vivo que recoge tu versión personal del método, adaptada a tu contexto real.

No es un resumen del curso. Es tu protocolo operativo.

Estructura del Playbook

# SDD PLAYBOOK — [Tu nombre]
Versión: 1.0 | Fecha: [fecha]

## Mi definición de SDD
(En tus palabras. No la del curso. Cómo lo entiendes tú.)

## Mi flujo de trabajo diario
(El ritual de inicio, el de implementación, el de cierre. Adaptado a tu contexto.)

## Mi plantilla de spec
(La versión definitiva de tu template, con tus ajustes y preferencias.)

## Mis reglas personales
(Las 5-7 reglas que has aprendido que funcionan para ti.
Por ejemplo: "Nunca implementar sin spec. Si tarda menos de 5 minutos escribirla, mejor aún.")

## Mis herramientas y configuración
(CLAUDE.md base, slash commands activos, MCPs configurados, estructura de carpetas estándar.)

## Cómo integro SDD con PIE
(La descripción de cómo encajan los dos métodos en tu flujo real.)

## Contextos de aplicación
(Contexto corporativo: cómo. Proyectos personales: cómo. Proyectos nuevos: cómo.)

## Lo que NO hago (anti-patterns detectados)
(Las cosas que hacías antes de SDD y que ahora sabes que no funcionan.)

## Historial de versiones
| Versión | Fecha | Cambio |
|---|---|---|
| 1.0 | [fecha] | Versión inicial post-curso |

6.7 El Playbook es vivo

El Playbook no se escribe una vez y se archiva. Es un documento que evoluciona con tu práctica.

Cuándo actualizar el Playbook

Cuando descubres una forma mejor de hacer algo
Cuando un anti-pattern nuevo aparece (y lo reconoces a tiempo)
Cuando el contexto cambia (nueva herramienta, nuevo proyecto, nuevo equipo)
Cada 2-3 meses, revisión general: ¿sigo aplicando lo que dice?

El síntoma de que el Playbook está desactualizado

Si lo abres y hay cosas que ya no haces así, actualízalo. Un Playbook que no refleja la práctica real no sirve de nada.

6.8 Métricas de adopción (opcional pero útil)

Si quieres medir si SDD te está aportando valor real, trackea esto:

Semana X:
- Specs escritas: N
- Features implementadas desde spec: N
- Desviaciones detectadas durante implementación: N
- Features sin spec (vibe coding): N (objetivo: 0)
- Tiempo medio spec → implementación → validación: Xh

No hace falta un sistema complejo. Un markdown con esta tabla actualizado semanalmente es suficiente para ver si el método se está consolidando o degradando.

Ejercicio M6

Escribe tu SDD Playbook completo usando la estructura del 6.6
Incluye al menos 5 reglas personales basadas en lo que aprendiste en el curso
Define cómo integras SDD en tu contexto corporativo y en tus proyectos personales por separado
Lista los 3-5 anti-patterns que reconoces en tu forma de trabajar anterior

Este es el entregable más personal del curso. No hay respuesta correcta. Hay una respuesta tuya, honesta, que refleja lo que has interiorizado.

Entregable M6

M6-SDD-Playbook-v1.md — Tu Playbook personal completo.

Este documento va a la raíz de tu carpeta de Drive del curso Y en algún lugar accesible desde tus proyectos (Notion, Drive raíz, etc.) porque lo vas a usar, no a archivar.

Resumen del Módulo 6

SDD encaja naturalmente en PIE: Planificar=Spec, Implementar=IA desde spec, Evaluar=Validación.
El flujo diario tiene tres momentos: inicio de sesión, durante implementación, cierre de sesión.
En contextos corporativos con restricciones de herramientas, SDD se adapta sin perder el núcleo del método.
Para proyectos personales: elige un proyecto piloto, no apliques a todos a la vez.
El Playbook es el artefacto final: tu protocolo operativo personal, vivo y actualizable.
Trackear métricas simples (specs escritas, desviaciones detectadas) te dice si el método se consolida.

Cierre del curso

Has completado el programa completo de SDD de 0 a 100.

Lo que tienes ahora:

Método interiorizado y documentado
Entorno configurado como sistema
Templates reutilizables
Al menos una feature construida end-to-end con SDD
Árbol de specs de un proyecto completo
Tu Playbook personal v1.0

Lo que viene después:

Práctica. El método se consolida con uso, no con lectura.
Actualiza el Playbook cuando descubras algo nuevo.
Si encuentras un punto del método que no funciona para ti, cámbialo. Es tuyo.

El objetivo nunca fue seguir SDD por seguirlo. El objetivo es que la IA construya exactamente lo que tú tienes en la cabeza, sin improvisar, sin iterar a ciegas, sin perder tiempo.

Si eso está pasando, el método funciona.