Backlog
Se mantiene como lista explícita y priorizada de trabajo, pero se conecta a Project Truth, riesgos, discovery y decisiones de arquitectura.
Metodología · De la necesidad a la evidencia
Una metodología de ingeniería para trabajar con IA sin perder criterio, control ni trazabilidad.
DCP Flow combina prácticas adaptadas de Scrum, Solution Discovery, arquitectura, agentes de IA, Quality Gates, Evidence y Human Gates. No copia Scrum: reutiliza sus componentes útiles dentro de un sistema más amplio orientado a decisiones verificables.
Scrum → DCP Flow
Qué tomamos de Scrum y cómo lo reutilizamos
DCP Flow conserva la iteración, el backlog, la priorización, el sprint, la revisión y la mejora continua. Reduce ceremonias y roles rígidos cuando no agregan valor y redefine el sprint como un contrato de outcome verificable.
Sprint
No es solo una ventana de tiempo: es un compromiso acotado con uno o más outcomes verificables, evidencia esperada y límites claros.
Sprint Planning
Se reutiliza como preparación del outcome: alcance, dependencias, riesgos, Golden Flows, agentes involucrados y Definition of Done.
Daily / sincronización
No se fuerza una ceremonia diaria. Se usa coordinación proporcional al equipo y al riesgo, especialmente cuando trabajan varios agentes o humanos.
Review
Se convierte en Human Review apoyada por evidencia: lo construido se contrasta contra outcome, Golden Flows, Quality Gates y artifact real.
Retrospective
Se amplía hacia Lesson Learned: qué funcionó, qué falló, qué queda local y qué merece evolucionar Standards, Blueprints, Skills o Gates.
Roles
No se copian roles Scrum por dogma. DCP Flow distingue Human Owner/Reviewer, Kai, Execution Agents y responsables técnicos según contexto.
Incremento
El incremento debe ser demostrable. Código, documentación o configuración solo cuentan como avance cuando existe evidencia proporcional al riesgo.
Beyond Scrum
Principios que amplían Scrum dentro de DCP Flow
Discovery antes de ejecución
Antes de BUILD se investigan SaaS, OSS y componentes; la programación deja de ser la respuesta automática.
Architecture & Project Truth
El trabajo no parte de tickets aislados: parte de contexto, ADRs, Blueprint, repo truth y boundaries.
AI-native con gobierno
Kai y los agentes aceleran, pero capacidad técnica no equivale a autorización operacional.
Quality Gates + Evidence
No basta con “Done”. El outcome debe quedar respaldado por checks, artifacts, browser/runtime evidence y Human Acceptance cuando aplica.
DCP Flow
El journey de DCP Flow
Problema
Entender la necesidad antes de elegir tecnología.
Capacidades
Definir qué debe poder hacer la solución.
Discovery
Comparar SaaS, OSS, componentes y alternativas reales.
Decisión
IMPLEMENT, EXTEND o BUILD con evidencia.
Arquitectura
Elegir estructura, stack, boundaries y riesgos.
Sprint
Convertir el objetivo en outcomes verificables.
Ejecución
Humanos, Kai y agentes trabajan con contexto compartido.
Quality Gate
La evidencia decide si se puede avanzar.
Aprendizaje
Lo aprendido puede quedar local o evolucionar DCP Flow.
Discovery Gate
Solution Discovery antes de BUILD
La primera respuesta no es programar. DCP Flow obliga a investigar qué existe, probar candidatos y medir GAP antes de justificar desarrollo propio.
Adoptar una solución existente.
Usar una base existente y ampliar capacidades.
Construir cuando la evidencia demuestra que es la mejor opción.
Kai · Architecture context
Kai acompaña el contexto, no reemplaza la arquitectura
Kai puede ayudar a leer el proyecto, conectar decisiones previas, analizar repositorios e infraestructura y preparar handoffs. La arquitectura sigue siendo una decisión trazable dentro de DCP Flow y permanece sujeta a Human Gates.
Evidence
Quality Gates: evidencia antes que confianza
Un cambio no está listo porque un agente diga que funciona. Está listo cuando existe evidencia suficiente para el nivel de riesgo y el Golden Flow relevante.
01 → 03 → 06 → 12