Hướng dẫn viết user stories và các ví dụ mẫu

User stories là một phần của phương pháp Agile giúp dịch chuyển từ việc viết về yêu cầu sang kể về yêu cầu. Các user stories theo phương pháp agile sẽ là một hoặc hai câu hoặc một chuỗi câu đối thoại về chức năng mong muốn.

User stories là gì?

User stories là những mô tả ngắn gọn, đơn giản về một feature và được kể từ cách nhìn của nhóm người dùng (user hoặc customer của phần mềm) muốn có feature đó. Một cách điển hình user stories có dạng:

Với tư cách là một người thuộc < nhóm user >, tôi muốn < mục tiêu > vì < lý do >

[As a < type of user >, I want < some goal > so that < some reason >]

User stories thường được viết trên những miếng thẻ (index cards hoặc sticky notes) được cất trong hộp đựng hoặc được dán trên tường, trên mặt bàn giúp cho việc thảo luận và lập kế hoạch được dễ dàng. Bằng cách này người ta chuyển từ việc viết ra feature sang việc thảo luận & kể về feature đó. Thực tế là trao đổi, thảo luận về feature thì quan trọng hơn là chỉ viết ra câu chữ mô tả.

Ví dụ về user story

Một ích lợi của user stories là chúng có thể được viết ra theo những mức độ chi tiết khác nhau. Người ta thậm chí có thể viết chỉ một user story chứa đựng cả một lượng lớn các chức năng. Kiểu user story này được gọi là Epic. Chẳng hạn đây là một ví dụ về epic của một phần mềm sao lưu dành cho máy trạm:

“Với tư cách một người dùng, tôi có thể sao lưu toàn bộ ổ cứng laptop của tôi”

Bởi vì một epic thường quá to để một agile team có thể hoàn thành trong vòng một iteration, nó sẽ được chia nhỏ thành nhiều user stories con trước khi agile team bắt tay thực hiện epic. Khái quát thì epic có thể chia thành mươi mười lăm user stories con, hoặc thậm chí cả trăm. Ví dụ epic nói trên bao gồm 2 user stories con như sau:

“Với tư cách một power user, tôi có thể chỉ ra các file hoặc folder sẽ được sao lưu, căn cứ theo kích thước file, ngày tạo và ngày sửa đổi”

Và

“Với tư cách một user tôi có thể chỉ ra các folder không cần sao lưu để ổ đích sao lưu của tôi khỏi bị chiếm chỗ bởi những thư mục tôi không cần sao lưu”

Cách thêm chi tiết vào một user story

Chi tiết có thể được thêm vào user story theo hai cách

Bằng cách chia nhỏ thành nhiều user story con
Bằng cách thêm các điều kiện cần thỏa mãn

Khi chia nhỏ một user story lớn thành nhiều user story con thì rõ ràng là chi tiết đã được thêm vào. Bạn đã phải viết nhiều hơn về user story đó.

Các điều kiện cần thỏa mãn thì đơn giản một dạng viết tiêu chí nghiệm thu ở high-level (high-level acceptance test) đối với user story đó.

Hãy xét ví dụ sau đây:

“Với tư cách một phó chủ tịch Marketing, tôi muốn chọn ra kỳ nghỉ lễ để sử dụng khi review kết quả của các chiến dịch marketing trong quá khứ để tôi có thể nhận biết đâu là kỳ nghỉ lễ sinh lợi nhất đối với chiến dịch”

Chi tiết được thêm vào user story nói trên nếu chỉ rõ điều kiện cần thỏa mãn là

“Danh sách các kỳ nghỉ lễ có thể chọn là bao gồm Christmas, Easter, President’s Day, Mother’s Day, Father’s Day, Labor Day, New Year’s Day.” Hoặc

“Hỗ trợ các kỳ nghỉ lễ bắc qua 2 năm”. Hoặc

“Có thể chọn ra số ngày cụ thể trước một ngày nghỉ lễ”

Ai viết user stories?

Bất kỳ ai cũng có thể viết user stories. Product Owner là người chịu trách nhiệm bảo đảm rằng phải tồn tại một Product backlog bao gồm các user stories, nhưng không nhất thiết phải trực tiếp viết ra các user stories. Với một Development Team đã có kinh nghiệm làm tốt một dự án agile thì người ta có thể kỳ vọng mỗi một thành viên của team đều có năng lực viết user stories.

Nhớ rằng ai viết user stories không quan trọng bằng ai thực sự tham gia thảo luận về nó.

Khi nào thì viết user stories?

Các user stories được viết ra trong suốt vòng đời của một dự án agile. Thường thường sẽ có một workshop để viết user stories trước khi sắp bắt đầu dự án. Mọi người trong team cùng tham gia với mục tiêu tạo ra một product backlog mô tả đầy đủ các chức năng sẽ được phát triển dần trong cả vòng đời dự án hoặc các chức năng sẽ được release trong vòng từ 3 đến 6 tháng sắp tới.

Hiển nhiên sẽ có những user stories lớn, đích thị là các epic. Thì sau này các epic sẽ cần được phân rã nhỏ hơn thành các user stories con mà có thể hoàn thành chỉ trong một iteration. Ngoài ra cũng sẽ có những user stories mới được thêm vào.

Liệu user stories có thể thay cho tài liệu phát biểu yêu cầu?

Các dự án agile, nhất là dự án theo phương pháp Scrum, sử dụng một Product backlog, tức là một danh sách các chức năng được sắp xếp theo thứ tự ưu tiên cần được phát triển khi xây dựng sản phẩm phần mềm. Mặc dù Product backlog thực tế bao gồm bất cứ item nào mà team muốn đưa vào, nhưng về cơ bản các user stories là hình thức phổ biến nhất và tốt nhất của các item trong Product backlog.

Product backlog có thể được coi như sự thay thế cho Tài liệu phát biểu yêu cầu vốn thấy ở các dự án truyền thống, nhưng bạn cần nhớ rằng một user story của dự án agile dù đã được viết ra thì chỉ được coi là viết XONG thực sự sau khi team đã thảo luận và hiểu rõ về nó.

Bạn nên coi các câu chữ được viết ra giống như là những pointer (con trỏ) chỉ dẫn đến các yêu cầu thực sự. User stories chẳng hạn có thể chỉ dẫn đến một sơ đồ luồng công việc (workflow diagram), hoặc chỉ đến một spreadsheet giải thích chi tiết một công thức tính toán hoặc mô tả một sản phẩm mà Product Owner hoặc Team mong muốn.