​
Quy trình làm việc

Quy trình phát triển sản phẩm tại PrimeCommerce theo mô hình GitHub Flow, phối hợp 5 vai trò: PM, Design, Dev, QA, DevOps.
Quy tắc bắt buộc:
  • Không code UI khi chưa có Design specs — Dev phải đợi Design hoàn thành UI specs/mockups
  • Không deploy khi chưa qua QA — QA phải sign-off trước khi merge staging → main
  • Mọi PR cần 1 approval + CI pass — không merge thẳng, không skip review

​
Tổng quan luồng công việc

​
Sprint 1 tuần

1

Sprint Planning — Thứ Hai

Ai: PM Làm gì:
  • Tạo tickets trên GitHub Projects
  • Assign issues cho dev
  • Ưu tiên backlog
  • Review PRD với Design team để align UI requirements
Công cụ:
/sprint-plan
/prd "mô tả tính năng"
/docs-project:full "feature"    # PRD → UI Specs → QA Plan
2

UI/UX Design — Thứ Hai đến Thứ Ba

Ai: Design Làm gì:
  • Đọc PRD, tạo UI specs và mockups
  • Design trong Figma hoặc generate với AI tools
  • Review với PM — confirm đúng requirements
  • Handoff cho Dev — share Figma link + component specs
Công cụ:
/design:good "mô tả screen"     # Generate design chất lượng cao
/design:screenshot               # Design từ screenshot reference
/figma:figma-generate-design     # Generate design trong Figma
/figma:figma-implement-design    # Figma → code
/docs-project:ui                 # Tạo UI Design Specs từ PRD
Handoff checklist Design → Dev:
  • Figma link với đầy đủ screens + states (hover, active, error, empty)
  • Component specs (spacing, colors, typography)
  • Responsive breakpoints (mobile, tablet, desktop)
  • Interaction specs (animations, transitions)
3

Development — Thứ Ba đến Thứ Năm

Ai: Dev Làm gì:
  • Tạo branch feat/FXX-YY-mo-ta
  • Code theo Design specs + PRD
  • Viết tests (unit + integration)
  • Tạo PR vào staging
Công cụ:
/plan "mô tả tính năng"
/cook                            # Implement theo plan
/fix:test                        # Fix failing tests
/fix:ui                          # Fix UI issues theo design
4

Code Review — Trong 4 giờ sau PR

Ai: Dev (reviewer) + Design (visual review nếu có UI) Làm gì:
  • Dev: Review correctness, security, performance
  • Design: Review UI match với mockups (cho PR có UI changes)
  • Approve hoặc request changes
Công cụ:
/code-review
/review #PR-number
5

QA Testing — Sau merge vào staging

Ai: QA Làm gì:
  • Verify từng issue trên staging
  • Kiểm tra UI match design (responsive, interactions, edge states)
  • Gán label qa:passed hoặc qa:failed
  • Báo cáo bug nếu có
Công cụ:
/qa-full:verify-issue #66
/qa-full:check
/qa-full:accept docs/prd/F05.md
/qa-full a11y https://staging...  # Accessibility check
6

Sprint Demo — Thứ Sáu

Ai: PM + Dev + Design Làm gì:
  • Demo trên staging cho stakeholders
  • Design confirm UI quality
  • Thu thập feedback
7

Release — Sau QA sign-off

Ai: DevOps Làm gì:
  • Merge staging vào main
  • Deploy production
  • Monitor sau deploy
Công cụ:
/deploy-checklist
/health-check

​
Quy trình QA theo sprint

# Đầu sprint:
/qa-full:audit                    # Xem tình trạng dự án

# Trong sprint (mỗi ngày):
/qa-full:verify-issue #N          # Verify issues được assign

# Cuối sprint:
/qa-full:check                    # Bổ sung tests thiếu
/qa-full:full --skip-gen          # Chạy full QA
/qa-full:accept docs/prd/F*.md    # Nghiệm thu theo PRD

# Trước release:
/qa-full:full                     # Full QA
/qa-full e2e https://staging...   # E2E
/qa-full security                 # Bảo mật

​
Daily Standup

Hàng ngày qua Lark, trả lời 3 câu hỏi:
  1. Hôm qua làm gì?
  2. Hôm nay sẽ làm gì?
  3. Có blocker nào?
Công cụ: 
/daily-standup

​
Git Flow

git checkout staging
git pull origin staging
git checkout -b feat/F01-01-generate-site
# ... code ...
git push -u origin feat/F01-01-generate-site
# Tạo PR vào staging

​
Handoff giữa các team

5 điểm handoff quan trọng — mỗi điểm cần output rõ ràng, không assume.
#HandoffTừ → ĐếnOutput bắt buộc
1PRD → DesignPM → DesignPRD với Acceptance Criteria + wireframes (nếu có)
2Design → DevDesign → DevFigma link + component specs + responsive breakpoints
3Code → QADev → QAPush staging + comment “ready for QA” + list files changed
4Bug → DevQA → DevBug report: steps to reproduce + expected vs actual + screenshots
5Release → OpsDev → DevOpsPR staging→main + QA sign-off + deploy checklist

​
Best Practices phối hợp cross-team

Sprint planning tips:
  • PM: Không assign quá 80% capacity → dành 20% cho bugs + tech debt
  • Design: Làm specs sớm (T2-T3) để Dev có specs code từ T3
  • Dev: Estimate thêm 30% buffer cho review + QA feedback
  • QC: Plan verify time song song với dev timeline, không đợi cuối sprint
Communication rules:
  • Dùng GitHub issues/PRs làm nguồn chính, Lark chỉ để chat nhanh
  • Design feedback qua Figma comments, không qua chat
  • Blocker phải escalate trong 2 giờ, không đợi standup ngày hôm sau
→ Xem thêm: Best Practices tổng hợp

​
Ma trận trách nhiệm (RACI)

Hoạt độngPMDesignDevQADevOps
PRDRCCCI
UI/UX DesignCRCII
Sprint PlanningRCCCI
CodeIIRII
Code ReviewICRII
Visual ReviewIRCCI
QA TestingICCRI
DeployIIICR
MonitoringIICIR
R = Responsible, C = Consulted, I = Informed