Ba bài trước cho bạn công cụ rời. Bài này ráp thành một quy trình lặp lại được để mỗi story bạn chỉ mất 10–15 phút là có bộ AC chặt, thay vì viết tay 45 phút mà vẫn thiếu.
Quy trình PO-AC 6 bước
- Chuẩn hóa story. Ép về khung "Là [ai], tôi muốn [gì], để [mục tiêu]". Nếu story hiện tại lỏng, nhờ AI viết lại chuẩn trước.
- Bơm ngữ cảnh & ràng buộc. Liệt kê mọi quy tắc nghiệp vụ bạn biết (giới hạn, phân quyền, phụ thuộc). Đây là phần AI không tự biết.
- Sinh happy path. Dùng prompt Bài 2, lấy 1–2 luồng thành công.
- Quét edge case. Dùng prompt 7 nhóm ở Bài 3.
- Biên tập nghiệp vụ. Xóa case sai/bịa, bổ sung case đặc thù, chốt Then đo được. Đánh dấu chỗ cần stakeholder quyết.
- Chốt & dán vào ticket. Kèm ghi chú "AC do AI hỗ trợ, PO đã review".
Prompt mẫu "one-shot" chạy cả quy trình
Thực hiện quy trình 4 phần cho story bên dưới, xuất ra Markdown:
PHẦN 1 — Chuẩn hóa story theo mẫu "Là.../tôi muốn.../để...".
PHẦN 2 — Liệt kê giả định & câu hỏi làm rõ (đừng tự quyết nghiệp vụ).
PHẦN 3 — AC happy path (Gherkin tiếng Việt, Then đo được).
PHẦN 4 — Edge/negative case theo 7 nhóm: dữ liệu biên, định dạng,
trạng thái, phân quyền, mạng/hệ thống, đồng thời, thời gian/giới hạn.
Nhóm không áp dụng thì ghi rõ, không bịa.
Story thô: "Người dùng đổi gói cước từ Free lên Pro."
Ràng buộc đã biết: thanh toán qua thẻ; nâng cấp có hiệu lực ngay;
nếu thẻ lỗi thì giữ nguyên gói Free.
Vì sao quy trình 6 bước tiết kiệm thời gian thật
Viết AC tay cho một story trung bình mất 30–45 phút và vẫn hay thiếu edge case. Quy trình này rút xuống 10–15 phút vì bạn không còn ngồi nghĩ từng nhánh — AI liệt kê, bạn biên tập. Điểm mấu chốt là thứ tự: bước 1–2 (chuẩn hóa + bơm ngữ cảnh) là phần bạn phải làm bằng đầu người vì AI không biết nghiệp vụ; bước 3–4 (sinh) giao cho AI vì nó liệt kê nhanh; bước 5–6 (biên tập + chốt) lại về tay bạn. Đảo thứ tự — ví dụ sinh AC trước khi bơm ràng buộc — là nguyên nhân phổ biến khiến kết quả kém.
Bảng review nhanh sau khi AI trả kết quả
| Kiểm tra | Đạt? |
|---|---|
| Story đã chuẩn hóa rõ mục tiêu | |
| Mọi ràng buộc nghiệp vụ đã phản ánh trong AC | |
| Happy path có Then đo được | |
| Đủ 7 nhóm edge case (hoặc lý do bỏ) | |
| Không có case bịa/không áp dụng | |
| Đã đánh dấu chỗ cần stakeholder quyết |
Các bước làm (tóm tắt thao tác)
- Dán story thô + ràng buộc vào prompt one-shot.
- Đọc PHẦN 2 (câu hỏi làm rõ) trước tiên, trả lời chúng.
- Chạy lại kèm câu trả lời.
- Dùng bảng review nhanh soát PHẦN 3 và 4.
- Biên tập, chốt, dán vào ticket kèm ghi chú nguồn gốc.
Sai lầm thường gặp
- Nhảy thẳng bước 3 (sinh AC) mà bỏ bước 2 (ràng buộc). Không bơm ngữ cảnh thì AI ảo giác nghiệp vụ. Bước 2 là bước quyết định chất lượng.
- Không trả lời câu hỏi làm rõ. Bỏ qua PHẦN 2 nghĩa là để giả định của AI trở thành spec — nguồn gốc của tranh cãi cuối sprint.
- Dán toàn bộ tài liệu nội bộ mật vào tool. Chỉ trích phần cần thiết, ẩn số liệu nhạy cảm để tránh rò rỉ dữ liệu.
- Xem output là bản cuối. Quy trình này cho bản nháp chất lượng cao, không thay thế phán đoán PO và phản biện của dev/QA ở refinement.
- Bỏ ghi chú nguồn gốc. Không đánh dấu "AI hỗ trợ, PO đã review" khiến team không biết mức độ tin cậy của AC. Minh bạch nguồn gốc giúp review đúng mức và tránh phụ thuộc quá mức mà không ai để ý.
Học xong bài này rồi?
Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu,
và học hết khóa thì có chứng chỉ.
Lưu tiến độ của tôi