Acceptance Criteria

Khi tôi làm việc với khách hàng của tôi, những người bắt đầu sử dụng Agile, một trong những mục tiêu tôi xem đầu tiên là backlog - công việc tồn đọng của họ. Bởi vì khối lượng backlog cho thấy rằng team sẽ thực hiện chỉ thị như thế nào. Nhưng hầu hết các backlog được tạo bởi product owners đều không được phát triển bởi team, và một trong số lý do của việc này là do bỏ qua acceptance criteria trong user stories.

• Acceptance criteria là quan trọng, nhưng chúng ta thường bỏ qua hoặc đánh giá thấp nó như nó chỉ là 1 khía cạnh của quá trình lập kế hoạch lặp đi lặp lại. Bởi vì các dự án thành công hay thất bại đều dựa vào khả năng của nhóm có đáp ứng được yêu cầu của khách hàng hay không.
• Khi xác định rõ các tiêu chí ngay từ đầu thì sau này team sẽ đảm bảo chất lượng sản phẩm và độ hài lòng của khách hàng cao hơn. Và quan trọng là chúng ta sẽ trả lời câu hỏi: Xây dựng đúng sản phẩm chưa? Và Xây dựng sản phẩm đã đúng chưa?

• What are acceptance criteria
• Why they are important
• When they work well
• How to create them

What are Acceptance Criteria?

Acceptance criteria là các điều kiện mà phần mềm cần thỏa mãn yêu cầu của người dùng, khách hàng.

• Nó là 1 tập hợp các statements, với mỗi statement sẽ có kết quả pass/fail. Hoặc là các tiêu chí được đáp ứng hoặc là không.
• Acceptance criteria là các statement của yêu cầu được mô tả từ quan điểm của người dùng để phán xét khi kịch bản đã được hoàn thành với công việc mong muốn.

=> Điều này giúp team giảm các risk bởi thử nghiệm các tiêu chí khi mà nhóm chấp nhận công việc. Acceptance criteria đang phát triển và đủ linh hoạt để thay đổi khi team bắt đầu thực hiện story. Bất cứ ai trong nhóm nhà phân tích kinh doanh, QA và các nhà phát triển đều có thể giúp project owner tạo và review acceptance criteria.

When to define our Acceptance Criteria?

Acceptance criteria sẽ được viết trước khi thực hiện dự án. Điều này sẽ giúp chúng ra nắm bắt được ý định của khách hàng hơn. Nên khuyến khích team viết ra tiêu chí trước khi bắt đầu phát triển để chắc chắn rằng các chức năng đáp ứng nhu cầu của khách hàng.

What makes good Acceptance Criteria?

Acceptance criteria sác định khi sản phẩm hoàn thành và đúng như mong đợi. Các tiêu chí được thể hiện qua ngôn ngữ đơn giản, không có sự mơ hồ về kết quả. Vì ngôn ngữ này sẽ được dịch sang các trường hợp thử nghiệm tự động để chạy, ngay cả trong quá trình tích hợp liên tục.

WHAT. Not HOW.

Như thế nào là “cái bẫy”. Các tiêu chí nên nêu ý định chứ không phải là một giải pháp. Các tiêu chí nên độc lập với việc thực hiện, và thảo luận CÁI GÌ để mong đợi chứ không phỉa LÀM THẾ NÀO để thực hiện.

Formats

Định dạng Given/When/Then giúp xác định các tiêu chí: Given: 1 vài điều kiện When : Tôi làm 1 vài hành động Then: Tôi mong muốn 1 vài kết quả

• Khi viết acceptance criteria theo đúng format nó cung cấp 1 cấu trúc nhất quán. Ngoài ra nó còn giúp người kiểm tra xác định thời điểm bắt đầu và kết thúc công việc.
• Đôi khi rất khó để xây dựng acceptance criteria theo format: Given/When/Then. Đặc biệt là khi giải quyết công việc với user stories của hệ thống. Trong trường hợp này thì nên sử dụng checklist để xác minh công việc.
• Một ưu điểm nữa của checklist đó là giúp chúng ra đánh dấu được những chức năng đã được thực hiện.

Who Writes Acceptance Criteria and When?

• Khách hàng hoặc nhóm DEV sẽ viết acceptance criteria. Nhưng theo nguyên tắc thì người viết sẽ là product owner và người review sẽ là thành viên trong đội DEV để đảm bảo rằng các tiêu chí được đã rõ ràng và không có ràng buộc hay mâu thuẫn phát triển nào...Đó cũng là 1 cách tuyệt vời để KH có thêm kinh nghiệm trong việc viết tài liệu dự án.

• Nếu bạn muốn assign cho nhóm DEV viết acceptance criteria, thì chuyên gia thiết kế yêu cầu, project manager hay QA nên giải quyết vấn đề này, vì họ biết về ký thuật ngăn xếp và tính khả thi của các tính năng hơn.

=> Hãy nhớ rằng acceptance criteria nên được xác định trước và không bao giờ để sau khi giai đoạn phát triển bắt đầu. Do đó, team và product owner nên thỏa thuận về mức độ tối thiểu chấp nhận sản phẩm.

Advantages of Acceptance Criteria:

• Nghiên cứu xem tính năng sẽ hoạt động như thế nào từ quan điểm người dùng cuối
• Giúp team viết ra test case chính xác và hiểu rõ hệ thống
• Loại bỏ phạm vi không cần thiết mà vẫn giữ đúng nội dung

Creating Acceptance Criteria

Khách hàng thường muốn một email gửi đến địa chỉ email của tôi khi tài khoản của anh ta bị chi quá tiền, để thông báo cho tôi chuyển thêm tiền vào tài khoản.

Ở ví dụ trên, acceptance criteria là một tập các ràng buộc thể hiện cho "điều kiện thỏa mãn". Nó còn chứa các ràng buộc và các tham số quyết định xem khi nào thì công việc hoàn thành và sẵn sàng được chấp thuận.

• Nó được thể hiện rõ ràng bằng ngôn ngữ của khách hàng mà không có sự mập mờ nào trong việc diễn tả các điều kiện đầu ra.
• Nó phải được dễ dàng chuyển đổi thành một hoặc nhiều test case thủ công/tự động.

Khi đội phát triển hoàn thành user story họ sẽ trình bày với Product Owner về các yêu cầu được thỏa mãn như thế nào. Một tiêu chí chấp nhận gồm có 3 phần:

• Input
• Process
• Outcome

Một cách hữu hiệu để mô tả một điều kiện chấp nhận là: When I <input> X and <process> Y, I will check for <outcome> as the result

• Phần input: là các thứ kiểu như "nhập giá trị này và nhấn vào nút kia" hay "nhập lệnh và kiểm tra kết quả"
• Phần process: là các tính toán kiểm tra thực sự. Bình thường khi ta tạo một user story, ta sẽ muốn một số xử lý được thực hiện trên tập input của user. Quá trình này, dù thường không thể quan sát trực tiếp, có thể được kiểm chứng bởi một tập input và output mong muốn.
• Phần outcome: hay kết quả nên được viết để có thể test được với ít mơ hồ nhất có thể.

Trên đây là một số khái niệm về acceptance criteria và cách tạo acceptance criteria cơ bản để các bạn thâm khảo và hiểu hơn về acceptance criteria.

Bài tìm hiểu và dịch tham khảo link : http://www.payton-consulting.com/user-stories-create-acceptance-criteria/ https://www.leadingagile.com/2014/09/acceptance-criteria/