Thuật ngữ
User story là gì? Cách viết kèm tiêu chí chấp nhận
User story là yêu cầu viết từ góc nhìn người dùng: là ai, muốn gì, để làm gì. Cách viết, tiêu chí chấp nhận kiểm tra được, INVEST, khi nào dùng Task thay vì Story.
Khoảng 6 phút đọc
Trả lời ngắn
Định nghĩaUser story là cách viết một yêu cầu ngắn gọn từ góc nhìn người dùng, theo mẫu “Là ai, tôi muốn điều gì, để được lợi gì”. Đi kèm luôn là tiêu chí chấp nhận: vài điều kiện kiểm tra được, để cả đội và người dùng cùng biết khi nào story đã xong.
Story không phải tài liệu đặc tả. Nó là lời nhắc để đội và người dùng nói chuyện với nhau trước khi làm; chi tiết được làm rõ trong cuộc nói chuyện đó và ghi vào tiêu chí chấp nhận. Vì thế một story tốt vừa đủ ngắn để đọc trong mười giây, vừa đủ rõ để kiểm thử.
Ba phần của một story
| Phần | Trả lời câu hỏi | Ví dụ |
|---|---|---|
| Là ai | Ai dùng tính năng này? Vai trò cụ thể, không phải “người dùng”. | Là cán bộ phòng Khảo thí |
| Tôi muốn | Họ cần làm được gì? Một hành động, không phải một màn hình. | tôi muốn xếp lịch thi tự động theo phòng |
| Để | Vì sao? Lợi ích thật; nếu không viết được thì story có thể không cần làm. | để không phải xếp tay và tránh trùng giảng viên coi thi |
Phần “để” hay bị bỏ qua nhất nhưng quan trọng nhất: nó cho đội hiểu mục đích để tìm cách làm đơn giản hơn, và cho quản lý dự án lý do để xếp ưu tiên.
Tiêu chí chấp nhận: viết sao cho kiểm tra được
Mỗi tiêu chí là một câu mà tester trả lời được “đạt” hoặc “không đạt” mà không cần hỏi ai. Ba đến sáu tiêu chí là vừa; nhiều hơn thì story quá to. Tránh chữ “nhanh”, “thân thiện”, “đầy đủ”: đổi thành con số hoặc tình huống.
Ví dụ
Story “xếp lịch thi tự động theo phòng” có bốn tiêu chí: (1) không có hai ca thi trùng phòng và giờ; (2) một giảng viên không coi hai phòng cùng giờ; (3) xuất được lịch ra Excel; (4) chạy dưới 30 giây với 5.000 sinh viên. Tiêu chí (4) lúc đầu viết là “chạy nhanh”, tester hỏi “nhanh là bao nhiêu”, cả đội mới thống nhất 30 giây.
Sáu dấu hiệu của story tốt (INVEST)
| Chữ | Nghĩa | Nếu thiếu thì |
|---|---|---|
| Independent | Làm được không phụ thuộc story khác | Kẹt dây chuyền, một story chậm kéo cả sprint |
| Negotiable | Cách làm còn bàn được, không đóng đinh giải pháp | Đội chỉ còn là người gõ code |
| Valuable | Người dùng được lợi rõ ràng | Làm xong không ai dùng |
| Estimable | Đội ước lượng được | Chưa đủ rõ, cần spike trước |
| Small | Xong trong một sprint, thường dưới 8 điểm | Không bao giờ xong hẳn |
| Testable | Có tiêu chí chấp nhận kiểm tra được | Cãi nhau “xong chưa” ở Review |
Khi nào không viết story
Không phải việc nào cũng là story. Việc kỹ thuật không trực tiếp là tính năng (nâng phiên bản thư viện, cấu hình máy chủ, viết tài liệu) là Task; lỗi của thứ đã có là Bug, mô tả bằng bước tái hiện và kết quả mong đợi thay vì mẫu “là ai, tôi muốn”. Ép mọi thứ thành story sinh ra những câu gượng như “Là hệ thống, tôi muốn nâng cấp cơ sở dữ liệu”. Ba loại việc và task con ở chương Backlog và công việc.
Ví dụ: viết lại ba yêu cầu mơ hồ
Ví dụ
“Làm màn hình báo cáo” thành: Là trưởng phòng Đào tạo, tôi muốn xem số sinh viên đã đăng ký theo từng học phần, để quyết định mở thêm lớp trước hạn 15/12. Tiêu chí: lọc theo học kỳ và khoa; có cột đã đăng ký trên sức chứa; xuất Excel.
“Tối ưu tốc độ” thành: Là sinh viên, tôi muốn danh sách học phần hiện trong vòng 2 giây kể cả giờ cao điểm, để đăng ký kịp trước khi hết chỗ. Tiêu chí: 2 giây với 2.000 người dùng đồng thời trên máy thử.
“Sửa lỗi đăng nhập” không phải story mà là Bug: bước tái hiện, tài khoản mẫu, ảnh chụp lỗi, kết quả mong đợi.
Bốn lỗi hay gặp
Đội mới hay mắc
- Vai trò chung chung “người dùng”. Sinh viên, giảng viên và cán bộ phòng ban cần thứ khác nhau; viết đúng vai thì tiêu chí tự rõ.
- Viết giải pháp thay vì nhu cầu. “Tôi muốn nút xuất PDF màu xanh ở góc phải” khóa cách làm; “tôi muốn in được bảng điểm để nộp phòng Đào tạo” mở cách làm.
- Không có tiêu chí chấp nhận. Story thiếu tiêu chí thì không vào sprint; tester không có gì để kiểm và Review thành tranh luận.
- Story to như một dự án. “Là sinh viên, tôi muốn đăng ký học phần” là cả hệ thống; tách theo bước, theo vai, theo trường hợp thường gặp trước.
User story trên Pentara
Tạo việc loại Story, viết câu “là ai, tôi muốn, để” ở đầu mô tả và tiêu chí chấp nhận thành danh sách ngay dưới bằng trình soạn thảo. Tester dựa vào danh sách này để kiểm ở cột Review trước khi kéo sang Done. Story to thì tách task con ngay trong màn hình chi tiết, một cấp, để nhiều người làm song song; phân hệ, nhãn và story point gắn trên story.
Đội có gói Chuyên nghiệp có thể đọc yêu cầu bằng giọng nói hoặc dán văn bản để AI dựng nháp việc kèm tiêu đề và mô tả, rồi sửa lại theo mẫu story. Chưa có dự án để thử? Đăng ký gói Miễn phí và viết story đầu tiên theo Bắt đầu nhanh.
Hỏi đáp nhanh
- User story khác use case và đặc tả yêu cầu ở đâu?
- Story ngắn, một câu cộng vài tiêu chí, viết để bàn tiếp chứ không để thay cuộc nói chuyện. Use case mô tả luồng từng bước, hợp khi cần kỹ như luồng thanh toán. Đặc tả yêu cầu là tài liệu đầy đủ cho hợp đồng. Đội nhỏ dùng story cho hầu hết việc và viết kỹ hơn chỉ ở chỗ rủi ro.
- Ai viết user story?
- Người hiểu nhu cầu nhất: quản lý dự án hoặc Product Owner cùng người dùng. Đội kỹ thuật góp tiêu chí chấp nhận và tách story. Story do dev tự viết cho mình thường thành mô tả giải pháp; story do khách viết thường thiếu tiêu chí. Viết chung là tốt nhất.
- Bug có viết dạng user story không?
- Không. Bug mô tả bằng bước tái hiện, kết quả mong đợi, kết quả thực tế, môi trường và ảnh chụp. Ép bug thành “là người dùng, tôi muốn nút không lỗi” chỉ làm mất thông tin. Việc kỹ thuật thuần cũng viết dạng Task thay vì story.