Bạn là Product Owner, cuối sprint dev báo "đã xong", QA test thì rớt, còn stakeholder bảo "không phải cái tôi muốn". Gần như lần nào truy ngược cũng ra cùng một gốc rễ: Acceptance Criteria (AC) viết mơ hồ, thiếu edge case, hoặc không kiểm chứng được. AC là bản hợp đồng ngầm giữa PO, dev và QA. Nếu nó lỏng, mỗi người hiểu một kiểu, và bạn là người gánh hậu quả trong retro.
Khóa học này không dạy bạn lý thuyết AI hay code. Nó dạy bạn dùng AI như một trợ lý viết AC: bạn đưa story, AI trả về bộ Given-When-Then đầy đủ, bạn review và tinh chỉnh. Kết quả: AC chặt hơn, refinement nhanh hơn, bug lọt sprint ít hơn.
AC tốt trông như thế nào
Chúng ta dùng chuẩn Gherkin / BDD — ngôn ngữ tự nhiên có cấu trúc:
Feature: Đăng nhập
Scenario: Đăng nhập thành công
Given người dùng đã có tài khoản với email "an@vd.vn"
When họ nhập đúng email và mật khẩu rồi bấm "Đăng nhập"
Then hệ thống chuyển tới trang Dashboard
And hiển thị lời chào "Xin chào An"
Given = bối cảnh/tiền điều kiện. When = hành động. Then = kết quả kỳ vọng có thể kiểm chứng. Đẹp ở chỗ: QA đọc là viết được test, dev đọc là biết đủ độ "done", stakeholder đọc là hiểu ngay. Cùng một AC phục vụ ba đối tượng mà không cần dịch qua lại — đó là lý do BDD giảm hiểu lầm ngay từ gốc, và cũng là lý do khóa học này chọn Gherkin làm định dạng chuẩn thay vì gạch đầu dòng tự do.
AI mạnh và yếu ở đâu
AI rất giỏi việc liệt kê nhanh các nhánh mà bạn hay quên: giá trị rỗng, quá dài, ký tự đặc biệt, mất mạng giữa chừng, phân quyền, đồng thời (concurrency). Nhưng AI không biết business của bạn — nó không biết "đơn > 50 triệu cần duyệt 2 cấp" trừ khi bạn nói. Vì vậy vai trò của bạn chuyển từ người viết từng dòng sang người biên tập và người gác cổng nghiệp vụ. Đây là một dịch chuyển quan trọng: giá trị của bạn không còn nằm ở tốc độ gõ mà ở khả năng phán đoán nhánh nào đúng với sản phẩm, nhánh nào là ảo giác, và nhánh nào cần hỏi stakeholder. Kỹ năng đó AI không thay được, và cả khóa học này xoay quanh việc mài sắc nó.
Prompt mẫu khởi động
Bạn là BA/QA giàu kinh nghiệm. Viết Acceptance Criteria dạng
Gherkin (Given-When-Then, tiếng Việt) cho user story sau.
Yêu cầu:
- 1 happy path
- Tối thiểu 4 edge/negative case
- Mỗi Then phải kiểm chứng được (không dùng từ mơ hồ như "nhanh", "ổn")
User story: "Là khách hàng, tôi muốn đặt lại mật khẩu qua email
để lấy lại quyền truy cập."
Ràng buộc nghiệp vụ: link reset hết hạn sau 15 phút, chỉ dùng 1 lần.
Các bước áp dụng
- Thu thập story + ràng buộc nghiệp vụ bạn đã biết.
- Đưa vào prompt mẫu, yêu cầu happy path + edge case.
- Đọc output, gạch bỏ cái sai nghiệp vụ, bổ sung cái AI thiếu.
- Chốt lại thành phiên bản dán vào ticket.
- Mang ra refinement để dev/QA phản biện.
Checklist "AC đạt chuẩn"
- [ ] Có ít nhất 1 happy path rõ ràng.
- [ ] Có edge case: rỗng, sai định dạng, hết hạn, phân quyền.
- [ ] Mỗi Then đo được (số, trạng thái, thông báo cụ thể).
- [ ] Không dùng từ mơ hồ (nhanh, dễ, thân thiện).
- [ ] Đã đối chiếu với ràng buộc nghiệp vụ thật.
Sai lầm thường gặp
- Copy nguyên output không đọc. AI có thể ảo giác (hallucination) ra quy tắc nghiệp vụ không có thật, ví dụ tự chế "khóa tài khoản sau 3 lần sai" trong khi hệ thống bạn không có. Luôn kiểm từng dòng.
- Dán thông tin nhạy cảm. Đừng paste dữ liệu khách hàng thật, secret, hay tài liệu nội bộ mật vào công cụ AI công cộng — rủi ro rò rỉ dữ liệu. Dùng dữ liệu giả ("an@vd.vn").
- Phụ thuộc quá mức. Xem AI là bản nháp, không phải chân lý. Bạn vẫn là người chịu trách nhiệm về AC trước team.