BMAD: planificar abans d'escriure codi

Si escric codi sense pensar, em perd a la tercera setmana. Si planifico massa, em perd abans. Vaig haver d’aprendre a planificar sense ofegar-me planificant.

El context

Aquest repo no és un projecte d’una tarda: hi ha 9 epics i una quarantena de stories. Ho he portat sol — sense equip, sense roadmap d’empresa, sense pressió externa. Aquesta llibertat és, també, la trampa més fàcil per a un projecte personal: que la pròxima cosa “interessant” desbanqui l’actual cada divendres a la nit.

L’únic que coneixia que funcionés contra això era una disciplina lleugera de planificació. BMAD és la que vaig adoptar — un mètode amb fases curtes i artefactes versionats al costat del codi.

La decisió

BMAD no és més que nou fases en ordre estricte, cada una amb un artefacte versionat:

analyze → plan → architect → stories → validate
       → sprint → dev → review → qa → retro

• analyze produeix un brief (_bmad/briefs/*.md): què volem, per què, què queda fora.
• plan produeix el PRD (_bmad/planning/prd.md): requeriments concrets, mètriques, gates.
• architect produeix l’architecture.md: layering, protocols, models de threading.
• stories parteix l’arquitectura en epics i stories petites (_bmad/epics/, _bmad/stories/). Cada story cap a un PR.
• validate és la passada de PO: cap story orfe, cap requeriment sense story.
• sprint agrupa stories en un sprint.
• dev, review, qa són les tres fases d’implementació d’una story.
• retro tanca el sprint amb què es fa diferent al pròxim.

Cada fase té un slash-command (/bmad-analyze, /bmad-plan, …). El més important: els artefactes viuen al repo (_bmad/). No a Notion, no a Linear. Si la planificació no viu al costat del codi, es desactualitza sense que ningú ho noti.

Branques: una per història

Tres tipus de branca i prou:

Branca	Rol
main	Releases estables. Mai un push directe.
staging	Integració. Aquí aterren els artefactes BMAD.
feature/story-XX-XX-...	Una per story d’implementació.

Merges sempre --no-ff (a GitHub: “Create a merge commit”). Mai squash, mai rebase. El graf de Git conserva la bombolla per història — pots veure quan una story va començar, quan va acabar, què va revertir. Squash perdria això; rebase també.

És més soroll al graf? Sí. És el preu de tenir traça visual. Quan, dos mesos més tard, busques quan vas canviar el transport.serial i per què, el graf t’ho mostra; el squash no.

Per què el ruff.extend-exclude està ancorat a stories concretes. Cada path llegacy exclòs al pyproject.toml té un comentari amb la story que el retira. Quan la story es completa, l’exclude se’n va amb ella. Sense aquest acoblament, els legacy paths es converteixen en permanents: ningú gosa tocar-los perquè “potser els necessitem”. Amb l’acoblament, el deute té data de caducitat des del dia que es contreu.

El cost real és més alt del que admetria abans. Cada funcionalitat porta un brief mini, dues iteracions de review (codi + QA) i una retro al sprint. Si fos només codi pur, anaria més ràpid els primers dies.

La recompensa: l’epic 09 (alinear vocabulari a Lumware) es va planificar, executar i mergir en hores. Tota la rename python2arduino → lumware, els docs, els imports, els tests. No perquè la feina fos petita, sinó perquè l’estructura per fer-la ja existia. Sense BMAD, hagués estat una setmana de bugs.

El que ve

Hem parlat de tot el sistema. Falta dir per què té el nom que té i per què la paleta de colors és R/G/B/W i no una altra. Pròxim post: identitat spectrum.