Cách viết các User Story và Acceptance Criteria hiệu quả

Trong thế giới Software Development, từ “Requirement” mô tả những gì khách hàng đang tìm kiếm, mục tiêu của họ là gì hoặc những gì họ cần để giải quyết một vấn đề hoặc nhu cầu kinh doanh cụ thể. Cho dù đó là một công ty dựa trên sản phẩm phát triển các sản phẩm phần mềm hay một công ty dựa trên dịch vụ cung cấp các dịch vụ trong các loại phần mềm khác nhau, điểm mấu chốt của tất cả chúng là “Requirement” và sự thành công của dự án hoặc sản phẩm được xác định. Hãy cùng BAC tìm hiểu câu chuyện của người dùng là gì và cách viết chúng một cách hiệu quả để giảm thiểu sự mơ hồ.

1. User Story là gì?

Trong phát triển phần mềm Agile, User Story hay câu chuyện người dùng là một mô tả ngắn gọn về chức năng hoặc tính năng của sản phẩm dưới góc nhìn của người muốn sử dụng chức năng đó. Câu chuyện người dùng thường xác định yêu cầu nhỏ nhất có thể và chỉ tập trung vào một chức năng hoặc tính năng tại một thời điểm.

Định dạng tiêu chuẩn thường được sử dụng để viết một câu chuyện người dùng được đưa ra dưới đây:

• Với tư cách là (vai trò người dùng / khách hàng),
• Tôi muốn (mục tiêu phải hoàn thành)
• Vì vậy, tôi có thể (lý do của mục tiêu)

Hãy xem xét trường hợp của Supplier Portal (cổng thông tin nhà cung cấp) cho phép các công ty quản lý và kết nối với các nhà cung cấp hàng hóa và hoặc dịch vụ bên thứ ba. Cổng thông tin nhà cung cấp tự động dựa trên web xử lý việc đăng ký, giới thiệu và tuân thủ, cho phép nhà cung cấp tự đăng ký và gửi sự tuân thủ cũng như các chi tiết bắt buộc khác như số VAT, chi tiết ngân hàng,.... Nhà cung cấp có thể tăng hóa đơn đối với các mặt hàng hoặc dịch vụ mà họ đã cung cấp và theo dõi trạng thái hóa đơn của họ (đang chờ xử lý, được chấp thuận, bị từ chối, đã thanh toán,...).

• Với tư cách là Nhà cung cấp, tôi có thể tự đăng ký với Cổng thông tin để có thể tăng hóa đơn
• Với tư cách là Nhà cung cấp, tôi có thể lập hóa đơn để có thể theo dõi trạng thái thanh toán
• Với tư cách là Nhà cung cấp, tôi có thể tải lên chi tiết hóa đơn bằng excel để tôi có thể theo dõi tình trạng thanh toán
• Với tư cách là Nhà cung cấp, tôi có thể chỉnh sửa các hóa đơn bị từ chối để có thể gửi lại để phê duyệt
• Với tư cách là Nhà cung cấp, tôi có thể thêm chi tiết dòng hóa đơn để nhà cung cấp có thể tự động tính số tiền VAT
• Với tư cách là Người ủy quyền hóa đơn, tôi sẽ có thể phê duyệt các hóa đơn để có thể phát hành khoản thanh toán cho nhà cung cấp
• Với tư cách là Người ủy quyền hóa đơn, tôi có thể từ chối các hóa đơn có nhận xét để Nhà cung cấp có thể gửi lại

Bạn phải dựa vào từ viết tắt INVEST để đánh giá chất lượng câu chuyện của người dùng.

• Independent (Độc lập): Một câu chuyện người dùng cụ thể phải được phát triển độc lập với các câu chuyện người dùng khác - Tránh giới thiệu bất kỳ phụ thuộc nào hoặc kết hợp các câu chuyện người dùng.
• Negotiable (Có thể thương lượng): Câu chuyện của người dùng không phải là hợp đồng; do đó nó sẽ cần sự linh hoạt được điều chỉnh dựa trên mức độ được triển khai.
• Valuable (Có giá trị): Nó có lợi như thế nào hoặc nó cung cấp giá trị gì cho người dùng, khách hàng và các bên liên quan

• Estimable (Có thể ước tính): Nhóm cần có đủ thông tin để ước tính các nỗ lực
• Small (Nhỏ): Nó phải có kích thước phù hợp để hoàn thành trong Sprint (bao gồm cả thử nghiệm)

• Testable (Có thể kiểm tra được): Đáp ứng nhu cầu của khách hàng, được tất cả mọi người hiểu và đủ rõ ràng để đánh giá xem câu chuyện có được thực hiện hay không. (nó phải dễ dàng được kiểm tra đơn vị và chấp nhận)

2. Acceptance Criteria là gì?

Acceptance Criteria hay tiêu chí chấp nhận (đôi khi được gọi là "định nghĩa của việc đã hoàn thành") là các điều kiện phải được đáp ứng để user story được đánh dấu là hoàn chỉnh và được người dùng, khách hàng hoặc bất kỳ hệ thống nào khác chấp nhận. Nó thường được trình bày dưới dạng các câu lệnh có thể được xác nhận là đạt hay không đạt. Mỗi product backlog item hoặc mỗi user story phải có ít nhất một acceptance criteria.

Các tiêu chí chấp nhận tốt phải bao gồm

• Khả năng sử dụng: Đảm bảo có các thước đo về khả năng sử dụng trong tiêu chí chấp nhận. Nó chỉ ra cách trả lời các câu hỏi như: Nó có dễ sử dụng không? Điểm quan trọng là xác định các phép đo chính xác và đảm bảo mỗi phép đo đều có thể định lượng được.
• Chức năng: Các tiêu chí chấp nhận xác định chính xác những gì phải được phát triển bởi nhóm phát triển. Khi nhóm có các yêu cầu chính xác, họ có thể chia các câu chuyện của người dùng thành các nhiệm vụ có thể được ước tính một cách chính xác.
• Xử lý lỗi: Tiêu chí chấp nhận có thể yêu cầu hệ thống xác định các trường hợp lỗi và cách xử lý từng lỗi. Ví dụ: Nhập mật khẩu không hợp lệ hoặc yêu cầu định dạng mật khẩu. Tiêu chí chấp nhận nên xác định các tình huống này và giải thích cách một hệ thống nên phản ứng với chúng.
• Hiệu suất: Tiêu chí chấp nhận nên xác định hiệu suất hệ thống từ góc độ người dùng cá nhân. Ví dụ: giao diện người dùng phải đáp ứng hoặc điều hướng đến một trang mới
• Kiểm tra mức độ căng thẳng: Tiêu chí chấp nhận phải mô tả cách hệ thống sẽ phản hồi khi nó bị căng thẳng vì có nhiều người dùng, giao dịch, khối lượng hoặc truy vấn. Tiêu chí chấp nhận cũng cần xác định các ngưỡng chấp nhận được đối với thử nghiệm căng thẳng. Ví dụ: Hệ thống phản hồi trong ngưỡng 275 mili giây khi có 100 người dùng gửi truy vấn đồng thời.

Dưới đây là một số tiêu chí chấp nhận tốt cho câu chuyện người dùng đã thảo luận ở trên:

"Là một nhà cung cấp, tôi có thể tự đăng ký với cổng thông tin để tôi có thể tăng hóa đơn."

• Người sử dụng nhà cung cấp phải cung cấp thông tin cho mọi trường được đánh dấu theo yêu cầu.
• Tất cả các trường phải vượt qua xác thực thành công (ví dụ: Tên không được chứa số, số điện thoại phải chứa giá trị số, …). Thông báo lỗi phải được hiển thị cho định dạng dữ liệu không chính xác.
• Người dùng có thể tải lên ảnh hồ sơ.
• Người dùng có thể đặt các tùy chọn liên quan đến doanh nghiệp.
• Người dùng có thể tải lên chứng chỉ VAT và bảng sao kê Ngân hàng dưới dạng tệp đính kèm. Thông báo lỗi phải được hiển thị nếu định dạng tệp được tải lên khác với định dạng tệp phải được đính kèm.
• Khi nhấp vào nút "Đăng ký", hệ thống phải hiển thị thông báo "Đã đăng ký thành công nhà cung cấp".
• Hệ thống phải gửi một email giới thiệu đến các Nhà cung cấp khi đăng ký thành công.
• Hệ thống phải gửi một bản sao của email giới thiệu cho nhóm liên quan.

Tóm lại, viết user story hiệu quả và tiêu chí chấp nhận là một tình huống đôi bên cùng có lợi cho cả khách hàng và nhóm phát triển. Nó không chỉ giúp nhóm biết chính xác những gì họ phải làm mà còn giúp khách hàng được thông báo về quá trình phát triển. Mong rằng bài viết này sẽ hữu ích với bạn đọc, đừng quên đón xem các nội dung mới sẽ được cập nhật thường xuyên tại BAC's Blog.

Nguồn tham khảo:
https://prod.adaptiveus.com/

Nhu cầu đào tạo doanh nghiệp