Phỏng vấn hỏi use case và user story khác nhau thế nào thì bạn trả lời bằng định nghĩa hay bằng một ví dụ, nhiều ứng viên chọn định nghĩa, và câu trả lời của ai nghe cũng giống hệt nhau. Cách thuyết phục hơn là viết cùng một chức năng theo cả hai kiểu, rồi chỉ ra lúc nào kiểu nào giúp dự án đỡ cãi nhau.
hai định nghĩa trong hai câu#
User story là một câu mô tả ngắn nhu cầu của một vai trò, theo mẫu quen thuộc As a [vai trò], I want [điều gì], so that [lợi ích], nó thiên về câu hỏi tại sao. Use case là một đặc tả chi tiết cách một actor tương tác với hệ thống để đạt một mục tiêu, nó thiên về câu hỏi chạy thế nào.
Nói gọn thì user story trả lời cần gì, còn use case trả lời làm sao. BABOK Guide v3 cũng tách chúng thành hai kỹ thuật riêng: Use Cases and Scenarios (10.47) và User Stories (10.48).
cùng một chức năng, hai cách viết#
Lấy ví dụ chức năng hoàn tiền cho đơn trả hàng trên một sàn thương mại điện tử, tình huống giả định thôi, tuần sau đợt sale lớn, nhân viên chăm sóc khách hàng ngồi trước vài trăm yêu cầu hoàn tiền, khách thì nhắn liên tục hỏi “bao giờ tiền về”.
Viết theo user story thì gọn:
“As a nhân viên chăm sóc khách hàng, I want duyệt hoàn tiền cho đơn trả hàng đã được kho xác nhận, so that khách nhận lại tiền nhanh mà không phải chờ kế toán xử lý tay.”
Kèm acceptance criteria:
- Hệ thống chỉ hiển thị các đơn trả hàng mà kho đã xác nhận nhận lại hàng.
- Nhân viên được duyệt hoặc từ chối hoàn tiền, từ chối thì bắt buộc nhập lý do.
- Sau khi duyệt, hệ thống ghi lại người duyệt, thời gian và số tiền hoàn.
Viết theo use case thì dài hơn hẳn, và có cấu trúc cố định:
- Actor: Nhân viên chăm sóc khách hàng.
- Tiền điều kiện: đơn trả hàng đã được kho xác nhận và chưa được hoàn tiền.
- Luồng chính: hệ thống hiển thị danh sách đơn chờ hoàn tiền; nhân viên chọn một đơn; hệ thống hiển thị chi tiết đơn và phương thức thanh toán gốc; nhân viên chọn duyệt; hệ thống tạo lệnh hoàn tiền về phương thức gốc và gửi thông báo cho khách.
- Luồng thay thế: nếu số tiền hoàn vượt ngưỡng (ví dụ 5 triệu đồng), hệ thống chuyển cho trưởng nhóm duyệt thay vì cho phép duyệt ngay.
- Ngoại lệ: nếu cổng thanh toán từ chối lệnh hoàn (thẻ đã hủy, ví đã khóa), hệ thống chuyển đơn sang trạng thái chờ hoàn thủ công và báo cho kế toán.
- Ngoại lệ: nếu đơn đã được nhân viên khác hoàn trước đó, hệ thống báo lỗi và không cho hoàn lần hai.
- Hậu điều kiện: đơn chuyển sang trạng thái đã hoàn tiền, bị từ chối, hoặc chờ hoàn thủ công.
Cùng một việc mà user story chỉ vài dòng, còn use case thì cả chục dòng, đủ các nhánh rẽ và ngoại lệ.
| Tiêu chí | User story | Use case |
|---|---|---|
| Mức chi tiết | Thấp, một câu | Cao, đặc tả đầy đủ luồng |
| Người đọc | Team phát triển, PO | Team phát triển, tester, khách hàng |
| Thời điểm viết | Liên tục trong sprint | Đầu dự án hoặc khi thiết kế chức năng |
| Trả lời | Cần gì, vì sao | Chạy thế nào |
phần so that hay bị viết bừa#
Theo mình chỗ user story hay hỏng nhất không phải là ai hay muốn gì, mà là phần để làm gì, người ta viết đủ vai trò, đủ chức năng, rồi tới vế so that thì điền đại một lợi ích nghe hợp lý, đọc thì xuôi mà thường không đúng ý end user, chỉ là giả định với đoán mò.
Muốn viết đúng vế đó thì không có đường tắt, phải làm elicitation với end user cho tử tế, interview trực tiếp được thì hỏi thật sâu, tại sao anh chị làm như vậy, việc này có ý nghĩa gì với anh chị, còn không interview được, hoặc họ làm quen tay tới mức không giải thích được, thì chuyển sang observation, ngồi xem quy trình làm việc thực tế của họ.
Còn viết sao cho dev đọc cũng hiểu, theo mình vế so that nên nói ra hậu quả cụ thể nếu thiếu chức năng thay vì một lợi ích chung chung. Giả sử một nhân viên kho cần lọc phiếu nhập theo nhà cung cấp, viết “so that làm việc hiệu quả hơn” thì dev đọc xong vẫn không biết nên ưu tiên gì. Viết “so that đối chiếu được phiếu nhập với hóa đơn của từng nhà cung cấp mà không phải dò cả danh sách” thì dev hiểu ngay ai dùng, dùng lúc nào, và tự đoán được bộ lọc cần nhanh tới đâu. Câu “so that” mà đọc xong không trả lời được “thiếu nó thì ai khổ” thì mình coi là chưa xong.
khi nào dùng cái nào#
Chẳng có cái nào tốt hơn tuyệt đối, câu hỏi đúng là dự án của bạn thuộc loại nào. Dự án Agile hoặc product thì user story là chủ đạo, backlog chứa user story, dev nhận story kèm acceptance criteria rồi làm, use case chỉ dùng cho mấy luồng phức tạp, nhiều ngoại lệ, chỗ mà vài dòng acceptance criteria không gánh nổi.
Dự án ERP hoặc outsource cố định phạm vi thì ngược lại, vì hệ thống đã có sẵn nên người ta viết use case hoặc FS cho phần gap, chỗ cần cấu hình hoặc phát triển thêm (cách xác định gap có trong bài Fit-gap analysis ERP). User story vẫn có thể dùng để chia nhỏ việc, nhưng tài liệu chính là đặc tả chi tiết.
Hiểu gọn thì user story dùng khi bạn muốn chia việc nhanh và thay đổi linh hoạt, còn use case dùng khi bạn cần chốt chặt luồng để tránh tranh cãi về sau.
use case diagram, vẽ khi nào là đáng#
Use case diagram là sơ đồ thể hiện các actor và các use case của hệ thống, cùng quan hệ giữa chúng, nó không mô tả chi tiết từng bước mà cho thấy ai dùng được gì và ranh giới hệ thống nằm đâu. Vẽ nó đáng công trong hai trường hợp, một là lúc thống nhất phạm vi, cho khách hàng thấy hệ thống sẽ phục vụ những actor nào, làm được những gì, hai là khi có nhiều actor và quyền khác nhau, cần một bức tranh tổng để không sót.
Còn luồng đơn giản, ít actor thì diagram thường không đáng công vẽ, đừng vẽ cho có.
lỗi hay gặp#
Lỗi đầu tiên là story quá to, gói cả một module thì không còn là story nữa, chẳng ai ước lượng được, story nào cần cả tuần mới xong thì nên chẻ nhỏ.
Lỗi thứ hai là use case viết như hướng dẫn click UI, đặc tả người dùng bấm nút A rồi bấm nút B thì thành hướng dẫn sử dụng mất rồi, use case nên mô tả mục tiêu và luồng nghiệp vụ, không mô tả từng cú click.
Lỗi thứ ba là nhầm mức độ, dùng use case cho mọi thứ trong Agile thì nặng nề, còn chỉ dùng user story duy nhất cho dự án ERP cố định phạm vi thì thiếu chi tiết, đến lúc test lại cãi nhau.
Lỗi thứ tư là bỏ sót luồng ngoại lệ, và đây chính là lý do use case vẫn tồn tại, nó bắt bạn nghĩ tới chuyện người dùng nhập sai, mất kết nối, cổng thanh toán từ chối lệnh hoàn, mấy thứ user story hay bỏ qua.
chọn theo loại dự án#
Đừng chọn use case hay user story như chọn phe, xem dự án của bạn cần gì, linh hoạt thì user story, chốt chặt thì use case. BA giỏi là người dùng được cả hai đúng chỗ.
Muốn viết user story và acceptance criteria cho chuẩn thì đọc User story và acceptance criteria: viết sao cho dev không hỏi lại, còn muốn biết use case nằm ở đâu giữa BRD, SRS và FS thì xem BRD, SRS, FS khác nhau thế nào.
Chỗ bạn đang làm dùng user story hay use case, và có khi nào bị bắt đổi từ cái này sang cái kia không? Kể mình nghe qua Facebook hoặc LinkedIn nhé.
