Backlog
Es manté com una llista explícita i prioritzada de treball, però connectada a Project Truth, risc, discovery i decisions d’arquitectura.
Metodologia · De la necessitat a l’evidència
Una metodologia d’enginyeria per treballar amb IA sense perdre criteri, control ni traçabilitat.
DCP Flow combina pràctiques adaptades de Scrum, Solution Discovery, arquitectura, agents d’IA, Quality Gates, Evidence i Human Gates. No copia Scrum: reutilitza els components útils dins d’un sistema més ampli orientat a decisions verificables.
Scrum → DCP Flow
Què prenem de Scrum i com ho reutilitzem
DCP Flow conserva iteració, backlog, priorització, sprint, review i millora contínua. Redueix cerimònies i rols rígids quan no aporten valor i redefineix el sprint com un contracte d’outcome verificable.
Sprint
No és només una finestra de temps: és un compromís acotat amb outcomes verificables, evidència esperada i límits clars.
Sprint Planning
Es reutilitza com a preparació de l’outcome: abast, dependències, riscos, Golden Flows, agents implicats i Definition of Done.
Daily / sincronització
No s’imposa una cerimònia diària. La coordinació és proporcional a l’equip i al risc, especialment amb diversos agents o humans.
Review
Es converteix en Human Review amb evidència: el resultat es contrasta amb outcome, Golden Flows, Quality Gates i artifact real.
Retrospective
S’amplia cap a Lesson Learned: què va funcionar, què va fallar, què queda local i què pot evolucionar Standards, Blueprints, Skills o Gates.
Rols
No es copien rols Scrum per dogma. DCP Flow distingeix Human Owner/Reviewer, Kai, Execution Agents i responsabilitat tècnica segons context.
Increment
L’increment ha de ser demostrable. Codi, documentació o configuració només compten amb evidència proporcional al risc.
Beyond Scrum
Principis que amplien Scrum dins DCP Flow
Discovery abans d’execució
Abans de BUILD s’investiguen SaaS, OSS i components; programar deixa de ser la resposta automàtica.
Architecture & Project Truth
El treball no parteix de tickets aïllats: parteix de context, ADRs, Blueprint, repository truth i boundaries.
AI-native amb govern
Kai i els agents acceleren, però capacitat tècnica no equival a autorització operacional.
Quality Gates + Evidence
“Done” no és suficient. L’outcome necessita checks, artifacts, browser/runtime evidence i Human Acceptance quan aplica.
DCP Flow
El journey de DCP Flow
Problema
Entendre la necessitat abans de triar tecnologia.
Capacitats
Definir què ha de poder fer la solució.
Discovery
Comparar SaaS, OSS, components i alternatives reals.
Decisió
IMPLEMENT, EXTEND o BUILD amb evidència.
Arquitectura
Triar estructura, stack, boundaries i riscos.
Sprint
Convertir l’objectiu en outcomes verificables.
Execució
Humans, Kai i agents treballen amb context compartit.
Quality Gate
L’evidència decideix si es pot avançar.
Aprenentatge
L’aprenentatge pot quedar local o evolucionar DCP Flow.
Discovery Gate
Solution Discovery abans de BUILD
La primera resposta no és programar. DCP Flow obliga a investigar què existeix, provar candidats i mesurar GAP abans de justificar desenvolupament propi.
Adoptar una solució existent.
Utilitzar una base existent i ampliar capacitats.
Construir quan l’evidència demostra que és la millor opció.
Kai · Architecture context
Kai acompanya el context, no substitueix l’arquitectura
Kai pot ajudar a llegir el projecte, connectar decisions prèvies, analitzar repositoris i infraestructura i preparar handoffs. L’arquitectura continua sent una decisió traçable dins DCP Flow i subjecta a Human Gates.
Evidence
Quality Gates: evidència abans que confiança
Un canvi no està preparat perquè un agent digui que funciona. Ho està quan existeix evidència suficient per al nivell de risc i el Golden Flow rellevant.
01 → 03 → 06 → 12