Plantilla de sprint semanal

Plantilla de sprint semanal

Plantilla de la Metodología Designio · «Soberanía de la Intención» (origen: cap. 3, pp. 83-114) · designio.dev

Qué es y cuándo se usa

El sprint de Designio es un ciclo de una semana, de lunes a viernes, dividido en siete fases que cubren desde la captura de la intención hasta el despliegue en producción. La semana sale del ciclo humano (refinar, aprobar, validar), no de la capacidad de construir: «Se optimiza el tiempo humano hacia la supervisión estratégica, el arbitraje de diseño y el ajuste de precisión» (p. 84). Es un marco elástico: se pueden recortar los tiempos o incrementar las EIS por sprint a medida que el equipo madura.

Usa esta plantilla para planificar y registrar cada sprint. Las firmas marcadas con ✍ son humanas y obligatorias: sin ellas no se avanza de fase.

SPRINT [NUMERO] — [NOMBRE_DEL_PROYECTO]

Semana: [FECHA_LUNES] a [FECHA_VIERNES] Intent Director: [NOMBRE] · Business Owner: [NOMBRE] · Delivery Lead: [NOMBRE] · Arquitecto de Proyecto: [NOMBRE] (independiente del ID y del DL) · QA: [NOMBRE] EIS del sprint: [LISTA_DE_EIS_CANDIDATAS]

Fase 1 · Lunes (AM) — Ingesta Crítica y Protocolo de Interrogación (AI-Refiner)

• Quién: Business Owner + Intent Director (protagonismo total), con el agente AI Interrogador.
• Trabajo: el Agente Guardián, como punto único de entrada, recoge y normaliza las peticiones de los canales autorizados [CANALES], descarta duplicados y fuera de alcance, las clasifica por tipo (A evolutivos críticos · B correctivos · C optimizaciones/refactorizaciones · D consultas/documentación), les asigna índice de criticidad y detecta colisiones contra el backlog. El Intent Director activa al agente AI Interrogador, que confronta los requisitos contra toda ambigüedad y obliga al BO a contestar; las sesiones se dirigen con la plantilla maestra de las EIS. Margen de ambigüedad residual de referencia: ~5 %. El interrogador cruza además cada requisito con el mapa del proyecto: ¿qué partes del sistema se ven afectadas?
• Salidas: EIS atómicas con ambigüedad mínima; clasificación y criticidad de cada petición; colisiones resueltas o bloqueadas para decisión del ID.
• Registro: [ENLACE_A_EIS_GENERADAS]

Fase 2 · Lunes (PM) — Certificación del EIS y Alineación de Negocio

• Quién: Delivery Lead + Intent Director (a veces la misma persona); buena práctica: el BO también certifica o, como mínimo, es informado de las EIS y su relación con sus requisitos.
• Trabajo: certificar que las respuestas del BO al interrogador son satisfactorias y viables; priorizar y seleccionar las EIS a construir. Criterio de aprobación del BO: la EIS se justifica por ROI directo, ROI indirecto o ROI de riesgo/gobernanza; si no encaja en ninguno, replantear si merece construirse. Se definen los puntos de control de soberanía: hitos en los que la IA debe detenerse y pedir confirmación humana (modelo de datos, persistencia, gasto de infraestructura, protocolos de seguridad críticos, contratos con sistemas externos, reglas de negocio críticas).
• Regla: no se permite continuar a construcción sin una validación explícita y firmada de las EIS.
• Firma ✍: certificación de las EIS por [DELIVERY_LEAD] y [INTENT_DIRECTOR] — fecha [FECHA]. (Opcional recomendado: aceptación del BO.)

Fase 3 · Martes — Aceleración de Entorno y Pre-vuelo Técnico

• Quién: Delivery Lead, agentes de entorno; en re-arquitecturación, Shadow Architect + Arquitecto humano + Agente Guardián + Financial Guard.
• Trabajo: configurar el entorno (ramas de git, contenedores, dependencias, stubs y mocks de servicios externos) y validarlo construyendo una EIS de referencia. Diseño y construcción pueden solaparse: los constructores arrancan artefactos (esquemas de datos, contratos de API, interfaces) sobre EIS ya certificadas. Protocolo de re-arquitecturación (primer sprint, o cambios estructurales): el Shadow Architect genera varias propuestas de ADRs (cada una optimiza un criterio distinto, con justificación, consecuencias y trade-offs) más un informe de coste estimado de tokens; el Guardián valida cada propuesta contra los estándares (whitelist de librerías, versiones, branching, despliegue); por la tarde el Arquitecto humano revisa, ajusta y firma.
• Nota: esta fase no siempre aparece; sin cambios de infraestructura, la fase 4 se adelanta.
• Salidas: entorno estable; ADR firmado como referencia inmutable de la arquitectura del sprint.
• Firma ✍: ADR elegido firmado por [ARQUITECTO] — fecha [FECHA] (solo si se activó el protocolo).

Fase 4 · Martes (PM) y Miércoles — Construcción

• Quién: Agente Constructor a plena capacidad; Delivery Lead en paralelo (pruebas de intención); Agente Guardián (protocolo Allow/Run); Financial Guard.
• Trabajo: el constructor diseña los casos de prueba antes de escribir el código (TDD agéntico: lee la EIS, extrae los criterios de aceptación, los traduce en pruebas) y construye código, migraciones, esquemas OpenAPI/Swagger, configuración, documentación inline, README técnico y log de decisiones. Condición de entrega: cobertura de pruebas unitarias superior al 90 %. El Delivery Lead hace pruebas de intención sobre el staging en caliente e inyecta micro-ajustes (prompts cortos y dirigidos) sin detener el flujo. Cada comando pasa por la whitelist del Guardián (Allow/Run: por defecto se deniega); los secretos se inyectan en memoria volátil y el constructor nunca los ve en claro. Ante tests que fallan, bucle de diagnóstico; si se repite sin avance, el sistema mata el proceso y notifica al humano (probable ambigüedad en la EIS).
• Salidas: código que compila en sandbox, suite de tests >90 %, sin intentos pendientes de saltarse restricciones, visto bueno de intención del DL a los módulos principales.
• Registro: consumo de tokens frente a presupuesto [PRESUPUESTO]: [CONSUMO]

Fase 5 · Jueves — Auditoría de Salud Técnica y Despliegue en Pre con Certificación de Seguridad

• Quién: Security Sentinel (subagente del Guardián), Sandbox de Validación de Fidelidad, Agente Constructor (refactoring autónomo), Arquitecto de Proyecto (certificación humana).
• Trabajo: auditoría de caja blanca: OWASP Top 10 con Taint Analysis, code smells, secretos expuestos, cumplimiento de las convenciones del cliente (ADN técnico) y seguridad de la cadena de suministro (SBOM, licencias). El Sandbox de Fidelidad compara el comportamiento real con los criterios de aceptación de la EIS (contra la alucinación lógica), estresa con fuzzing y recalibra Railguards. El Guardián consolida el Health Score (5 vectores: seguridad, fidelidad, mantenibilidad, rendimiento, cobertura; ponderación del proyecto: [PESOS]): exigido ≥ 98/100; por debajo, el constructor refactoriza automáticamente hasta alcanzarlo. Métrica de intención: PA = (C / I) × 100; más de tres iteraciones de corrección activan auditoría de ambigüedad y la EIS vuelve al Intent Director. Tras la certificación: despliegue automatizado en PRE con IaC (espejo exacto de producción), estrategia Blue-Green o Canary, rollback automático <30 s, smoke tests. Recomendado: pasar el 100 % de las pruebas e2e de UAT de forma agéntica este día.
• Salidas: Health Score [VALOR]; código certificado y desplegado en PRE respondiendo a smoke tests.
• Firma ✍: certificación de salud firmada digitalmente por [ARQUITECTO] — fecha [FECHA]. No hay despliegue sin esa firma.

Fase 6 · Viernes (AM) — Validación de Valor (UAT) y Refactorización Flash

• Quién: QA + Business Owner sobre PRE; Agente Constructor (Flash Refactoring); Security Sentinel (re-validación); Agente Guardián (filtro de scope); Intent Director (autorización de evolutivos).
• Trabajo: validación de caja negra (aceptación por comportamiento, no por inspección). El BO y QA confirman cuatro cosas: hace lo que se pidió, resuelve el problema de negocio, se comporta como acordamos en la EIS y la experiencia es la esperada. Cada hallazgo se categoriza: Error de Intención (no cumple lo pactado → bucle de corrección rápida: prompt de corrección, parche en minutos, re-validación del Sentinel, despliegue ultra-dirigido en PRE, ciclos de 15-30 min hasta el «OK Final») o Evolutivo de Último Minuto (cumple lo pactado, pero se ve una mejora → solo entra en el sprint con visto bueno del Intent Director; si toca arquitectura, además firma del Arquitecto con nuevo ADR). El scope nuevo lo detecta el Guardián y se deriva al backlog del próximo lunes.
• Firma ✍: firma electrónica del BO con sello temporal: marca la EIS como «Satisfecha» y autoriza el merge y el despliegue a producción — fecha [FECHA]. Si el BO no está disponible, el DL puede firmar de forma provisional solo si: 100 % de e2e del jueves satisfactorias, sin Errores de Intención pendientes, Health Score sobre el umbral y BO notificado por canal trazable sin respuesta en plazo; los casos delicados se escalan al miembro del AIGB con autoridad de decisión última.

Fase 7 · Viernes (PM) — Release, Merge y Retrospectiva del Sprint

• Quién: Agente Guardián (ejecución), Delivery Lead (supervisión técnica; no firma nada nuevo: la firma del BO de la fase 6 es la única firma humana de cierre).
• Trabajo: merge a la rama principal con verificación de colisiones; tagging según el versionado del proyecto (habitualmente semver); despliegue a producción con Blue-Green o Canary y auto-rollback ante desviaciones. Cierre del Traceability Log (la «caja negra» del sprint, construida en paralelo a todas las fases): EIS firmada y modificaciones autorizadas, ADRs, código + tests + log de decisiones, reportes del Sentinel y Health Score, microajustes y hot-fixes, todas las aprobaciones humanas, resultados de UAT agéntico y humano, logs de despliegue con hashes criptográficos. Retrospectiva agéntica: el sistema analiza calidad de la ingesta del lunes (repreguntas), ajusta prompts del Constructor y del Shadow Architect, identifica cuellos de botella y hace el cierre financiero de tokens, aplicando los ajustes para el lunes siguiente.
• Salidas: versión [TAG] en producción; Traceability Log consolidado; ajustes de retrospectiva aplicados.

Resumen de firmas humanas del sprint ✍