增強的 IDE 開發工作流程

Enhanced IDE Development Workflow

This is a simple step-by-step guide to help you efficiently manage your development workflow using the BMad Method. The workflow integrates the Test Architect (QA agent) throughout the development lifecycle to ensure quality, prevent regressions, and maintain high standards. Refer to the User Guide for any scenario that is not covered here.
這是一份簡單的逐步指南，幫助你使用 BMad Method 有效率地管理開發工作流程。該工作流程在整個開發生命週期中整合了測試架構師（QA 代理），以確保品質、預防回歸並維持高標準。如遇本指南未涵蓋的情況，請參考使用者指南。

Create New Branch  建立新分支

1. Start new branch  啟動新分支

Story Creation (Scrum Master)
任務建立（Scrum Master）

1. Start new chat/conversation
   開始新的聊天/對話
2. Load SM agent  載入 SM 代理
3. Execute: *draft (runs create-next-story task)
   執行： *draft （執行 create-next-story 任務）
4. Review generated story in docs/stories/
   審閱在 docs/stories/ 中產生的故事
5. Update status: Change from "Draft" to "Approved"
   更新狀態：從「草稿」改為「已核准」

Story Implementation (Developer)
故事實作（開發者）

1. Start new chat/conversation
   開始新的聊天/對話
2. Load Dev agent  載入開發代理
3. Execute: *develop-story {selected-story} (runs execute-checklist task)
   執行： *develop-story {selected-story} （執行 execute-checklist 任務）
4. Review generated report in {selected-story}
   在 {selected-story} 檢視生成的報告

Test Architect Integration Throughout Workflow
在整個工作流程中測試 Architect 的整合

The Test Architect (Quinn) provides comprehensive quality assurance throughout the development lifecycle. Here's how to leverage each capability at the right time.
測試 Architect（Quinn）在整個開發生命週期中提供全面的品質保證。以下說明如何在適當的時機善用各項功能。

Command Aliases: Documentation uses short forms (*risk, *design, *nfr, *trace) for the full commands (*risk-profile, *test-design, *nfr-assess, *trace-requirements).
命令別名：文件中使用簡寫（ *risk 、 *design 、 *nfr 、 *trace ）來代表完整命令（ *risk-profile 、 *test-design 、 *nfr-assess 、 *trace-requirements ）。

Quick Command Reference  快速命令參考

Stage 1: After Story Creation (Before Dev Starts)
階段 1：故事建立後（開發開始前）

RECOMMENDED - Set Developer Up for Success:
建議 — 讓開發者能順利開始：

# 1. RISK ASSESSMENT (Run FIRST for complex stories)
@qa *risk {approved-story}
# Identifies:
# - Technical debt impact
# - Integration complexity
# - Regression potential (1-9 scoring)
# - Mitigation strategies
# Critical for: Brownfield, API changes, data migrations

# 2. TEST DESIGN (Run SECOND to guide implementation)
@qa *design {approved-story}
# Provides:
# - Test scenarios per acceptance criterion
# - Test level recommendations (unit/integration/E2E)
# - Risk-based priorities (P0/P1/P2)
# - Test data requirements
# Share with Dev: Include in story comments or attach to ticket

Stage 2: During Development (Mid-Implementation Checkpoints)
階段 2：開發中（實作中期檢查點）

Developer Self-Service Quality Checks:
開發者自助品質檢查：

# 3. REQUIREMENTS TRACING (Verify coverage mid-development)
@qa *trace {story-in-progress}
# Validates:
# - All acceptance criteria have tests
# - No missing test scenarios
# - Appropriate test levels
# - Given-When-Then documentation clarity
# Run when: After writing initial tests

# 4. NFR VALIDATION (Check quality attributes)
@qa *nfr {story-in-progress}
# Assesses:
# - Security: Authentication, authorization, data protection
# - Performance: Response times, resource usage
# - Reliability: Error handling, recovery
# - Maintainability: Code quality, documentation
# Run when: Before marking "Ready for Review"

Stage 3: Story Review (Quality Gate Assessment)
階段 3：故事審查（品質閘門評估）

REQUIRED - Comprehensive Test Architecture Review:
必要 — 全面測試架構審查：

Prerequisite: All tests green locally; lint & type checks pass.
先決條件：所有測試在本地均通過；程式碼風格及型別檢查通過。

# 5. FULL REVIEW (Standard review process)
@qa *review {completed-story}

What Happens During Review:
審查期間的流程：

1. Deep Code Analysis  深入程式碼分析
   • Architecture pattern compliance
     架構模式符合性
   • Code quality and maintainability
     程式碼品質與可維護性
   • Security vulnerability scanning
     安全性漏洞掃描
   • Performance bottleneck detection
     效能瓶頸偵測
2. Active Refactoring  主動重構
   • Improves code directly when safe
     在安全時直接改善程式碼
   • Fixes obvious issues immediately
     立即修正明顯問題
   • Suggests complex refactoring for dev
     為開發者建議複雜的重構
3. Test Validation  測試驗證
   • Coverage at all levels (unit/integration/E2E)
     涵蓋所有層級（單元/整合/端到端）
   • Test quality (no flaky tests, proper assertions)
     測試品質（無易碎測試、適當的斷言）
   • Regression test adequacy
     迴歸測試的充分性
4. Gate Decision  閘門決策
   • Creates: docs/qa/gates/{epic}.{story}-{slug}.yml  建立： docs/qa/gates/{epic}.{story}-{slug}.yml
   • Adds: QA Results section to story file
     新增：QA 結果段落到故事檔案
   • Status: PASS/CONCERNS/FAIL/WAIVED
     狀態：通過/有疑慮/失敗/豁免

Stage 4: Post-Review (After Addressing Issues)
階段 4：審查後（在解決問題之後）

Update Gate Status After Fixes:
修復後更新閘門狀態

# 6. GATE UPDATE (Document final decision)
@qa *gate {reviewed-story}
# Updates: Quality gate with new status
# Use when: After addressing review feedback
# Documents: What was fixed, what was waived

Understanding Gate Decisions
瞭解關卡決策

Risk-Based Testing Strategy
以風險為基礎的測試策略

The Test Architect uses risk scoring to prioritize testing:
測試架構師使用風險評分來優先排序測試：

Special Situations & Best Practices
特殊情況與最佳實務

High-Risk or Brownfield Stories
高風險或複雜既有系統案例

# ALWAYS run this sequence:
@qa *risk {story} # First - identify dangers
@qa *design {story} # Second - plan defense
# Then during dev:
@qa *trace {story} # Verify regression coverage
@qa *nfr {story} # Check performance impact
# Finally:
@qa *review {story} # Deep integration analysis

Complex Integrations  複雜整合

• Run *trace multiple times during development
  在開發期間多次執行 *trace
• Focus on integration test coverage
  專注於整合測試覆蓋率
• Use *nfr to validate cross-system performance
  使用 *nfr 驗證跨系統效能
• Review with extra attention to API contracts
  特別注意 API 合約的審查

Performance-Critical Features
對效能關鍵功能

• Run *nfr early and often (not just at review)
  及早且經常執行 *nfr （不僅在審查時）
• Establish performance baselines before changes
  在變更前建立效能基準
• Document acceptable performance degradation
  文件可接受的效能退化
• Consider load testing requirements in *design
  在 *design 中考慮負載測試需求

Test Quality Standards Enforced
執行的測試品質標準

Quinn ensures all tests meet these standards:
Quinn 確保所有測試符合這些標準：

• No Flaky Tests: Proper async handling, explicit waits
  沒有不穩定的測試：正確處理非同步，使用明確的等待
• No Hard Waits: Dynamic strategies only (polling, events)
  不要使用固定等待：僅採用動態策略（輪詢、事件）
• Stateless: Tests run independently and in parallel
  無狀態：測試可獨立且並行執行
• Self-Cleaning: Tests manage their own test data
  自我清理：測試自行管理其測試資料
• Appropriate Levels: Unit for logic, integration for interactions, E2E for journeys
  適當等級：邏輯用單元測試、互動用整合測試、流程用端對端測試
• Clear Assertions: Keep assertions in tests, not buried in helpers
  清晰的斷言：把斷言放在測試中，而不是埋在輔助函式裡

Documentation & Audit Trail
文件與稽核記錄

All Test Architect activities create permanent records:
所有測試架構師活動都會建立永久紀錄：

• Assessment Reports: Timestamped analysis in docs/qa/assessments/
  評估報告：在 docs/qa/assessments/ 中帶時間戳記的分析
• Gate Files: Decision records in docs/qa/gates/
  門檔案：位於 docs/qa/gates/ 的決策紀錄
• Story Updates: QA Results sections in story files
  故事更新：故事檔案中的 QA 結果區段
• Traceability: Requirements to test mapping maintained
  可追溯性：維護需求到測試的對應關係

Commit Changes and Push  提交變更並推送

1. Commit changes  提交變更
2. Push to remote  推送到遠端

Complete Development Cycle Flow
完整開發週期流程

The Full Workflow with Test Architect
包含測試架構師的完整工作流程

1. SM: Create next story → Review → Approve
   SM：建立下一個故事 → 審查 → 核准
2. QA (Optional): Risk assessment (*risk) → Test design (*design)
   QA（選填）：風險評估（ *risk ）→ 測試設計（ *design ）
3. Dev: Implement story → Write tests → Complete
   Dev：實作故事 → 撰寫測試 → 完成
4. QA (Optional): Mid-dev checks (*trace, *nfr)
   QA（選填）：開發中檢查（ *trace ， *nfr ）
5. Dev: Mark Ready for Review
   開發：標記為準備審查
6. QA (Required): Review story (*review) → Gate decision
   品質保證（必需）：審查故事（ *review ）→ 門檻決策
7. Dev (If needed): Address issues
   開發（如需）：處理問題
8. QA (If needed): Update gate (*gate)
   品質保證（如需）：更新門檻（ *gate ）
9. Commit: All changes  提交：所有變更
10. Push: To remote  推送：到遠端
11. Continue: Until all features implemented
    繼續：直到所有功能實作完成

Quick Decision Guide  快速決策指南

Should I run Test Architect commands?
我應該執行 Test Architect 指令嗎？

Success Metrics  成功指標

The Test Architect helps achieve:
測試架構師協助達成：

• Zero regression defects in production
  生產環境零回歸缺陷
• 100% requirements coverage with tests
  以測試達成 100% 需求覆蓋
• Clear quality gates for go/no-go decisions
  明確的品質門檻以作出通過/不通過決策
• Documented risk acceptance for technical debt
  已記錄的技術債風險接受情形
• Consistent test quality across the team
  團隊內一致的測試品質
• Shift-left testing with early risk identification
  提早進行測試（shift-left），及早識別風險