This commit is contained in:
Leonard-ThindPad-P50
2026-09-08 10:26:21 +07:00
commit c81f249920
169 changed files with 38726 additions and 0 deletions

View File

@@ -0,0 +1,160 @@
# 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:
1. Bảng đối chiếu `RQ`→`US` phủ 100% (hoặc RQ chưa phủ đều có `DEC` hoãn)
2. Bảng tự chấm G2 toàn ✅
3. PO **và** Tech Lead đã điền `Approved by`
4. 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`