186 lines
8.1 KiB
Markdown
186 lines
8.1 KiB
Markdown
# Hướng dẫn sử dụng — `ba-4-delivery-support` (Giai đoạn 4)
|
|
|
|
## Giai đoạn này giải quyết gì
|
|
|
|
Code đang chạy. Việc của BA lúc này là **giữ cho spec và sản phẩm không lệch nhau**: trả lời
|
|
câu hỏi, xử lý thay đổi, đối chiếu test case, điều hành UAT.
|
|
|
|
Đây là giai đoạn chiếm nhiều thời gian thực tế nhất nhưng ít được ghi nhận nhất — vì phần
|
|
lớn công việc là trả lời câu hỏi, và câu trả lời không ghi lại thì mất luôn.
|
|
|
|
## Bốn phần độc lập
|
|
|
|
Skill chia làm bốn phần, gọi phần nào chạy phần đó:
|
|
|
|
| Phần | Việc | Template |
|
|
|---|---|---|
|
|
| **A** | Trả lời câu hỏi làm rõ của dev/QA | `clarification-log.md` |
|
|
| **B** | Quản lý change request | `change-request.md` |
|
|
| **C** | Review test case của QA | `testcase-review.md` |
|
|
| **D** | Chuẩn bị & tổng hợp UAT | `uat-plan.md` |
|
|
|
|
## Cú pháp
|
|
|
|
```
|
|
/ba-4-delivery-support <US-id|PROJECT> [--part a|b|c|d] [--out <path>] [go]
|
|
```
|
|
|
|
Thường thì không cần `--part` — mô tả việc là skill tự nhận ra:
|
|
|
|
```
|
|
/ba-4-delivery-support US011 — dev hỏi field mã cửa hàng có phân biệt hoa thường không
|
|
/ba-4-delivery-support US011 — khách muốn thêm cột ngày cập nhật vào bảng
|
|
/ba-4-delivery-support US011 --part c — QA gửi bộ test case ở link…
|
|
/ba-4-delivery-support Settlement --part d — UAT tuần sau
|
|
```
|
|
|
|
## Phần A — Trả lời câu hỏi dev/QA
|
|
|
|
### Cách dùng
|
|
|
|
Dán câu hỏi của dev vào. Skill sẽ:
|
|
1. Phân loại câu hỏi thành 1 trong 4 loại
|
|
2. Tìm câu trả lời trong tài liệu, trích dẫn đích danh mục nào
|
|
3. Nếu tài liệu không có ⇒ tạo `OQ` với người phải trả lời và hạn
|
|
4. Chỉ ra tài liệu nào cần sửa và báo cho ai
|
|
|
|
### Điều quan trọng nhất
|
|
|
|
**Ba trong bốn loại câu hỏi đều phải sửa tài liệu:**
|
|
|
|
| Loại | Sửa tài liệu? |
|
|
|---|---|
|
|
| 1. Spec đã nói rõ, dev chưa đọc thấy | ❌ Không |
|
|
| 2. Spec mơ hồ, hiểu hai cách | ✅ Bắt buộc |
|
|
| 3. Spec không nói gì | ✅ Bắt buộc |
|
|
| 4. Spec nói sai | ✅ Bắt buộc, qua `CR` |
|
|
|
|
Trả lời cho một dev mà không sửa spec nghĩa là người tiếp theo sẽ hỏi lại đúng câu đó.
|
|
|
|
Skill còn theo dõi **câu hỏi lặp lại**: cùng một câu từ ≥2 người ⇒ tài liệu có vấn đề ở chỗ
|
|
đó, không phải người hỏi có vấn đề.
|
|
|
|
## Phần B — Change Request
|
|
|
|
### Việc đầu tiên: phân loại
|
|
|
|
Đây là phân loại tốn kém nhất khi làm sai, và nó bị làm sai thường xuyên vì cả hai bên đều
|
|
có động cơ: dev muốn gọi là CR, khách muốn gọi là defect.
|
|
|
|
Skill áp dụng phép thử máy móc:
|
|
|
|
```
|
|
Sản phẩm có làm đúng SRS đã ký không?
|
|
├── KHÔNG → DEFECT (dev sửa, không tính phí)
|
|
└── CÓ → Tài liệu có nói về tình huống này không?
|
|
├── CÓ → CHANGE REQUEST
|
|
└── KHÔNG → SPEC GAP ← vùng xám, trách nhiệm của BA
|
|
```
|
|
|
|
**Spec gap** được xử lý thẳng thắn: ghi nhận là thiếu sót của đặc tả, đánh giá tác động như
|
|
CR, nhưng nêu rõ nguyên nhân gốc để lần sau đặc tả kỹ chỗ đó. Không đẩy sang khách như CR
|
|
bình thường, cũng không nhận là bug của dev.
|
|
|
|
### Sáu bước, không bỏ bước
|
|
|
|
Ghi nhận → **làm rõ vấn đề gốc** → đánh giá tác động → trình ≥2 phương án → PO quyết → thực thi.
|
|
|
|
Bước "làm rõ vấn đề gốc" cứu được nhiều tiền nhất. Khách nói *"thêm cột X"* — hỏi *"để làm
|
|
gì?"* — hoá ra để tìm nhanh hơn — hoá ra chỉ cần thêm bộ lọc.
|
|
|
|
## Phần C — Review test case
|
|
|
|
BA **không viết** test case. BA đối chiếu bốn phép:
|
|
|
|
1. Mỗi `AC` → có ≥1 test case *(phát hiện AC bị bỏ sót khi test)*
|
|
2. Mỗi test case → truy về được `AC`/`BR` *(phát hiện test thừa hoặc AC thiếu)*
|
|
3. Mỗi `BR` → có test **ca vi phạm** *(rule chỉ test luồng đúng là chưa test)*
|
|
4. Mỗi dòng bảng dữ liệu biên → có test case
|
|
|
|
Cộng bốn nhóm hay thiếu: phân quyền (gọi thẳng API), lỗi hệ thống (giữ dữ liệu đã nhập),
|
|
đồng thời (hai người sửa một bản ghi), dữ liệu cũ.
|
|
|
|
**Độ phủ AC phải đạt 100% trước khi bắt đầu test.**
|
|
|
|
## Phần D — UAT
|
|
|
|
### Chuẩn bị (trước ít nhất 1 tuần)
|
|
|
|
Năm việc, và mỗi việc có một chỗ hay hỏng:
|
|
|
|
| Việc | Hay hỏng ở đâu |
|
|
|---|---|
|
|
| Kịch bản | Viết theo màn hình ⇒ người dùng không nhận ra công việc của mình |
|
|
| Dữ liệu | Quá sạch ⇒ UAT pass, chạy thật thì lỗi |
|
|
| Môi trường | Ngày UAT mới phát hiện chưa cấp tài khoản |
|
|
| Người tham gia | Người đại diện pass, người dùng thật từ chối |
|
|
| **Tiêu chí pass** | Không chốt trước ⇒ tranh cãi lúc kết luận |
|
|
|
|
### Trong lúc UAT
|
|
|
|
BA là **người quan sát**, không phải người hướng dẫn thao tác. Chỗ người dùng loay hoay là
|
|
thông tin quý nhất — ghi lại trước, hướng dẫn sau.
|
|
|
|
Mỗi phát hiện phân loại ngay thành ba loại: **defect** · **CR** · **hiểu nhầm cách dùng**.
|
|
Loại thứ ba hay bị ghi nhầm thành defect; nó là tín hiệu về đào tạo hoặc thiết kế chưa rõ.
|
|
|
|
## Bạn sẽ nhận được gì
|
|
|
|
```
|
|
ba-output/<PROJECT>/04-delivery/
|
|
├── QLOG_<PROJECT>.md ← cập nhật liên tục, không tạo file mới mỗi lần
|
|
├── CR_<US>-<nnn>_v1.0.md ← mỗi CR một file
|
|
├── TCREVIEW_<US>_v1.0.md
|
|
└── UAT_<đợt phát hành>_v1.0.md
|
|
```
|
|
|
|
Cộng bảng tương ứng phần đã chạy, và **luôn có**: danh sách tài liệu đã sửa kèm version mới,
|
|
và ai cần được báo.
|
|
|
|
## Lỗi thường gặp
|
|
|
|
**"Dev hỏi qua chat, tôi trả lời qua chat, thế là xong."**
|
|
Không xong. Ba tháng sau không ai biết vì sao hệ thống hành xử như vậy — kể cả bạn. Mọi câu
|
|
trả lời phải vào `QLOG`, và nếu spec mơ hồ/thiếu thì phải sửa spec.
|
|
|
|
**"CR này nhỏ thôi, làm luôn cho nhanh."**
|
|
Không có CR nhỏ, chỉ có CR chưa được đánh giá tác động. Thay đổi không ghi nhận sẽ: không
|
|
vào test case ⇒ QA không test ⇒ lỗi lọt ra thật; không vào tài liệu ⇒ người sau đọc thấy
|
|
khác sản phẩm; không vào ước lượng ⇒ trễ tiến độ mà không giải thích được.
|
|
|
|
**"Rõ ràng là nên làm, tôi quyết luôn."**
|
|
Vi phạm nguyên tắc "không quyết định thay PO". Kể cả khi bạn đúng, PO vẫn phải biết vì họ
|
|
chịu trách nhiệm về scope và chi phí.
|
|
|
|
**"Tôi sửa SRS rồi, dev tự đọc lại."**
|
|
Dev đang code theo bản cũ. Sửa spec âm thầm còn tệ hơn không sửa. Danh sách "ai cần được
|
|
báo" là phần bắt buộc của mọi lần sửa.
|
|
|
|
**"Người dùng loay hoay, tôi chỉ luôn cho nhanh."**
|
|
Bạn vừa xoá mất phát hiện quan trọng nhất của buổi UAT. Ghi lại chỗ họ loay hoay, rồi mới
|
|
hướng dẫn.
|
|
|
|
**"Defect Medium này để sau cũng được."**
|
|
Được, nhưng phải có **ticket theo dõi và hạn**. Không có ticket thì nó biến mất và quay lại
|
|
sau sáu tháng dưới dạng khiếu nại.
|
|
|
|
## Ra khỏi giai đoạn này khi nào
|
|
|
|
Đủ cả sáu:
|
|
|
|
1. Kịch bản UAT mức Must pass 100%
|
|
2. Defect Critical/High đã đóng
|
|
3. Defect Medium/Low chấp nhận tạm đều **có ticket**
|
|
4. Mọi `CR` đã được quyết và tài liệu đã cập nhật
|
|
5. `QLOG` không còn câu hỏi mở chặn dev
|
|
6. PO ký nghiệm thu theo tiêu chí đã chốt **trước** buổi UAT
|
|
|
|
Rồi chạy `/ba-5-post-release <PROJECT>`.
|
|
|
|
## Liên quan
|
|
|
|
- Tiêu chí gate G4: `../ba-lifecycle/references/workflow.md` §2
|
|
- Đường quay lui GĐ4 → GĐ3 / GĐ2: `../ba-lifecycle/references/workflow.md` §5
|
|
- Template: `templates/clarification-log.md` · `templates/change-request.md` ·
|
|
`templates/testcase-review.md` · `templates/uat-plan.md`
|