User Story là một cách thức thường được các nhóm agile sử dụng để mô tả các tính năng mong muốn. Chúng thường được viết trên quan điểm của một người dùng cuối của hệ thống. Mặt khác, chúng còn thể hiện loại người dùng, điều họ muốn, và mục đích đằng sau đó. User story giúp đơn giản hóa việc mô tả requirement. Tùy thuộc vào dự án, một US có thể được viết bởi nhiều cổ đông khác nhau bao gồm đối tác, người dùng, quản lý, hay thành viên phát triển.
User Story Template: Role-Action-Benefit
User story được viết bởi ngôn ngữ thường ngày, trong định dạng “Là :who: tôi muốn :what: nhờ đó mà :benefit:”. Nhằm định nghĩa các điểm cốt lõi của requirement, bao gồm mục tiêu cụ thể của một đối tượng người dùng cùng với lý do tại sao họ muốn điều đó.
Role – Thể hiện người mà muốn tương tác với hệ thống.
- Càng cụ thể càng tốt
- Nhà phát triển KHÔNG phải là một người dùng
Action – Hành vi của hệ thống
- Thường là duy nhất, không lặp lại tại US khác
- Khẳng định, không phủ định (chẳng hạn “tôi có thể”)
Benefits – Lợi ích đem lại (mục tiêu đằng sau mong muốn của người dùng. The benefit should be a real-world result that is non-functional or external to the system.
- Lợi ích thực tế
- Không phải chức năng
- Nhiều US có thể chia sẻ chung lợi ích
- Lợi ích có thể có cả tác dụng cho cả các người dùng khác, không chỉ mỗi người dùng trong story
Ví dụ về User Story
- Là một nhà tuyển dụng, tôi muốn đăng một thông báo tuyển người nhờ đó ứng viên có thể tìm kiếm được
- Là một người tìm việc, tôi muốn giới hạn những ai có thể nhìn thấy CV của tôi để bảo vệ sự riêng tư
3 chữ C của một User Stories
Card — Thẻ — thông tin chi tiết của story, được viết ra để sử dụng cho lập kế hoạch và ước lượng
Conversation – Thảo luận trao đổi — thông tin và các ý tưởng được đưa ra và thảo luận với những người khác. Hỏi thật nhiều, xúm nhau để đưa ra các giải pháp. Mục tiêu là cùng nhau hiểu thấu.
Confirmation — Chốt — Đồng thuận với nhau về thứ sẽ được dựng nên. Ghi lại biên bản đồng thuận dưới dạng một tập hợp các kiểm thử.
Ví dụ về User Story tệ
- Phần mềm được viết bằng C++
- Cơ sở dữ liệu có connection pool
Viết những User Story tốt với nguyên tắc INVEST
Nguyên tắc INVEST giúp dễ dàng ghi nhớ những dấu hiệu của một user story có chất lượng. Nếu một user story không đạt được một tiêu chí nào đó, nhóm có thể quyết định cải thiện hoặc thậm chí viết lại một loạt các user story.
Independent — Không phụ thuộc — Mỗi user story cần thể hiện một nghiệp vụ đơn nhất và không phụ thuộc lẫn nhau, sao cho khi user story đó được release, nó sẽ chuyển giao giá trị tăng trưởng so với trước đó.
Negotiable — Có thể thương lượng — Dù mục tiêu cuối cùng là đã được làm rõ, cách thức để đạt mục tiêu đó cần có khả năng du di — giữa PO và Dev Team, giữa PO và Customer, hay giữa bất kỳ hai cổ đông nào — nhờ đó hạn chế những ràng buộc không thực tế về chức năng/tính năng.
Valuable — Mang lại giá trị — Giá trị của nghiệp vụ của user story phải dễ dàng nhận thức được chỉ bằng cách đọc user story, mỗi story phải thể hiện sự mang lại giá trị cho một người dùng đặc thù nào đó.
Estimable — Ước lượng được — Phải có đủ thông tin để có thể ước lượng cẩn thận độ phức tạp của story, nhờ đó có thể lập kế hoạch và cam kết công việc.
Small — Nhỏ — User Story phải đủ nhỏ để có thể hoàn thành được trong thời gian một chặng nước rút (một sprint).
Testable — Kiểm thử được — Mọi thành viên cần rõ ràng cách để biết được một user story đã là xong hay chưa.
Ngoài lề, INVEST là một hướng dẫn để đánh giá nhanh chất lượng của một user story, được đề xuất bởi Bill Wake, thông qua việc đặt lại mục tiêu cho tập từ SMART (Specific, Measurable, Achievable, Relevant, Time-boxed: Cụ thể, đo đếm được, có thể đạt được, thực tế, có giới hạn về thời gian — vốn được dùng cho các task phân rã của một user story.
Nguồn: https://www.visual-paradigm.com/scrum/3c-and-invest-guide/
