Back to Bmad Method

Hướng dẫn BMAD cho Developer

docs/vi-vn/bmad-developer-guide.md

6.6.028.3 KB
Original Source

BMAD Method — Hướng dẫn toàn diện cho Developer

BMAD (Build More Architect Dreams) là framework phát triển phần mềm hỗ trợ bởi AI, giúp team đi từ ý tưởng đến sản phẩm một cách có cấu trúc, nhất quán và hiệu quả.


Mục lục

  1. BMAD là gì?
  2. Nguyên lý cốt lõi
  3. Kiến trúc hệ thống — Các Agent
  4. Quy trình làm việc — 4 Giai đoạn
  5. Chọn nhánh phù hợp
  6. Hướng dẫn từng bước áp dụng BMAD
  7. Kiểm thử với BMAD — Hướng dẫn cho QC
  8. Các công cụ hỗ trợ
  9. Cấu trúc thư mục dự án
  10. Mẹo và Best Practices

1. BMAD là gì?

BMAD Method là một hệ thống phối hợp nhiều AI agent chuyên biệt để hỗ trợ toàn bộ vòng đời phát triển phần mềm — từ phân tích ý tưởng, lập kế hoạch, thiết kế kiến trúc, đến triển khai code và kiểm thử.

Điểm khác biệt so với cách dùng AI thông thường

Cách thông thườngBMAD Method
Hỏi AI từng câu rời rạcWorkflow có cấu trúc, mỗi bước tạo đầu ra cho bước kế tiếp
Một AI làm tất cảNhiều agent chuyên biệt, mỗi agent hiểu sâu vai trò của mình
Không có tài liệu hóaMỗi giai đoạn sinh ra tài liệu chuẩn (PRD, Architecture, Stories)
Developer phải giám sát liên tụcAgent tự chủ dài hơn, chỉ cần con người tại các điểm kiểm tra quan trọng

BMAD phù hợp với ai?

  • Developer cần xây dựng tính năng nhanh, chất lượng cao
  • Tech Lead / Architect cần thiết kế hệ thống và phân rã công việc
  • Product Manager cần định nghĩa yêu cầu rõ ràng
  • QC/Tester cần sinh test case có truy vết yêu cầu
  • Team nhỏ muốn áp dụng quy trình chuẩn không cần nhiều overhead

2. Nguyên lý cốt lõi

2.1. Tài liệu là "ngôn ngữ chung" giữa con người và AI

Mỗi giai đoạn trong BMAD sinh ra một tài liệu chuẩn. Tài liệu đó trở thành đầu vào cho giai đoạn kế tiếp. Agent AI đọc tài liệu để hiểu context, thay vì phụ thuộc vào lịch sử hội thoại có thể bị mất.

Ý tưởng → [Brief/PRFAQ] → PRD → Architecture → Epics/Stories → Code → Tests

2.2. Phân tách "XÂY GÌ" và "XÂY NHƯ THẾ NÀO"

BMAD tách bạch rõ ràng hai câu hỏi quan trọng nhất:

  • Planning (Giai đoạn 2): Trả lời "XÂY GÌ và vì sao?" → Đầu ra: PRD
  • Solutioning (Giai đoạn 3): Trả lời "XÂY NHƯ THẾ NÀO?" → Đầu ra: Architecture + Epics/Stories

Đây là nguyên lý quan trọng nhất. Nhiều dự án thất bại vì triển khai khi chưa thống nhất được "XÂY GÌ", hoặc bắt đầu code mà chưa quyết định "XÂY NHƯ THẾ NÀO".

2.3. Agent chuyên biệt — mỗi vai trò một chuyên gia

BMAD không dùng một AI đa năng mà dùng các agent được cấu hình để đóng vai chuyên gia cụ thể: PM, Architect, Developer, UX Designer, Technical Writer. Mỗi agent có phong cách tư duy, ưu tiên, và workflow riêng.

2.4. Con người chỉ tham gia tại các điểm kiểm tra quan trọng

BMAD được thiết kế để AI tự chủ trong phạm vi đã định nghĩa, chỉ đưa con người vào:

  • Phê duyệt chuyển giai đoạn (PRD xong → Architect làm việc)
  • Review kết quả tổng thể (sau Dev Story, sau epic)
  • Quyết định thay đổi hướng (Correct Course)

2.5. Có thể mở rộng theo nhu cầu

Ba nhánh lập kế hoạch với độ phức tạp tăng dần:

NhánhPhù hợp vớiStory ước tính
Quick FlowBug fix, tính năng nhỏ, phạm vi rõ1–15 stories
BMad MethodSản phẩm, nền tảng, tính năng phức tạp10–50+ stories
EnterpriseHệ thống tuân thủ, đa tenant, đa team30+ stories

3. Kiến trúc hệ thống — Các Agent

3.1. Các Agent chính

AgentTên nhân vậtSkill IDVai trò
AnalystMarybmad-analystBrainstorm, nghiên cứu thị trường/kỹ thuật, tạo Product Brief và PRFAQ
Product ManagerJohnbmad-pmTạo và quản lý PRD, Epics, Stories, kiểm tra Implementation Readiness
ArchitectWinstonbmad-architectThiết kế Architecture, ADR, kiểm tra Implementation Readiness
DeveloperAmeliabmad-agent-devTriển khai story, tạo test, code review, sprint planning
UX DesignerSallybmad-ux-designerThiết kế UX specification
Technical WriterPaigebmad-tech-writerViết tài liệu, cập nhật standards, giải thích khái niệm

3.2. Cách gọi Agent

Qua Skill (Claude Code / Cursor):

bmad-analyst
bmad-pm
bmad-architect
bmad-agent-dev

Qua Trigger (sau khi đã nạp agent, gõ mã ngắn trong hội thoại):

TriggerAgentWorkflow
BPAnalystBrainstorm
CBAnalystCreate Brief
CPPMCreate PRD
VPPMValidate PRD
EPPMCreate Epics & Stories
CAArchitectCreate Architecture
IRPM / ArchitectImplementation Readiness
SPDeveloperSprint Planning
DSDeveloperDev Story
QADeveloperQA Test Generation
CRDeveloperCode Review

4. Quy trình làm việc — 4 Giai đoạn

┌─────────────────┐    ┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   Giai đoạn 1   │    │   Giai đoạn 2   │    │   Giai đoạn 3    │    │   Giai đoạn 4   │
│   PHÂN TÍCH     │───▶│   LẬP KẾ HOẠCH  │───▶│  ĐỊNH HÌNH GIẢI  │───▶│   TRIỂN KHAI    │
│  (Tùy chọn)     │    │  (Bắt buộc)     │    │  PHÁP (BMad/Ent) │    │  (Bắt buộc)     │
│                 │    │                 │    │                  │    │                 │
│ Brief, PRFAQ    │    │ PRD, UX Spec    │    │ Architecture,    │    │ Sprint, Stories, │
│ Research        │    │                 │    │ Epics, Stories   │    │ Code, Test, QA   │
└─────────────────┘    └─────────────────┘    └──────────────────┘    └─────────────────┘

Giai đoạn 1: Phân tích (Tùy chọn)

Giai đoạn này giúp khám phá và xác nhận ý tưởng trước khi cam kết lập kế hoạch chi tiết. Bỏ qua nếu yêu cầu đã rõ.

Các công cụ:

Brainstorming — Khi cần khai phá ý tưởng

Trigger: BP (trong agent Analyst)
Đầu ra: brainstorming-report.md

Sử dụng 60+ kỹ thuật brainstorming, tạo 100+ ý tưởng đa dạng, sau đó phân tích, lọc và đề xuất hướng tiếp cận.

Product Brief — Khi concept đã tương đối rõ

Trigger: CB (trong agent Analyst)
Đầu ra: product-brief.md

Tóm tắt điều hành 1–2 trang: vấn đề, giải pháp, đối tượng, lợi thế cạnh tranh, rủi ro.

PRFAQ — Khi cần stress-test concept

Trigger: (hỏi Analyst về PRFAQ)
Đầu ra: prfaq.md

Phương pháp "Working Backwards" của Amazon: viết thông cáo báo chí như thể sản phẩm đã tồn tại, sau đó trả lời các câu hỏi khó nhất từ khách hàng. Buộc phải rõ ràng theo hướng lấy khách hàng làm trung tâm.

Nghiên cứu — Xác thực giả định

Trigger: MR (Market Research), DR (Domain Research), TR (Technical Research)

Giai đoạn 2: Lập kế hoạch (Bắt buộc)

Xác định rõ cần xây gìcho ai.

Tạo PRD — PM Agent

Trigger: CP
Đầu ra: PRD.md

PRD bao gồm: mục tiêu sản phẩm, functional requirements (FR), non-functional requirements (NFR), user stories cấp cao, acceptance criteria.

Thiết kế UX — UX Designer Agent (Tùy chọn)

Trigger: CU
Đầu ra: ux-spec.md

Dùng khi UX/UI là yếu tố quan trọng. Bao gồm user flows, component specs, interaction patterns.

Validate PRD — PM Agent

Trigger: VP

Kiểm tra tính đầy đủ, nhất quán, và khả năng triển khai của PRD trước khi chuyển sang giai đoạn 3.


Giai đoạn 3: Định hình giải pháp (Bắt buộc với BMad Method / Enterprise)

Quyết định xây như thế nào và phân rã công việc.

Tạo Architecture — Architect Agent

Trigger: CA
Đầu ra: architecture.md + ADR (Architecture Decision Records)

Bao gồm: tech stack, component design, data models, API contracts, deployment strategy, ADR cho các quyết định quan trọng.

Tạo Epics & Stories — PM Agent

Trigger: EP
Đầu ra: epics/ thư mục với các file story

Phân rã PRD và Architecture thành Epics (nhóm tính năng) và Stories (đơn vị công việc cụ thể). Mỗi story có: mô tả, acceptance criteria, technical notes.

Implementation Readiness Check — Architect Agent

Trigger: IR
Kết quả: PASS / CONCERNS / FAIL

Cổng kiểm tra trước khi bắt đầu triển khai. Đảm bảo mọi thứ đã đủ rõ ràng để developer có thể làm việc độc lập.


Giai đoạn 4: Triển khai (Bắt buộc)

Xây dựng từng story một theo thứ tự ưu tiên.

Sprint Planning — Developer Agent

Trigger: SP
Đầu ra: sprint-status.yaml

Xác định stories sẽ làm trong sprint, thứ tự ưu tiên và tracking.

Dev Story — Developer Agent

Trigger: DS
Đầu ra: Code chạy được + unit/integration tests

Agent tự chủ triển khai story theo acceptance criteria. Đọc architecture và project-context để đảm bảo nhất quán.

Code Review — Developer Agent

Trigger: CR
Kết quả: Approved / Changes Requested

Review tự động: correctness, style, security, performance, test coverage.

QA Test Generation — Developer Agent

Trigger: QA
Đầu ra: API tests + E2E tests

Sinh test case cho API và E2E sau khi epic hoàn tất. Chi tiết ở Mục 7.

Correct Course — PM Agent

Trigger: CC

Xử lý thay đổi yêu cầu lớn giữa sprint mà không phá vỡ quy trình.

Retrospective — Developer Agent

Trigger: ER (Epic Retrospective)

Review sau khi hoàn tất một epic. Ghi lại bài học, pattern tốt, vấn đề gặp phải.


5. Chọn nhánh phù hợp

Quick Flow — Nhánh nhanh

Khi nào dùng:

  • Bug fix
  • Tính năng nhỏ, phạm vi rõ ràng
  • Cập nhật đơn lẻ (1–15 stories)
  • Bạn đã hiểu đầy đủ yêu cầu

Bỏ qua: Giai đoạn 1, 2, 3 hoàn toàn

Dùng: Quick Dev (bmad-quick-dev)

Mô tả yêu cầu → Làm rõ ý định → Sinh spec → Triển khai → Review → Done

Quick Dev gộp tất cả vào một workflow: làm rõ yêu cầu, lập kế hoạch mini, triển khai, code review, và trình bày kết quả.


BMad Method — Nhánh đầy đủ

Khi nào dùng:

  • Sản phẩm mới hoặc nền tảng
  • Tính năng phức tạp với nhiều dependencies
  • 10–50+ stories cần phối hợp nhiều developer

Đi qua: Giai đoạn 1 (tùy chọn) → 2 → 3 → 4


Enterprise — Nhánh mở rộng

Khi nào dùng:

  • Hệ thống đa tenant
  • Yêu cầu tuân thủ (compliance), security audit
  • 30+ stories, nhiều team
  • Cần truy vết yêu cầu đầy đủ

Thêm vào: Security review, DevOps pipeline, NFR assessment, Test Architect Module (TEA)


6. Hướng dẫn từng bước áp dụng BMAD

6.1. Dự án mới

Bước 1: Cài đặt BMAD

bash
# Yêu cầu: Node.js 20+, Git
npx bmad-method install

Trình cài đặt sẽ hỏi:

  • IDE đang dùng (Claude Code, Cursor, hoặc tương tự)
  • Modules muốn cài (core bắt buộc, thêm TEA nếu cần test nâng cao)
  • Nhánh lập kế hoạch (Quick Flow / BMad Method / Enterprise)

Bước 2: Khởi động với bmad-help

bmad-help

Đây là điểm bắt đầu thông minh. Agent sẽ hỏi về dự án của bạn và dẫn bạn đến đúng workflow.

bmad-help Tôi có ý tưởng về ứng dụng SaaS quản lý task, bắt đầu từ đâu?
bmad-help Tôi cần thêm tính năng export PDF, dùng quick flow hay đầy đủ?

Bước 3: Tạo Project Context (khuyến nghị mạnh)

bash
# Tạo tự động sau khi có architecture
bmad-generate-project-context

# Hoặc tạo thủ công
touch _bmad-output/project-context.md

File project-context.md là "bản hiến pháp" kỹ thuật của dự án — được tất cả agent tự động nạp:

markdown
# Project Context

## Technology Stack
- Node.js 20.x, TypeScript 5.3
- React 18.2, Zustand (không dùng Redux)
- PostgreSQL 15, Prisma ORM
- Testing: Vitest, Playwright, MSW

## Critical Implementation Rules
- Bật strict mode — không dùng `any`
- Dùng `interface` cho public API, `type` cho union/intersection
- API calls phải qua `apiClient` singleton
- Components đặt trong `/src/components/` với co-located tests

Bước 4: Chạy Analysis (nếu cần)

bash
# Mở agent Analyst
bmad-analyst

# Trong hội thoại, gõ trigger:
BP    # Brainstorm ý tưởng
CB    # Tạo Product Brief
MR    # Research thị trường

Bước 5: Tạo PRD

bash
# Mở agent PM
bmad-pm

# Trigger tạo PRD
CP    # Create PRD (có hướng dẫn từng bước)
VP    # Validate PRD sau khi hoàn thiện

Bước 6: Tạo Architecture (BMad Method / Enterprise)

bash
# Mở agent Architect
bmad-architect

# Trigger
CA    # Create Architecture
IR    # Implementation Readiness Check

Bước 7: Tạo Epics & Stories

bash
# Mở agent PM
bmad-pm

# Trigger
EP    # Create Epics and Stories

Bước 8: Triển khai theo Stories

bash
# Mở agent Developer
bmad-agent-dev

# Mỗi sprint
SP    # Sprint Planning
DS    # Dev Story (làm từng story)
CR    # Code Review
QA    # Tạo tests (sau khi epic hoàn tất)
ER    # Epic Retrospective

6.2. Dự án đã tồn tại

Bước 1: Tạo Project Context từ codebase hiện tại

bash
# Chạy trong agent Developer hoặc Architect
bmad-generate-project-context

Agent sẽ khám phá codebase và tạo project-context.md từ:

  • package.json, pyproject.toml, hoặc build files
  • Cấu trúc thư mục
  • Conventions hiện có trong code

Bước 2: Tạo tài liệu index

Tạo hoặc cập nhật docs/index.md với:

  • Mục tiêu kinh doanh của dự án
  • Architecture overview
  • Các quy tắc quan trọng cần giữ

Bước 3: Chọn cách tiếp cận phù hợp

  • Thay đổi nhỏ (bug fix, tính năng nhỏ): Dùng bmad-quick-dev trực tiếp
  • Thay đổi lớn (module mới, refactor lớn): Dùng BMad Method đầy đủ từ Giai đoạn 2

Bước 4: Quick Dev cho việc nhỏ

bash
# Mở skill Quick Dev
bmad-quick-dev

# Mô tả yêu cầu, agent sẽ:
# 1. Làm rõ ý định (có người trong vòng lặp)
# 2. Tạo mini-spec nếu cần
# 3. Triển khai tự động
# 4. Code review
# 5. Trình bày kết quả để bạn approve

6.3. Luồng làm việc mẫu — Tính năng mới (BMad Method)

Ngày 1-2: Analysis
  ├── bmad-analyst → CB → product-brief.md
  └── (tùy chọn) bmad-analyst → MR → market-research.md

Ngày 2-3: Planning  
  ├── bmad-pm → CP → PRD.md
  ├── bmad-pm → VP (validate)
  └── (nếu có UI) bmad-ux-designer → CU → ux-spec.md

Ngày 3-4: Solutioning
  ├── bmad-architect → CA → architecture.md
  ├── bmad-pm → EP → epics/ (stories)
  └── bmad-architect → IR → PASS ✓

Ngày 5+: Implementation (lặp lại cho mỗi story)
  ├── bmad-agent-dev → SP → sprint-status.yaml
  ├── bmad-agent-dev → DS → code + tests
  ├── bmad-agent-dev → CR → approved
  └── (sau epic) bmad-agent-dev → QA → e2e tests

7. Kiểm thử với BMAD — Hướng dẫn cho QC

BMAD cung cấp hai hướng tiếp cận kiểm thử:

7.1. QA tích hợp sẵn — Nhẹ nhàng (Developer Agent)

Phù hợp với: Dự án nhỏ–trung bình, cần bao phủ test nhanh

Kích hoạt:

bash
# Trong agent Developer
bmad-agent-dev

# Sau khi hoàn tất một epic (tất cả stories đã dev + review xong)
QA    # QA Test Generation

5 bước workflow QA:

  1. Phát hiện framework: Agent tự nhận diện Jest, Vitest, Playwright, Cypress từ codebase
  2. Xác định tính năng cần test: Dựa vào stories và acceptance criteria của epic vừa hoàn tất
  3. Tạo API tests: Status codes, cấu trúc response, happy path, edge cases
  4. Tạo E2E tests: User workflows, semantic locators (role/label/text — không dùng CSS selector)
  5. Chạy và xác minh: Tự chạy tests, phát hiện và sửa lỗi ngay

Các nguyên tắc khi sinh test:

typescript
// ✅ Dùng semantic locator
await page.getByRole('button', { name: 'Đăng nhập' }).click()
await page.getByLabel('Email').fill('[email protected]')

// ❌ Không dùng CSS selector cứng
await page.locator('.btn-primary#login').click()

// ✅ Test độc lập, không phụ thuộc thứ tự
test('create task', async () => {
  // setup riêng cho test này
})

// ❌ Không hardcode wait/sleep
await page.waitForTimeout(3000) // Không làm thế này

Khi nào dùng:

  • Cần bao phủ test nhanh cho tính năng mới
  • Dự án nhỏ–trung bình không cần chiến lược kiểm thử nâng cao
  • Muốn tự động hóa kiểm thử mà không cần thiết lập phức tạp

7.2. Module Test Architect (TEA) — Nâng cao

Phù hợp với: Dự án lớn, miền nghiệp vụ phức tạp, cần truy vết yêu cầu

Cài đặt:

bash
npx bmad-method install
# Chọn thêm module: TEA (Test Architect)

Agent TEA: Murat (Master Test Architect)

9 workflow của TEA:

#WorkflowMục đích
1Test DesignTạo chiến lược kiểm thử gắn với yêu cầu (PRD/AC)
2ATDDPhát triển hướng Acceptance Test — viết test trước khi code
3AutomateTạo automated test với pattern nâng cao
4Test ReviewKiểm tra chất lượng và độ bao phủ của bộ test
5TraceabilityLiên kết test ngược về yêu cầu trong PRD
6NFR AssessmentĐánh giá yêu cầu phi chức năng (performance, security, reliability)
7CI SetupCấu hình thực thi test trong CI/CD pipeline
8Framework ScaffoldingDựng hạ tầng test cho dự án mới
9Release GateRa quyết định go/no-go dựa trên chất lượng

Hệ thống ưu tiên P0–P3:

MứcÝ nghĩaVí dụ
P0Critical — phải pass 100%Thanh toán, xác thực, bảo mật
P1High — phải pass cho releaseCore business flow
P2Medium — nên passTính năng phụ, edge cases
P3Low — test khi có thểUI detail, minor UX

Luồng ATDD với TEA:

QC viết Acceptance Criteria (AC) → 
TEA tạo test từ AC (trước khi code) → 
Developer implement để test pass → 
TEA verify traceability (AC ↔ test ↔ requirement) → 
Release Gate go/no-go

7.3. So sánh hai hướng tiếp cận

Yếu tốQA tích hợp sẵnModule TEA
Thời điểm testSau khi epic hoàn tấtCó thể trước khi code (ATDD)
Thiết lậpKhông cần cài thêmCài module riêng
Loại testAPI + E2EAPI, E2E, ATDD, NFR, Performance
Truy vết yêu cầuKhôngCó (Traceability workflow)
Release gateKhôngCó (go/no-go)
Phù hợp nhấtDự án nhỏ–trung bìnhDự án lớn, có compliance

7.4. Vị trí kiểm thử trong vòng đời dự án

Story 1: Dev → Code Review → ✓
Story 2: Dev → Code Review → ✓
Story 3: Dev → Code Review → ✓
...
Epic hoàn tất → QA Test Generation → Tests pass → Epic Retrospective

Lưu ý: QA Test Generation chạy sau khi toàn bộ epic hoàn tất, không phải sau từng story. Mục đích là kiểm thử tích hợp các stories với nhau.


7.5. Edge Case Hunter — Công cụ tìm trường hợp biên

Ngoài QA workflow, Developer Agent còn hỗ trợ:

bash
# Trong hội thoại với Developer Agent
bmad-review-edge-case-hunter

Phân tích toàn bộ nhánh điều kiện trong code để tìm:

  • Trường hợp biên chưa được xử lý
  • Null/undefined checks bị thiếu
  • Điều kiện race condition
  • Input validation gaps

8. Các công cụ hỗ trợ

8.1. Party Mode — Thảo luận đa agent

bash
bmad-party-mode

Triệu tập nhiều agent vào cùng một hội thoại để thảo luận các quyết định quan trọng:

  • Kiến trúc: PM + Architect + Developer cùng đánh giá trade-off
  • Tính năng phức tạp: UX Designer + Architect + PM
  • Post-mortem: Tất cả agent cùng phân tích sự cố
  • Sprint retrospective: PM + Developer + QC

8.2. Advanced Elicitation — Tinh luyện đầu ra

bash
bmad-advanced-elicitation

Buộc AI xem xét lại đầu ra bằng các phương pháp:

Phương phápMục đích
Pre-mortemGiả sử thất bại → lần ngược nguyên nhân
First PrinciplesLoại bỏ giả định, bắt đầu từ sự thật cơ bản
Red Team / Blue TeamTự tấn công, tự bảo vệ
Socratic QuestioningChất vấn mọi khẳng định
Constraint RemovalBỏ ràng buộc → thấy giải pháp khác
Stakeholder MappingĐánh giá từ góc nhìn từng bên liên quan

Dùng sau khi có một tài liệu quan trọng (PRD, Architecture) để tìm điểm yếu trước khi tiếp tục.

8.3. Adversarial Review — Review hoài nghi

bash
bmad-review-adversarial-general

Review kiểu "devil's advocate" — giả định vấn đề luôn tồn tại:

  • Phải tìm được tối thiểu 10 vấn đề
  • Tìm những gì còn thiếu, không chỉ những gì sai
  • Trực giao với Edge Case Hunter

8.4. Distillator — Nén tài liệu cho LLM

bash
bmad-distillator

Khi tài liệu quá lớn (PRD dài, Architecture phức tạp), Distillator nén nội dung tối ưu cho LLM mà không mất thông tin quan trọng.

8.5. Shard Large Documents — Tách file lớn

bash
bmad-shard-doc

Tách file markdown lớn thành các file phần nhỏ hơn, với index tự động.


9. Cấu trúc thư mục dự án

Sau khi cài BMAD và chạy qua các giai đoạn, dự án sẽ có cấu trúc:

your-project/
├── _bmad/                              # Cấu hình BMAD (không chỉnh sửa thủ công)
│   ├── core/                           # Module core
│   └── bmm/                            # Modules đã cài (TEA, v.v.)
│
├── _bmad-output/                       # Tất cả artifacts sinh ra
│   ├── project-context.md              # Bản hiến pháp kỹ thuật của dự án
│   ├── planning-artifacts/
│   │   ├── product-brief.md            # Giai đoạn 1 output
│   │   ├── PRD.md                      # Giai đoạn 2 output
│   │   ├── ux-spec.md                  # Giai đoạn 2 output (nếu có)
│   │   ├── architecture.md             # Giai đoạn 3 output
│   │   └── epics/                      # Giai đoạn 3 output
│   │       ├── epic-1-auth/
│   │       │   ├── story-1-login.md
│   │       │   ├── story-2-register.md
│   │       │   └── story-3-reset-password.md
│   │       └── epic-2-dashboard/
│   └── implementation-artifacts/
│       └── sprint-status.yaml          # Tracking sprint
│
├── .claude/skills/                     # Skills cho Claude Code
│   ├── bmad-pm.md
│   ├── bmad-architect.md
│   └── ...
│
├── docs/                               # Tài liệu dự án
│   └── index.md                        # Overview, goals, architecture notes
│
└── src/                                # Source code dự án

10. Mẹo và Best Practices

Chat mới cho mỗi workflow

Luôn bắt đầu một hội thoại mới khi chuyển sang workflow khác.

Mỗi workflow của BMAD thiết kế để chạy trong context rõ ràng. Việc tiếp tục hội thoại cũ có thể gây ra nhiễu context, đặc biệt với các workflow dài.

Đọc kỹ project-context.md trước khi bắt đầu sprint

Tất cả agent developer tự động nạp project-context.md. Đảm bảo file này luôn cập nhật với:

  • Tech stack và phiên bản chính xác
  • Quy tắc implementation quan trọng
  • Patterns đang dùng trong codebase

Kiến trúc là bắt buộc khi có nhiều developer

Nếu nhiều agent (hoặc developer) làm việc song song trên các stories khác nhau, kiến trúc phải được định nghĩa trước. Thiếu kiến trúc → các agent tạo ra code xung đột nhau.

Dùng bmad-help khi không chắc

bmad-help Tôi đang ở đâu trong workflow?
bmad-help Story này nên dùng Quick Flow hay Dev Story?
bmad-help Implementation Readiness check thất bại, làm gì tiếp?

Quick Flow không có nghĩa là không có chất lượng

Quick Dev vẫn có code review, vẫn tạo spec (mini), vẫn yêu cầu người approve kết quả. "Nhanh" ở đây là bỏ overhead lập kế hoạch không cần thiết, không phải bỏ qua chất lượng.

Customize agent theo nhu cầu team

yaml
# .customize.yaml
agents:
  bmad-agent-dev:
    persona: "Senior developer theo hướng TDD, luôn viết test trước"
    rules:
      - "Mọi function public phải có unit test"
      - "Không dùng any trong TypeScript"

Vị trí QA trong workflow

❌ Sai: Test sau mỗi story ngay lập tức
✅ Đúng: Test sau khi toàn bộ epic hoàn tất (Dev + Code Review cho tất cả stories)

E2E test cần toàn bộ tính năng của epic để test integration. Test sớm hơn sẽ gặp dependency chưa sẵn sàng.


Tài liệu tham khảo

Tài liệuĐường dẫn
Getting Startedtutorials/getting-started.md
Danh sách Agentsreference/agents.md
Workflow Mapreference/workflow-map.md
Testing Referencereference/testing.md
Core Toolsreference/core-tools.md
Modulesreference/modules.md
Dự án đã tồn tạihow-to/established-projects.md
Project Contextexplanation/project-context.md
Quick Devexplanation/quick-dev.md
Why Solutioning Mattersexplanation/why-solutioning-matters.md
Cài đặt BMADhow-to/install-bmad.md

Tài liệu này được tổng hợp từ bản dịch tiếng Việt của BMAD Method Documentation. Cập nhật lần cuối: 2026-04-15.