Hướng dẫn sử dụng — `ba-2-analysis` (Giai đoạn 2)

Giai đoạn này giải quyết gì

Đầu vào là BRIEF đã qua G1 với một danh sách RQ. Đầu ra là mô hình nghiệp vụ mà PO và Dev đọc đều hiểu giống nhau: quy trình chạy thế nào, chia thành những user story nào, quy tắc gì chi phối, ai được làm gì, và việc này đụng vào đâu trong hệ thống đang chạy.

Không làm ở giai đoạn này: vẽ màn hình chi tiết, định nghĩa field (kiểu, độ dài, validation), viết AC Given/When/Then, thiết kế API. Tất cả là GĐ3.

Ranh giới dễ nhớ: GĐ2 trả lời "nghiệp vụ cần gì", GĐ3 trả lời "dev code cái gì".

Khi nào gọi

Tình huống	Có nên gọi
`BRIEF` vừa qua G1, cần phân rã backlog	✅ Chạy đầy đủ
Nhận một US từ khách, cần hiểu nó ảnh hưởng tới đâu	✅ Chạy Bước 5 (`IMPACT`) là chính
Quy tắc nghiệp vụ đang rối, nhiều chỗ mâu thuẫn	✅ Chạy Bước 3 (`BR`) là chính
Cần ma trận phân quyền cho module	✅ Chạy Bước 4 (`RBAC`)
Đã có backlog rồi, chỉ cần viết spec	❌ Sang `ba-3-specification`

Cú pháp

/ba-2-analysis <PROJECT|US-id> [--only process|backlog|br|rbac|impact] [--out <path>] [go]

Tham số	Ý nghĩa
`--only <bước>`	Chỉ chạy một phần. Dùng khi bạn chỉ cần `IMPACT` hoặc chỉ cần `RBAC`
`go`	Bỏ bước dừng xác nhận input

Ví dụ:

/ba-2-analysis Settlement
/ba-2-analysis US059 --only impact
/ba-2-analysis Settlement --only br,rbac

Chuẩn bị gì trước khi gọi

Bắt buộc:

BRIEF với danh sách RQ (từ GĐ1). Chưa có ⇒ skill sẽ cảnh báo và đề nghị quay lại GĐ1

Rất nên có — quyết định chất lượng của PROCESS và IMPACT:

Biên bản quan sát người dùng làm việc thật
Quyền truy cập/ảnh chụp hệ thống hiện tại
Tài liệu hoặc schema DB hiện có
Tên dev/tech lead từng làm module bị ảnh hưởng

Quy trình 5 bước — bạn tham gia ở đâu

Bước	Skill làm	Bạn làm
1. `PROCESS`	Dựng khung AS-IS/TO-BE, đòi cột thời gian, đòi đối chiếu điểm đau	Cung cấp quy trình thật, xác nhận với người dùng
2. `BACKLOG`	Phân rã 3 tầng, chấm INVEST, đối chiếu ngược RQ→US	Chốt MoSCoW với PO, chốt thứ tự
3. `BR`	Gom rule, dựng bảng chuyển trạng thái, dò mâu thuẫn	Hỏi nguồn của từng rule, đưa PO quyết mâu thuẫn
4. `RBAC`	Dựng ma trận, đòi điều kiện cho ô 🔶, đòi SoD	Xác nhận với bảo mật/kiểm toán
5. `IMPACT`	Rà 6 trục, đòi phương án cho dữ liệu cũ	Xác nhận với Tech Lead

Bạn sẽ nhận được gì

ba-output/<PROJECT>/02-analysis/
├── PROCESS_<tên quy trình>_v1.0.md
├── BACKLOG_<PROJECT>_v1.0.md
├── BR_<PROJECT>_v1.0.md
├── RBAC_<PROJECT>_v1.0.md
└── IMPACT_<US|PROJECT>_v1.0.md

Cộng bốn bảng in ra màn hình: đối chiếu RQ→US · tự chấm G2 · checklist W1–W13 · OQ mở.

Bảng đối chiếu RQ→US là thứ đáng đọc nhất. Nó chỉ ra ngay hai loại lỗi:

| RQ     | US phủ           | Trạng thái       |
| RQ-001 | US-001, US-002   | ✅ Đã phủ         |
| RQ-005 | —                | 🔴 CHƯA PHỦ      |   ← yêu cầu bị bỏ quên

US không truy về RQ nào (nghi ngờ scope creep):
| US-018 | Từ đề xuất của dev ở buổi grooming | Chờ PO quyết |

Ví dụ hội thoại

Bạn:    /ba-2-analysis Settlement

Claude: [Bước 0]
        Input:
        | BRIEF_Settlement_v1.0.md | Yêu cầu nghiệp vụ, 12 RQ | v1.0 | ✅ Baselined |
        | PROCESS_… | Chưa có | — | — |

        G1: đã qua (Approved by: chị Lan, 2026-08-25). ✅

        Phạm vi: 12 RQ — chạy một lượt được, không cần chia.

        Để làm IMPACT tôi cần khảo sát:
        - d:/Kakao/fan-platform-admin (màn hình admin hiện có)
        - Schema DB settlement — bạn có tài liệu không?
        Xác nhận giúp tôi.

Bạn:    DB thì hỏi anh Huy. Cứ đọc repo admin trước đi.

Claude: [chạy 5 bước, ghi 5 file, in bảng đối chiếu RQ→US]

        ⚠️ RQ-005 (cảnh báo chênh lệch qua email) chưa có US nào phủ.
        Đây là Should. Bạn muốn tôi thêm US hay ghi DEC hoãn sang phase 2?

Lỗi thường gặp

"AS-IS mất thời gian quá, bỏ được không?" Bỏ được, và bạn sẽ thiết kế một TO-BE thiếu đúng phần ngoại lệ mà người ta xử lý tay mỗi ngày. Nếu thật sự gấp: tối thiểu phải có mục A4 (đường tắt) và A5 (ngoại lệ) — hai mục đó chứa spec ẩn nhiều nhất.

"US của tôi bị chấm INVEST không đạt chữ S, phải tách." Dùng bốn cách tách theo thứ tự: luồng nghiệp vụ (CRUD) → quy tắc (thường/ngoại lệ) → dữ liệu (loại A trước, loại B sau) → vai trò. Đừng tách theo tầng kỹ thuật ("US làm API", "US làm UI") — mỗi US phải giao được một mẩu giá trị chạy được đầu-cuối.

"Ma trận phân quyền của tôi toàn ✅." Nghĩa là chưa phân tích. Hỏi ngược từng hành động: "vai trò nào KHÔNG được làm việc này?" Nếu câu trả lời thật sự là "ai cũng được" thì ghi rõ lý do vào ghi chú.

"Không biết dữ liệu cũ xử lý sao, ghi 'sẽ xử lý sau' được không?" Không. Chọn một trong ba (giữ nguyên / migrate / song song) và ghi lý do. Chưa đủ thông tin để chọn ⇒ ghi OQ với người phải trả lời và hạn — như vậy nó là một việc có chủ, không phải một khoảng trống.

"IMPACT của US này chắc chắn bằng không, cần viết file không?" Có. Ghi "đã rà 6 trục, không phát hiện tác động" kèm phạm vi đã rà. Sáu tháng sau khi có sự cố, dòng đó là bằng chứng đã rà, chứ không phải đã quên.

"Rule tôi viết thẳng trong mô tả US cho tiện." Rồi sáu tháng sau rule đổi, bạn sửa một US và quên ba US khác cũng chứa rule đó. Rule luôn có ID riêng, sống ở BR, US chỉ tham chiếu.

Ra khỏi giai đoạn này khi nào

Đủ cả bốn:

Bảng đối chiếu RQ→US phủ 100% (hoặc RQ chưa phủ đều có DEC hoãn)
Bảng tự chấm G2 toàn ✅
PO và Tech Lead đã điền Approved by
Chạy /ba-traceability <PROJECT> không còn cảnh báo mức 🔴

Rồi chạy /ba-3-specification <US-id>.

Liên quan

Tiêu chí gate G2: ../ba-lifecycle/references/workflow.md §2
Quy tắc viết: ../ba-lifecycle/references/writing-rules.md
Template: templates/process-model.md · templates/user-story-backlog.md · templates/business-rules.md · templates/rbac-matrix.md · templates/impact-analysis.md

7.1 KiB Raw Permalink Blame History Unescape Escape

Hướng dẫn sử dụng — ba-2-analysis (Giai đoạn 2)