Cách viết User Story (kèm ví dụ và tiêu chí chấp nhận)
Một user story là mô tả ngắn gọn về một tính năng theo góc nhìn của người dùng: “Với tư cách là [loại người dùng], tôi muốn [mục tiêu] để [lý do].” Bên dưới, bạn viết các tiêu chí chấp nhận (acceptance criteria), tức một vài điều kiện cụ thể phải đúng thì story mới được coi là xong. Hãy giữ mỗi story đủ nhỏ để xây dựng và kiểm thử trong một lần, và viết tiêu chí sao cho bất kỳ ai cũng có thể kiểm tra được.
User story được các nhóm phát triển phần mềm theo phương pháp Agile phổ biến, nhưng chúng cũng rất hữu ích khi bạn tự xây dựng sản phẩm với một công cụ tạo app bằng AI. Một story tốt chính là một prompt tốt.
Định dạng
Một user story gồm ba phần:
Với tư cách là [ai], tôi muốn [việc gì] để [vì sao].
- Ai là một kiểu người dùng cụ thể: khách truy cập lần đầu, thành viên trả phí, lễ tân phòng khám, quản trị viên. Đừng viết chung chung là “người dùng”.
- Việc gì là điều họ muốn làm, dùng chính cách diễn đạt của họ. Đừng mô tả cách màn hình hoạt động.
- Vì sao là kết quả mà họ quan tâm. Đây là phần hay bị bỏ qua nhất, nhưng nó giúp bạn tránh xây dựng sai thứ.
Ví dụ:
Với tư cách là hội viên phòng gym, tôi muốn hủy đặt lớp tập từ điện thoại để người trong danh sách chờ có thể nhận chỗ của tôi và tôi không bị tính phí vắng mặt.
Phần “vì sao” cho bạn biết hai điều mà phần “việc gì” không nói: tính năng phải hoạt động tốt trên điện thoại, và có liên quan đến danh sách chờ cũng như quy định phí.
Tiêu chí chấp nhận
Story cho biết điều gì được mong muốn. Tiêu chí chấp nhận cho biết khi nào thì việc đó được coi là xong. Chúng cần đủ cụ thể để hai người bất kỳ đều đồng ý được một tiêu chí có đạt hay không.
Một cách viết phổ biến là Given / When / Then:
- Given (cho trước) một tình huống ban đầu
- When (khi) người dùng làm một việc
- Then (thì) đây là kết quả
Với story đặt lớp tập ở trên:
- Given tôi có một lượt đặt lớp cách hơn 12 giờ, when tôi nhấn Hủy và xác nhận, then lượt đặt bị xóa và tôi thấy thông báo “Đã hủy đặt lớp”.
- Given tôi hủy một lượt đặt và lớp đó có danh sách chờ, when việc hủy được lưu, then người đầu tiên trong danh sách chờ nhận được chỗ và một email.
- Given một lượt đặt cách chưa tới 12 giờ, when tôi nhấn Hủy, then tôi thấy thông báo phí hủy muộn sẽ được áp dụng trước khi xác nhận.
- Given tôi đang dùng màn hình có chiều rộng bằng điện thoại, then nút Hủy hiển thị được mà không phải cuộn ngang.
Một danh sách kiểm tra đơn giản cũng được, miễn là mỗi mục có thể kiểm thử. “Hủy đặt lớp thật dễ dàng” không kiểm thử được. “Hủy đặt lớp chỉ cần tối đa hai lần chạm từ danh sách lượt đặt” thì kiểm thử được.
Từng bước: viết một story tốt
Bước 1: Bắt đầu từ một người dùng thật và một vấn đề thật
Chọn một kiểu người dùng và một khó khăn mà họ đang gặp. Nếu bạn đã phỏng vấn khách hàng, hãy dùng chính lời lẽ của họ. “Tôi luôn quên hủy nên bị trừ tiền” là điểm xuất phát tốt hơn nhiều so với “thêm tính năng hủy”.
Bước 2: Viết story một dòng
Điền vào mẫu. Nếu bạn không viết được phần “để” một cách thuyết phục, hãy tự hỏi liệu tính năng đó có thực sự cần thiết không.
Bước 3: Thêm từ ba đến sáu tiêu chí chấp nhận
Bao quát trường hợp thành công chính trước, sau đó là các biến thể quan trọng: một vai trò khác, một trạng thái trống, một giới hạn, một lỗi. Nếu bạn viết hơn sáu tiêu chí, story có lẽ đang quá lớn.
Bước 4: Ghi rõ những gì nằm ngoài phạm vi
Một dòng ghi chú có thể tiết kiệm rất nhiều qua lại: “Ngoài phạm vi: hoàn tiền cho lớp trả phí; quản trị viên hủy thay cho hội viên.” Điều này giúp story không phình ra trong lúc bạn đang xây dựng.
Bước 5: Kiểm tra theo INVEST
INVEST là một danh sách kiểm tra phổ biến cho story tốt. Một story nên:
| Chữ cái | Nghĩa | Cách kiểm tra nhanh |
|---|---|---|
| I | Độc lập (Independent) | Có thể xây dựng mà không phải chờ story khác |
| N | Có thể thương lượng (Negotiable) | Mô tả nhu cầu, không phải thiết kế cố định |
| V | Có giá trị (Valuable) | Người dùng sẽ nhận ra nếu nó được phát hành |
| E | Ước lượng được (Estimable) | Bạn có thể đoán tương đối quy mô của nó |
| S | Đủ nhỏ (Small) | Xây dựng và kiểm thử được trong một buổi |
| T | Kiểm thử được (Testable) | Mỗi tiêu chí chấp nhận đều có thể kiểm tra |
Bạn không cần chấm điểm mọi story. Cách này hữu ích nhất khi một story có cảm giác không ổn và bạn muốn biết lý do.
Ví dụ tốt và chưa tốt
| Story yếu | Vấn đề | Story tốt hơn |
|---|---|---|
| Với tư cách là người dùng, tôi muốn có một bảng điều khiển. | Không có người dùng cụ thể, không có lý do, không kiểm thử được | Với tư cách là chủ cửa hàng, tôi muốn xem đơn hàng và doanh thu hôm nay trên một màn hình để biết ngay ngày hôm nay có suôn sẻ không. |
| Với tư cách là quản trị viên, tôi muốn cơ sở dữ liệu có một cột trạng thái. | Mô tả cách triển khai, không phải nhu cầu | Với tư cách là quản trị viên, tôi muốn đánh dấu đơn hàng đã giao để khách hàng không phải nhắn tin hỏi đơn đang ở đâu. |
| Với tư cách là khách hàng, tôi muốn quản lý tài khoản của mình. | Quá lớn: bao gồm nhiều tính năng | Với tư cách là khách hàng, tôi muốn đổi địa chỉ email để hóa đơn được gửi đến hộp thư mới. |
| Với tư cách là khách truy cập, tôi muốn trang web nhanh. | Đây không phải story; đó là một chất lượng mà ai cũng cần | Viết thành một tiêu chí trên mọi story, hoặc thành một mục tiêu hiệu năng riêng. |
Cách chia một story quá lớn
Các story quá lớn là nguyên nhân khiến dự án bị đình trệ. Những cách chia thường gặp:
- Theo vai trò người dùng. Hội viên tự hủy lượt đặt của mình; nhân viên hủy lượt đặt của bất kỳ ai.
- Theo bước trong luồng. Xem lớp; đặt lớp; nhận nhắc lịch.
- Trường hợp đơn giản trước. Hủy lớp miễn phí ngay bây giờ; xử lý phí và hoàn tiền trong một story sau.
- Theo biến thể dữ liệu. Hỗ trợ một địa điểm trước, nhiều địa điểm sau.
- Luồng chính trước, lỗi sau. Làm cho nó chạy được trước, sau đó thêm xử lý cho lớp đã đầy, gói học hết hạn, v.v.
Mỗi phần vẫn phải là thứ mà người dùng có thể dùng và nhận ra.
Dùng user story làm prompt
Một user story kèm tiêu chí chấp nhận rất gần với một prompt tốt cho công cụ tạo app bằng AI. Nó cho AI biết ai là người dùng, họ muốn gì, vì sao, và thế nào là hoàn thành. Hãy gửi mỗi lần một story:
Với tư cách là hội viên phòng gym, tôi muốn hủy lượt đặt lớp từ điện thoại để người trong danh sách chờ có thể nhận chỗ của tôi. Tiêu chí chấp nhận:
- Nút Hủy nằm ở mỗi lượt đặt trong Lượt đặt của tôi, có bước xác nhận.
- Hủy trước hơn 12 giờ thì chỉ cần xóa lượt đặt.
- Trước chưa tới 12 giờ, hiển thị “Áp dụng phí hủy muộn 5 USD” trước khi xác nhận, và ghi phí vào lượt đặt.
- Nếu lớp có danh sách chờ, người đầu tiên nhận được chỗ và một email.
- Hoạt động trên màn hình có chiều rộng bằng điện thoại. Ngoài phạm vi: hoàn tiền, nhân viên hủy thay hội viên. Hãy xây dựng, sau đó kiểm tra từng tiêu chí trong bản xem trước và cho tôi biết tiêu chí nào đạt.
Bạn cũng có thể nhờ AI soạn story từ một ý tưởng sơ bộ, rồi tự chỉnh sửa:
Đây là ý tưởng ứng dụng của tôi: [hai hoặc ba câu]. Hãy viết các user story cho phiên bản đầu tiên, nhóm theo loại người dùng, mỗi story có 3 đến 5 tiêu chí Given/When/Then. Đánh dấu story nào cần thiết cho lần ra mắt và story nào có thể để sau.
Luôn đọc và chỉnh sửa kết quả. AI không biết người dùng của bạn; bạn mới biết.
Các tiêu chí chấp nhận cũng đóng vai trò là kế hoạch kiểm thử của bạn. Khi story đã được xây dựng, hãy tự kiểm tra từng tiêu chí. Hướng dẫn của chúng tôi về kiểm thử ứng dụng trước khi ra mắt được xây dựng trên ý tưởng này.
User story nằm ở đâu trong các tài liệu khác
- Một tài liệu yêu cầu sản phẩm (PRD) mô tả toàn bộ sản phẩm: vấn đề, người dùng, phạm vi. User story là các phần chi tiết nằm bên trong nó. Xem cách viết PRD với AI.
- Một báo lỗi (bug report) mô tả một thứ bị hỏng so với một story đã được xây dựng trước đó. Xem cách viết báo lỗi tốt.
- Một MVP là tập story nhỏ nhất mang lại giá trị cốt lõi. Xem MVP là gì.
Những lỗi thường gặp
- “Với tư cách là người dùng…” Quá chung chung. Hãy nêu loại người dùng cụ thể.
- Bỏ phần “để”. Nếu không có lý do, bạn không thể đánh đổi hợp lý.
- Viết giải pháp thay vì nhu cầu. “Tôi muốn một menu thả xuống” khóa thiết kế trước khi ai đó nghĩ kỹ.
- Tiêu chí không kiểm thử được. “Dễ dùng”, “nhanh” và “trực quan” là mong muốn, không phải tiêu chí.
- Story thực chất là epic. “Quản lý tài khoản của tôi” là mười story.
- Viết hết mọi story ngay từ đầu. Hãy viết chi tiết vài story tiếp theo; những story còn lại giữ ở dạng một dòng cho đến khi bạn đến lượt chúng.
Story trong Mythex
Trong Mythex, chế độ Plan là nơi phù hợp để biến một ý tưởng thành các story: agent bàn về cách tiếp cận trước khi chỉnh sửa bất cứ thứ gì. Khi một story đã sẵn sàng, chuyển sang Build và dán vào, mỗi lần một story. Sau mỗi lần, /test có thể thao tác trong bản xem trước và kiểm tra luồng, và bạn có thể quay lại bất kỳ phản hồi nào bằng Revert to this point nếu nó đi sai hướng. Xem prompt hiệu quả trong tài liệu, và hướng dẫn của chúng tôi về cách viết prompt cho công cụ tạo app bằng AI.
Danh sách kiểm tra user story
- Nêu rõ một kiểu người dùng cụ thể
- Mô tả một nhu cầu, không phải một thiết kế
- Có phần “để” là một lý do thật
- Có từ ba đến sáu tiêu chí chấp nhận kiểm thử được
- Bao quát ít nhất một trường hợp ngoại lệ hoặc lỗi
- Ghi rõ những gì nằm ngoài phạm vi
- Đủ nhỏ để xây dựng và kiểm thử trong một lần
- Đã kiểm tra từng tiêu chí một sau khi xây dựng
Câu hỏi thường gặp
Định dạng của một user story là gì?
Mẫu phổ biến là: Với tư cách là [loại người dùng], tôi muốn [mục tiêu] để [lý do]. Sau đó là các tiêu chí chấp nhận, tức một danh sách ngắn các điều kiện phải đúng thì story mới được coi là xong.
Tiêu chí chấp nhận (acceptance criteria) là gì?
Tiêu chí chấp nhận là các điều kiện cụ thể, kiểm thử được, xác định khi nào một user story được hoàn thành. Chúng thường được viết theo dạng Given / When / Then: cho trước một tình huống ban đầu, khi người dùng làm một việc gì đó, thì sẽ có một kết quả nhất định xảy ra.
Một user story nên có kích thước thế nào?
Đủ nhỏ để xây dựng và kiểm thử trong một buổi làm việc, nhưng vẫn có giá trị khi đứng riêng. Nếu một story có hơn năm hoặc sáu tiêu chí chấp nhận, hoặc trải qua nhiều màn hình, hãy chia nhỏ theo vai trò người dùng, theo từng bước trong luồng, hoặc làm trường hợp đơn giản trước và các trường hợp ngoại lệ sau.
User story có hữu ích khi xây dựng với AI không?
Có. Một user story kèm tiêu chí chấp nhận gần như là một prompt lý tưởng: nó cho biết tính năng dành cho ai, họ cần gì, và chính xác cách kiểm tra xem tính năng có chạy đúng không. Gửi mỗi lần một story cũng giúp các thay đổi do AI thực hiện nhỏ và dễ kiểm thử.