mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-09-19 08:11:52 +08:00
Brian
cf54f4d76d
* refactor(bmm): move sprint-planning and sprint-status to plan/ They sit at the plan/ship boundary and their outputs are planning artifacts of the dev cycle; next commit makes sprint-planning the readiness gate, which is plan-side work. * refactor(bmm): fold readiness gate into sprint-planning, retire check-implementation-readiness The old skill was 1,154 lines of legacy numbered-step ceremony whose document discovery hardcoded filename globs (*prd*, *ux*, *epic*) that miss what current skills produce (SPEC.md, DESIGN.md) and still treated retired sharded docs as first-class. Sprint-planning now opens with a lean readiness gate: generic artifact discovery by content, forward/back traceability, PASS/CONCERNS/FAIL, stop on FAIL with findings. The IR trigger on John's and Winston's menus dispatches sprint-planning, so 'check implementation readiness' still works everywhere it used to. * refactor(bmm): modernize sprint-planning with deterministic script core SKILL.md drops the legacy XML step dialect for the product-brief style (~100 lines, uv run, headless contract). New scripts/sprint_plan.py owns the mechanical work — epic parsing, key derivation, ordering, preserve- never-downgrade merge, story-file detection, action_items carry-over, atomic writes, drift checks — with 11 tests wired in as test:sprint-planning. Judgment stays with the LLM: epic discovery, the readiness gate, and reconciling script-reported orphans and unparsed headings. checklist.md retired (the script performs that checklist); sprint-status-template.yaml is the single source for the status vocabulary. Output stays byte-compatible with build's sprint sync and retrospective's tooling. * refactor(bmm): fold sprint-status into sprint-planning's status view sprint_plan.py gains a status subcommand: counts (legacy values mapped), risk flags, open action items, and a priority-ordered next-action recommendation — the old skill's inference-driven summary, computed deterministically and covered by 9 new tests. bmad-sprint-status becomes a v6-shims husk that forwards with status-view intent and a deprecation notice; its dead data/validate modes had zero callers and are gone. If a hand-edited status file defeats the script, the skill falls back to reading it directly and summarizing by best judgment. New explanation page docs/explanation/sprint-planning.md covers the consolidated skill; workflow maps and references updated across all languages. * docs: changelog entries for skill reorg and sprint consolidation * fix(bmm): harden sprint_plan.py per review; add validate/fix intents with full progressive disclosure Review fixes (PR #2659 findings, bot + internal review): - Normalize legacy v6 statuses (drafted/contexted) on every read — merged by meaning and reported, never treated as illegal or reset - dropped_orphans carry their old status; transplant renames via --set - project_key/tracking_system/story_location preserved from the existing file unless overridden; refresh round-trips custom keys and user comments - Hardened write path: dump-to-bytes, fsync, permission-preserving atomic write inside the guarded block, explicit checks (no asserts), atomic restore - JSON-only argparse (errors and -h emit JSON); unicode-aware slugs with hash fallback; fenced code blocks ignored when parsing epics - Odd retro keys, date-typed stamps, and non-mapping YAML report cleanly instead of crashing; unparseable timestamps warn instead of silently disabling the staleness check; malformed action items flagged, not dropped - Dead check subcommand removed; generate --dry-run reports drift/in_sync - test:sprint-planning wired into quality and CI (was test-only) - Retro tests use a vendored template fixture (PATH-05); repo-level test-template-sync.js keeps it byte-identical to the source; template example timestamps and story_location fixed; header block pinned to the template by test New capability: - validate subcommand + reference: structural validation, never writes - fix flow: evidence-gathering subagents -> user-confirmed state table -> generate --fresh --set writes a pristine file (the one path allowed to downgrade); universal script-failure fallback to inference for every intent - SKILL.md is now a lean router: gate, tracking, status, fix, and validate each load as progressive-disclosure references Docs: explanation page gains Repair section; workflow-map and getting-started across all five languages mention the status view; headless payload nests under 'report' to avoid the status key collision; changelog updated. Test suite grows 20 -> 37; retro suite 91/91; docs build and validators green. * docs: mention repair in sprint-planning explanation description
84 lines
6.9 KiB
Markdown
84 lines
6.9 KiB
Markdown
---
|
|
title: "Mapa pracovních postupů"
|
|
description: Vizuální reference fází workflow BMad Method a jejich výstupů
|
|
sidebar:
|
|
order: 1
|
|
---
|
|
|
|
BMad Method (BMM) je modul v ekosystému BMad, zaměřený na dodržování osvědčených postupů context engineeringu a plánování. AI agenti fungují nejlépe s jasným, strukturovaným kontextem. Systém BMM buduje tento kontext progresivně napříč 4 odlišnými fázemi — každá fáze a volitelně více workflow v každé fázi produkují dokumenty, které informují další, takže agenti vždy vědí, co budovat a proč.
|
|
|
|
Zdůvodnění a koncepty vycházejí z agilních metodik, které byly v průmyslu úspěšně používány jako mentální framework.
|
|
|
|
Pokud si kdykoli nejste jisti, co dělat, skill `bmad-help` vám pomůže zůstat na cestě nebo vědět, co dělat dál. Vždy se můžete odkázat sem — ale `bmad-help` je plně interaktivní a mnohem rychlejší, pokud již máte nainstalovaný BMad Method. Navíc, pokud používáte různé moduly, které rozšířily BMad Method nebo přidaly další komplementární moduly — `bmad-help` se vyvíjí a zná vše, co je dostupné, aby vám dal nejlepší radu v daném okamžiku.
|
|
|
|
Důležitá poznámka: Každý workflow níže lze spustit přímo vaším nástrojem přes skill nebo načtením agenta a použitím záznamu z nabídky agenta.
|
|
|
|
<iframe src="/workflow-map-diagram.html" title="Diagram mapy workflow BMad Method" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
|
|
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
|
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">Otevřít diagram v novém panelu ↗</a>
|
|
</p>
|
|
|
|
## Fáze 1: Analýza (volitelná)
|
|
|
|
Prozkoumejte problémový prostor a validujte nápady před závazkem k plánování.
|
|
|
|
| Workflow | Účel | Produkuje |
|
|
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
|
| `bmad-brainstorming` | Brainstorming nápadů na projekt s řízenou facilitací brainstormingového kouče | `brainstorming-report.md` |
|
|
| `bmad-deep-recon` | Validace předpokladů nebo výběr mezi variantami — návrh promptu pro váš nástroj hloubkového výzkumu, zpracování jeho zprávy, nebo výzkum přímo zde; tržní, doménový, technický, konkurenční, uživatelský, akademický; ověřené, citované, obnovitelné | Výzkumná zpráva či shrnutí + volitelný HTML briefing |
|
|
| `bmad-product-brief` | Zachycení strategické vize — nejlepší, když je váš koncept jasný | `product-brief.md` |
|
|
| `bmad-prfaq` | Working Backwards — zátěžový test a zformování vašeho produktového konceptu | `prfaq-{project}.md` |
|
|
|
|
## Fáze 2: Plánování
|
|
|
|
Definujte, co budovat a pro koho.
|
|
|
|
| Workflow | Účel | Produkuje |
|
|
| --------------------------- | ---------------------------------------- | ------------ |
|
|
| `bmad-prd` | Definice požadavků (FR/NFR) | `PRD.md` |
|
|
| `bmad-ux` | Návrh uživatelského zážitku (když záleží na UX) | `DESIGN.md`, `EXPERIENCE.md` |
|
|
| `bmad-spec` | Destiluje jakýkoli vstupní záměr (brief, PRD, přepis, poznámky) do stručného kontraktu `SPEC.md` + doprovodných souborů — zafixuje CO před JAK | `SPEC.md` + doprovodné soubory pod `{output_folder}/specs/spec-{slug}/` |
|
|
|
|
## Fáze 3: Solutioning
|
|
|
|
Rozhodněte, jak to budovat, a rozložte práci na stories.
|
|
|
|
| Workflow | Účel | Produkuje |
|
|
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
|
| `bmad-architecture` | Explicitní technická rozhodnutí | `architecture.md` s ADR |
|
|
| `bmad-create-epics-and-stories` | Rozložení požadavků na implementovatelnou práci | Soubory epiců se stories |
|
|
| `bmad-sprint-planning` | Brána připravenosti před implementací, poté sledování stories a přehled stavu sprintu | PASS/CONCERNS/FAIL + `sprint-status.yaml` |
|
|
|
|
## Fáze 4: Implementace
|
|
|
|
Všechny implementační vstupy se sbíhají do `bmad-build`. Přijímá přímý záměr, issue, specifikaci nebo naplánovanou story a zvolí potřebnou míru upřesnění, plánování, implementace a revize.
|
|
|
|
| Workflow | Účel | Produkuje |
|
|
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
|
| `bmad-build` | Převod přímého záměru nebo naplánované story na implementovaný a revidovaný kód | `spec-*.md` + kód |
|
|
| `bmad-code-review` | Validace kvality implementace | Schváleno nebo požadovány změny |
|
|
| `bmad-correct-course` | Řešení významných změn uprostřed sprintu | Aktualizovaný plán nebo přesměrování |
|
|
| `bmad-retrospective` | Revize po dokončení epicu | Poučení |
|
|
|
|
### Přímý a plánovaný vstup
|
|
|
|
Jasná práce může vstoupit do `bmad-build` přímo. Větší iniciativa může nejprve vytvořit PRD, UX, architekturu, epicy, stories, kontrolu připravenosti a sprint plán. Tyto artefakty přidávají kontext; nevybírají jiný implementační workflow.
|
|
|
|
## Správa kontextu
|
|
|
|
Každý dokument se stává kontextem pro další fázi. PRD říká architektovi, jaká omezení záleží. Architektura říká dev agentovi, jaké vzory následovat. Soubory stories poskytují zaměřený, kompletní kontext pro implementaci. Bez této struktury agenti dělají nekonzistentní rozhodnutí.
|
|
|
|
### Kontext projektu
|
|
|
|
:::tip[Doporučeno]
|
|
Vytvořte `project-context.md` pro zajištění toho, aby AI agenti dodržovali pravidla a preference vašeho projektu. Tento soubor funguje jako ústava vašeho projektu — vede implementační rozhodnutí napříč všemi workflow. Tento volitelný soubor lze vygenerovat na konci tvorby architektury, nebo u existujícího projektu ho lze také vygenerovat pro zachycení toho, co je důležité pro zachování souladu se současnými konvencemi.
|
|
:::
|
|
|
|
**Jak ho vytvořit:**
|
|
|
|
- **Ručně** — Vytvořte `_bmad-output/project-context.md` s vaším technologickým stackem a pravidly implementace
|
|
- **Vygenerujte ho** — Spusťte `bmad-generate-project-context` pro automatické generování z vaší architektury nebo kódové báze
|
|
|
|
[**Zjistit více o project-context.md**](../explanation/project-context.md)
|