Cách viết user story và tiêu chí chấp nhận Given - When - Then cho BA
Mục lục (8 phần)
Bài viết do đội ngũ biên tập Vietdemy biên soạn từ khoá học Phân tích nghiệp vụ (Business Analyst) thực chiến: từ yêu cầu đến UAT của Hoàng Phương Thảo.
Đội phát triển làm việc theo sprint hai tuần không đọc tài liệu yêu cầu dài hàng chục trang. Họ kéo từng hạng mục nhỏ từ backlog, và mỗi hạng mục đó thường là một user story kèm tiêu chí chấp nhận. Viết story mơ hồ, đội sẽ làm theo cách họ hiểu; viết tiêu chí thiếu, đến lúc kiểm thử mới vỡ lẽ "không phải ý tôi". Bài viết này hướng dẫn cách viết user story và tiêu chí chấp nhận Given - When - Then dành cho Business Analyst (BA) mới vào nghề.
Nếu bạn chưa rõ BA làm những việc gì và viết những tài liệu nào, hãy đọc trước bài Business Analyst (BA) là gì.
User story là gì?
User story là một mô tả ngắn về một nhu cầu, viết từ góc nhìn người dùng. Mẫu câu phổ biến có ba phần:
Là [ai], tôi muốn [làm được gì] để [đạt giá trị gì].
- "Là"phải là một nhóm người dùng cụ thể: "bệnh nhân đặt lịch lần đầu", "lễ tân phòng khám", không phải "người dùng" chung chung, càng không phải "hệ thống".
- "Tôi muốn"là nhu cầu, không phải thiết kế: "biết ngay khung giờ còn trống", không phải "thấy ô màu xanh".
- "Để"là lý do. Phần này hay bị bỏ, nhưng nó giúp đội chọn cách làm đúng khi gặp lựa chọn và giúp Product Owner (PO) xếp ưu tiên.
Ví dụ (tình huống minh hoạ)
Một phòng khám làm ứng dụng đặt lịch khám. Story tốt: Là bệnh nhân đặt lịch lần đầu, tôi muốn thấy các khung giờ còn trống của bác sĩ trong 7 ngày tới để chọn được giờ phù hợp mà không phải gọi điện.
Story chưa tốt: Là người dùng, tôi muốn có màn hình lịch đẹp, dễ dùng. Không rõ ai, không rõ nhu cầu, không rõ giá trị, và "đẹp, dễ dùng" không kiểm thử được.
Tiêu chí chấp nhận Given - When - Then
Story nói cái gì và vì sao; tiêu chí chấp nhận nói thế nào là xong. Dạng phổ biến là Given - When - Then (tiếng Việt: Cho trước - Khi - Thì):
- Cho trướcbối cảnh, trạng thái ban đầu.
- Khihành động hoặc sự kiện xảy ra.
- Thìkết quả quan sát được.
Với story đặt lịch ở trên, có thể viết:
- Cho trướcbác sĩ A còn 3 khung giờ trống ngày mai, khi bệnh nhân mở lịch của bác sĩ A, thì ứng dụng hiển thị đúng 3 khung giờ đó, sắp theo thời gian.
- Cho trướcbác sĩ A kín lịch cả 7 ngày tới, khi bệnh nhân mở lịch, thì ứng dụng báo "Bác sĩ đã kín lịch 7 ngày tới" và gợi ý bác sĩ cùng chuyên khoa còn trống.
- Cho trướcmột khung giờ vừa được người khác đặt, khi bệnh nhân bấm chọn khung đó, thì ứng dụng báo khung giờ không còn trống và tải lại danh sách trong vòng 2 giây.
Quy tắc viết tiêu chí chấp nhận
- Viết 3 đến 6 tiêu chí cho một story. Ít hơn thường là thiếu ca lỗi; nhiều hơn thường là story quá to, nên cắt.
- Luôn có ít nhất một ca thành công và một ca lỗi hoặc trường hợp biên.
- Phần "Thì" phải quan sát được: thông báo gì, trạng thái nào, trong bao lâu.
- Viết trước khi đội bắt đầu làm, được PO đồng ý và được người kiểm thử đọc.
Kiểm nhanh story bằng INVEST
Một danh sách kiểm phổ biến trong cộng đồng Agile là INVEST. Story tốt nên:
| Chữ cái | Ý nghĩa | Câu hỏi tự kiểm |
|---|---|---|
| I - Independent | Độc lập | Story có phụ thuộc quá nhiều vào story khác không? |
| N - Negotiable | Thương lượng được | Chi tiết còn bàn được với đội không? |
| V - Valuable | Có giá trị | Người dùng nhận được gì khi story xong? |
| E - Estimable | Ước lượng được | Đội có đủ thông tin để ước lượng không? |
| S - Small | Nhỏ | Có làm xong trong một sprint không? |
| T - Testable | Kiểm thử được | Có tiêu chí chấp nhận rõ ràng không? |
Cắt story từ một yêu cầu lớn
Một yêu cầu như "Bệnh nhân đặt, đổi và huỷ lịch khám, nhận nhắc lịch" quá to cho một story. Hãy cắt theo lát dọc: mỗi story vẫn đem lại một phần giá trị hoàn chỉnh từ giao diện đến dữ liệu.
- US-01: Bệnh nhân xem khung giờ trống của bác sĩ trong 7 ngày tới.
- US-02: Bệnh nhân đặt một khung giờ và nhận mã xác nhận.
- US-03: Bệnh nhân huỷ lịch trước giờ khám ít nhất 2 tiếng.
- US-04: Bệnh nhân nhận tin nhắc lịch trước giờ khám.
Không cắt theo lớp kỹ thuật như "làm API", "làm giao diện", "làm cơ sở dữ liệu", vì từng phần đó không đem lại giá trị khi đứng một mình.
Story sống cùng tài liệu yêu cầu thế nào?
User story không thay hoàn toàn tài liệu yêu cầu nghiệp vụ (BRD). Trong thực tế:
- Mỗi story ghi mã yêu cầu nó phục vụ, và yêu cầu đó gắn với một mục tiêu kinh doanh. Chuỗi truy vết này giúp trả lời "vì sao làm story này".
- Quy tắc nghiệp vụ (ví dụ "chỉ được huỷ trước giờ khám 2 tiếng") được ghi một lần ở danh sách quy tắc; story chỉ tham chiếu, không chép lại.
- Yêu cầu phi chức năng chung như bảo mật, hiệu năng thường đưa vào Definition of Done của đội thay vì lặp lại trong từng story.
Những lỗi BA mới hay mắc
| Lỗi | Cách sửa |
|---|---|
| Vai "người dùng" hoặc "hệ thống" | Gọi tên nhóm người dùng cụ thể |
| Viết giải pháp thay cho nhu cầu | Hỏi "để làm gì?" cho đến khi ra nhu cầu thật |
| Bỏ phần "để" | Luôn ghi giá trị; không ghi được thì xem lại story có cần không |
| Tiêu chí chỉ có ca thành công | Thêm ít nhất một ca lỗi hoặc ca biên |
| Dùng từ không đo được: nhanh, dễ dùng, thân thiện | Thay bằng con số hoặc kết quả quan sát được |
Checklist trước khi đưa story vào sprint
- Câu story đủ ba phần, vai cụ thể, nhu cầu không phải thiết kế.
- Có 3-6 tiêu chí chấp nhận, có ca lỗi, phần "Thì" quan sát được.
- Đã ghi mã yêu cầu và quy tắc nghiệp vụ liên quan.
- PO đã đồng ý, người kiểm thử đã đọc và không còn câu hỏi.
- Đủ nhỏ để làm xong trong một sprint.
Câu hỏi thường gặp
User story và use case khác nhau thế nào?
Use case mô tả chi tiết các bước tương tác giữa một tác nhân và hệ thống, gồm luồng chính, luồng thay thế, ngoại lệ. User story ngắn hơn, tập trung vào nhu cầu và giá trị, chi tiết được làm rõ qua tiêu chí chấp nhận và trao đổi với đội. Nhiều dự án dùng cả hai.
Ai viết user story?
Thường là PO hoặc BA, nhưng story tốt được hoàn thiện qua trao đổi với đội phát triển và người kiểm thử. BA thường giữ vai trò đảm bảo story truy được về yêu cầu và mục tiêu.
Tiêu chí chấp nhận có bắt buộc theo dạng Given - When - Then không?
Không bắt buộc. Một số đội viết dạng danh sách kiểm. Given - When - Then được dùng nhiều vì mỗi tiêu chí là một kịch bản kiểm thử nhỏ, dễ chuyển thành ca kiểm thử.
Một story nên có bao nhiêu tiêu chí chấp nhận?
Thường 3 đến 6. Quá 6 tiêu chí là dấu hiệu story nên được cắt nhỏ hơn.
Ví dụ phòng khám trong bài là tình huống minh hoạ do Vietdemy tự soạn.
