Acceptance Criteria (AC) là gì? Làm thế nào để viết được AC?

-A A +A

Acceptance Criteria (AC) là gì?

Acceptance Criteria là một tập hợp các điều kiện chấp nhận mà chức năng hoặc tính năng phải thỏa mãn để được Product Owner (PO)/ Stakeholder chấp nhận.

AC giúp ghi lại những kỳ vọng của khách hàng, làm rõ yêu cầu của khách hàng, đảm bảo thông tin nghiệm thu minh bạch.

Acceptance Criteria
Acceptance Criteria

AC được tạo bởi ai?

AC được tạo ra bởi PO nếu PO hiểu về Software Devlopment và cách viết AC. Nếu PO không quen viết, thì họ sẽ giao cho một người có khả năng viết như Business Analyst, Scrum menber thích hợp, Requirement Analyst. Sau đó Development team sẽ review xem đủ tài liệu chưa, có điểm nào mơ hồ không thể đáp ứng cũng chỉnh sửa lại không.

Làm thế nào để viết được AC?

AC có thể viết bởi nhiều format khác nhau. Tuy nhiên, có 2 cấu trúc được sử dụng phổ biến là Theo kịch bản (Given/When/Then) và Theo Quy tắc (Checklist).

Dạng kịch bản (Given/When/Then)

  • Scenario: tên cho hành vi sẽ mô tả
  • Given : trạng thái bắt đầu của kịch bản (1 vài điều kiện)
  • When : hành động cụ thể mà người dùng thực hiện ( Làm vài hành động)
  • Then : kết quả cho hành động đó (Mong muốn vài kết quả)
  • And: được sử dụng bất cứ lúc nào trong 3 câu trước

Sau khi phát biểu kết thúc cần bao hàm tất cả hành động mà người dùng thực hiện để hoàn thành nhiệm vụ và trải nghiệm kết quả

VD User story: Là người dùng, tôi muốn đăng nhập vào hệ thống

AC1: nếu thông tin hợp lệ, người dùng có thể đăng nhập

  • Given: người dùng có tài khoản trong hệ thống
  • And: người dùng đang ở trang “Đăng nhập”
  • When: người dùng nhập “duyenthai” vào trường Username
  • And: người dùng nhập “duyen123” vào trường Password
  • And: người dùng nhấn nút “Đăng nhập”.
  • Then: Người dùng nhìn thấy thông báo “Đăng nhập thành công”
  • And: Chuyển sang “Trang chủ”.

AC2: nếu nhập sai mật khẩu, người dùng không đăng nhập được vào hệ thống.

  • Given: người dùng có tài khoản trong hệ thống
  • And: người dùng đang ở trang “Đăng nhập”
  • When: người dùng nhập “duyenthai” vào trường Username
  • And: người dùng nhập “duyen120” vào trường Password
  • And: người dùng nhấn nút “Đăng nhập”
  • Then: người dùng không thể đăng nhập vào hệ thống
  • And: hệ thống thông báo ” Sai thông tin mật khẩu, vui lòng nhập lại!”
  • And: hệ thống giữ nguyên tại giao diên “Đăng nhập”

Trong một vài trường hợp dưới đây rất khó để đưa AC với format Given/when/then.

  • Với User story mô tả chức năng cấ hệ thống cần những phương thức đảm bảo chất lượng
  • Đối tựng mục tiêu của điều kiện chấp nhận không cần chi tiết chính xác về các testcase
  • Given/when/then không phù hợp với mô tả ràng buộc về thiết kế và tari nghiệm người dùng của 1 tính năng

Với những trường hợp trên thì nên mô tả AC bằng format Quy tắc (Checklist).

Dạng quy tắc (Checklist)

AC dạng checklist
AC dạng checklist

AC dạng quy tắc mô tả hành vi của hệ thống, dựa trên những quy tắc này rồi vẽ ra những case cụ thể. AC dạng này thông thường sẽ được soạn với những gạch đầu dòng đơn giản

VD User story: là người dùng tôi muốn có thể tìm kiếm nhà với những thông tin địa chỉ.

AC giao diện tìm kiếm

  • Thanh Tìm kiếm đặt trên cùng
  • Cho phép người dùng tìm kiếm địa chỉ theo Tỉnh/Thành phố, Huyện/Quận, Xã/Phường. Mỗi trường này đều là select option cho phép người dùng tìm kiếm nhanh.
  • Bắt đầu tìm kiếm khi người dùng nhấn vào ô “Tìm kiếm”
  • Place holder là “Bạn muốn đi đâu?”
  • Tìm kiếm dạng gần đúng
  • Không hỗ trợ tìm kiếm những ký tự đặc biệt

Kết luận

Dù nhóm của bạn phát triển phần mềm bằng mô hình nào thì việc xác định rõ ràng các điều kiện chấp nhận cũng giúp nhóm biết cần phải làm mỗi tính năng đến mức nào, như thế nào là xong. Đêìu cuối cùng là những lưu ý khi viết AC

  • Nên viết theo dạng ai đọc cũng hiểu
  • Không có mô tả kỹ thuật trong AC
  • Có format nhất quán
  • Chỉ nên viết những AC quan trọng, bắt buộc phải có trong User story

Mong những thông tin sẽ giúp ích cho bạn biết cách viết AC cho mỗi tính năng trong sản phẩm.

Phân biệt AC và DoD (Definition of Done)

Sẽ có nhiều người nhầm lẫn giữa DoD (khái niệm về sự hoàn thành trong Scrum) và AC (tiêu chí nghiệm thu của chủ đầu tư hoặc đơn vị vận hành). Hãy cùng tìm hiểu sự khác nhau dưới đây:

Ví dụ của DoD:

  1. Tính năng chạy được
  2. Code đã được review chéo
  3. Hoàn thành kiểm thử chấp nhận
  4. Release lên môi trường staging


Ví dụ của AC với User story: là người dùng tôi muốn có thể tìm kiếm nhà với những thông tin địa chỉ.

  1. Thanh Tìm kiếm đặt trên cùng
  2. Cho phép người dùng tìm kiếm địa chỉ theo Tỉnh/Thành phố, Huyện/Quận, Xã/Phường. Mỗi trường này đều là select option cho phép người dùng tìm kiếm nhanh.
  3. Bắt đầu tìm kiếm khi người dùng nhấn vào ô “Tìm kiếm”
  4. Place holder là “Bạn muốn đi đâu?”
  5. Tìm kiếm dạng gần đúng
  6. Không hỗ trợ tìm kiếm những ký tự đặc biệt

Nguồn: scrum4dummies

Category
Methodology

Tags