Viết yêu cầu và acceptance criteria

Vì sao yêu cầu mơ hồ đắt hơn mọi thứ khác

Dev nhận một thẻ ghi "làm màn hình danh sách đơn hàng". Bạn ấy làm hai ngày. Đưa ra xem, chủ sản phẩm nói "thiếu bộ lọc theo trạng thái, và phải sắp theo ngày gần nhất". Hai ngày mất. Không phải vì dev kém, mà vì thông tin đó nằm trong đầu một người và không được viết ra.

Viết yêu cầu kỹ mất thêm 30 phút. Yêu cầu mơ hồ mất vài ngày, và làm hỏng niềm tin giữa hai bên.

Definition of Ready

Hạng mục chỉ được đưa vào sprint khi thoả toàn bộ:

Nêu được vấn đề của người dùng, không phải mô tả giải pháp kỹ thuật.
Có acceptance criteria, mỗi tiêu chí kiểm chứng được bằng quan sát.
Ghi rõ phần nằm ngoài phạm vi của hạng mục này.
Xác định module nào sở hữu, có chạm ranh giới module khác không.
Có thiết kế hoặc mô tả giao diện nếu là việc có màn hình.
Nêu các trường hợp biên đã biết: rỗng, lỗi, mạng chậm, quyền không đủ.
Đủ nhỏ để một người làm xong trong tối đa ba ngày. Lớn hơn thì chẻ ra.

Thiếu bất kỳ mục nào thì hạng mục quay lại chặng làm rõ. Đây là quality gate của chủ sản phẩm, và nó tiết kiệm nhiều thời gian hơn mọi quality gate kỹ thuật cộng lại.

Mẫu một hạng mục

# Lọc đơn hàng theo trạng thái

## Vấn đề
Nhân viên bán hàng mở danh sách đơn thấy tất cả đơn trộn lẫn. Để tìm đơn
chưa giao, họ phải cuộn và đọc từng dòng. Với hơn 200 đơn một ngày,
việc này mất khoảng 10 phút mỗi lần và hay bỏ sót.

## Người dùng và bối cảnh
Nhân viên bán hàng, dùng trên điện thoại, thường lúc đang di chuyển,
mạng không ổn định.

## Acceptance criteria
1. Trên màn hình danh sách đơn có bộ lọc theo trạng thái: tất cả, chờ xác
   nhận, đang giao, hoàn tất, đã huỷ.
2. Chọn một trạng thái thì danh sách chỉ còn đơn thuộc trạng thái đó, và
   số lượng hiển thị đúng với số đơn thực tế.
3. Lựa chọn lọc được giữ lại khi rời màn hình rồi quay lại trong cùng phiên.
4. Khi không có đơn nào khớp, hiển thị trạng thái rỗng có chữ, không phải
   màn hình trắng.
5. Khi mất mạng, bộ lọc vẫn hoạt động trên dữ liệu đã tải về.
6. Thao tác lọc cho kết quả trong vòng 300 mili giây với 500 đơn.

## Ngoài phạm vi
- Lọc theo khoảng ngày.
- Lọc theo nhân viên phụ trách.
- Lưu bộ lọc giữa các lần đăng nhập.

## Trường hợp biên
- Tài khoản không có quyền xem đơn của người khác.
- Đơn có trạng thái lạ do dữ liệu cũ.
- Danh sách rỗng ngay từ đầu.

Acceptance criteria viết thế nào cho đúng

Một tiêu chí tốt phải kiểm chứng được bằng quan sát, và hai người đọc cho ra cùng kết luận.

Viết sai	Vì sao sai	Viết đúng
Màn hình phải nhanh	Nhanh là bao nhiêu?	Danh sách hiện trong 300 ms với 500 bản ghi
Xử lý lỗi tốt	Tốt theo ai?	Mất mạng thì hiện thông báo kèm nút thử lại, dữ liệu đã tải vẫn xem được
Giao diện đẹp, dễ dùng	Không đo được	Theo bản thiết kế đã duyệt, khoảng cách và cỡ chữ đúng hệ thống thiết kế
Không có lỗi	Không ai chứng minh được	Các luồng ở mục tiêu chí đều chạy đúng trên máy thật, có test tự động che

Mẹo kiểm tra: đọc tiêu chí lên và hỏi "tester có thể biến câu này thành một bước test không?". Không được thì viết lại.

Chẻ hạng mục lớn

Hạng mục quá ba ngày công thì chẻ. Cách chẻ tốt là chẻ theo giá trị, không chẻ theo tầng kỹ thuật.

Cách chẻ	Ví dụ	Đánh giá
Theo tầng	"Làm API", "Làm giao diện", "Nối hai thứ"	Xấu — không mảnh nào dùng được một mình, tới mảnh cuối mới biết sai
Theo luồng	"Lọc theo trạng thái", "Lọc theo ngày", "Nhớ lựa chọn"	Tốt — mỗi mảnh xong là người dùng dùng được
Theo trường hợp	"Luồng thành công", "Xử lý lỗi mạng", "Trạng thái rỗng"	Tốt — ưu tiên được, phần sau không chặn phần trước

Ai viết yêu cầu

Chủ sản phẩm viết phần vấn đề, acceptance criteria, phạm vi. Chủ kỹ thuật bổ sung ràng buộc kỹ thuật và trường hợp biên. Dev được quyền từ chối nhận việc chưa đạt Định nghĩa Sẵn sàng — đây không phải là làm khó, đây là chặn lãng phí ngay từ đầu.

Nếu dev thường xuyên phải từ chối, đó là tín hiệu buổi chuẩn bị hạng mục đang làm hời hợt. Nêu trong buổi cải tiến.