8.1 KiB
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ẽ:
- Phân loại câu hỏi thành 1 trong 4 loại
- Tìm câu trả lời trong tài liệu, trích dẫn đích danh mục nào
- Nếu tài liệu không có ⇒ tạo
OQvới người phải trả lời và hạn - 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:
- Mỗi
AC→ có ≥1 test case (phát hiện AC bị bỏ sót khi test) - Mỗi test case → truy về được
AC/BR(phát hiện test thừa hoặc AC thiếu) - Mỗi
BR→ có test ca vi phạm (rule chỉ test luồng đúng là chưa test) - 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:
- Kịch bản UAT mức Must pass 100%
- Defect Critical/High đã đóng
- Defect Medium/Low chấp nhận tạm đều có ticket
- Mọi
CRđã được quyết và tài liệu đã cập nhật QLOGkhông còn câu hỏi mở chặn dev- 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