MỤC ĐÍCH
Câu chuyện của người dùng (user story) thể hiện một tuyên bố nhỏ, ngắn gọn về chức năng hoặc chất lượng cần thiết để mang lại giá trị cho một bên liên quan cụ thể.
MÔ TẢ
Use story nắm bắt nhu cầu của một bên liên quan cụ thể và cho phép các nhóm xác định các đặc điểm có giá trị đối với bên liên quan bằng cách sử dụng tài liệu ngắn gọn, đơn giản. Chúng có thể làm cơ sở để xác định nhu cầu và cho phép ưu tiên, ước tính và lập kế hoạch cho các giải pháp. User story thường là một hoặc hai câu mô tả về người có nhu cầu được câu chuyện giải quyết, mục tiêu mà người dùng đang cố gắng hoàn thành và bất kỳ thông tin bổ sung nào có thể quan trọng để hiểu phạm vi của câu chuyện. Với việc tập trung vào giá trị của các bên liên quan, user story mời gọi việc khám phá các yêu cầu bằng cách thúc đẩy các cuộc trò chuyện bổ sung với các bên liên quan và nhóm các yêu cầu chức năng để phân phối.
User story có thể được sử dụng:
- Để nắm bắt nhu cầu của các bên liên quan và ưu tiên phát triển các giải pháp
- Làm cơ sở cho việc ước tính và lập kế hoạch cung cấp giải pháp
- Làm cơ sở để tạo ra các bài kiểm thử chấp nhận của người dùng
- Như một thước đo để đo lường việc phân phối giá trị
- Như một đơn vị truy xuất nguồn gốc các yêu cầu liên quan
- Làm cơ sở cho việc phân tích bổ sung
- Là đơn vị quản lý dự án và báo cáo.
YẾU TỐ
Tiêu đề (tùy chọn)
Tiêu đề của user story mô tả một hoạt động mà bên liên quan muốn thực hiện với hệ thống. Thông thường, nó là một cụm từ mục tiêu có động từ chủ động tương tự như cách đặt tiêu đề cho các use case.
Tuyên bố giá trị
Không có cấu trúc bắt buộc cho user story. Định dạng phổ biến nhất bao gồm ba thành phần:
- Ai (Who): vai trò hoặc cá nhân người dùng.
- Cái gì (What): một hành động, hành vi, tính năng hoặc chất lượng cần thiết.
- Tại sao (Why): lợi ích hoặc giá trị mà người dùng nhận được khi câu chuyện được đăng được thực hiện.
Ví dụ:
“Là một <ai>, tôi cần <cái gì>, để <tại sao>.”
“Vì…Khi…Thì” (“Given …. When …. Then….) là một định dạng phổ biến khác.
Cuộc trò chuyện
User story giúp các nhóm khám phá và hiểu tính năng được mô tả trong câu chuyện cũng như giá trị mà nó sẽ mang lại cho các bên liên quan. Bản thân câu chuyện không nắm bắt được mọi điều cần biết về nhu cầu của các bên liên quan và thông tin trong câu chuyện được bổ sung bằng cách mô hình hóa sâu hơn khi câu chuyện được truyền tải.
Tiêu chí chấp nhận
User story có thể được hỗ trợ thông qua việc phát triển các tiêu chí chấp nhận chi tiết (xem Tiêu chí chấp nhận và đánh giá). Tiêu chí chấp nhận xác định ranh giới của user story và giúp nhóm hiểu những gì giải pháp cần cung cấp để mang lại giá trị cho các bên liên quan.
Tiêu chí chấp nhận có thể được bổ sung bằng các mô hình phân tích khác nếu cần.
CÂN NHẮC SỬ DỤNG
Điểm mạnh
- Các bên liên quan dễ hiểu.
- Có thể được phát triển thông qua nhiều kỹ thuật khơi gợi khác nhau.
- Tập trung vào giá trị cho các bên liên quan.
- Sự hiểu biết chung về lĩnh vực nghiệp vụ được nâng cao thông qua cộng tác xác định và khám phá các câu chuyện của người dùng.
- Gắn với các phần chức năng nhỏ, có thể triển khai và kiểm tra được, giúp tạo điều kiện phân phối nhanh chóng và phản hồi khách hàng thường xuyên.
Hạn chế
Nói chung, các user stories được coi là một công cụ để nắm bắt và ưu tiên các yêu cầu trong thời gian ngắn chứ không phải để lưu giữ kiến thức lâu dài hoặc cung cấp phân tích chi tiết. Bỏ qua nguyên tắc này có thể dẫn đến các vấn đề sau:
- Cách tiếp cận đàm thoại này có thể thách thức nhóm vì họ không có trước tất cả các câu trả lời và thông số kỹ thuật chi tiết.
- Yêu cầu bối cảnh và khả năng hiển thị; nhóm có thể đánh mất bức tranh toàn cảnh nếu các câu chuyện không được truy ngược lại thông qua quá trình xác thực hoặc được bổ sung các phân tích cấp cao hơn và tạo tác hình ảnh.
- Có thể không cung cấp đủ tài liệu để đáp ứng nhu cầu quản trị, cơ sở cho công việc trong tương lai hoặc mong đợi của các bên liên quan. Tài liệu bổ sung có thể được yêu cầu.
