1. AC (Acceptance Criteria) là gì:
Trong Agile, AC là một tập các yêu cầu được define cần phải đạt từ góc độ người dùng khi một user story được coi là Done . Mỗi User story sẽ có một hoặc nhiều Acceptance criteria, nên tối đa là 3, nhiều hơn thì nên chia nhỏ user story
Thông thường, PO là người có trách nhiệm verify AC của user story, PO sẽ kết hợp với development team để thực hiện viết AC trước khi backoog item được đưa vào sprint planning
“Pre-established standards or requirements a product or project must meet.” _Google
2. Mục đích của Accpetance Criteria:
- Quản lý được những mong muốn của user story, giúp team hiểu rõ cái gì trong yêu cầu, cái gì nằm ngoài yêu cầu
- Xác định scope rõ ràng hơn và giảm thiểu những mơ hồ
- Hạn chế những thay đổi gây ảnh hưởng tới sprint khi sprint active
- Giúp QA có thể verify lại nếu như tính năng đúng với yêu cầu của người dùng
3. Thời gian viết Acceptance Criteria:
Có thể bắt đầu càng sớm càng tốt, muộn nhất là trước khi quá trình thực thi ticket được bắt đầu, tức là trước planning 1, thậm chí khuyến khích trước cả Refinement. Trong khi planning, bạn có thể bổ sung, tuy nhiên sẽ không phải là sprint planning mới bắt đầu viết AC. Sau buổi planning thì AC sẽ không được tự động update mà không có thông báo tới các thành viên của team.
4. Ai sẽ viết Accpetance Criteria:
Trong một cross-functional team, mọi người đều có thể viết được AC. Thông thường PO hoặc Manager sẽ chịu trách nhiệm viết AC trước, hoặc ít nhất là khởi tạo thảo luận để tạo AC, đây là những người hiểu rõ và đúng nhất về nhu cầu của người dùng tính năng. Tuy nhiên không hạn chế việc các thành viên khác có thể viết để cùng hoàn thiện AC, để cung cấp các góc nhìn khác nhau về tính năng sản phẩm.
PO hoặc PE sẽ thực hiện verify lại AC đảm bảo backlog item được người dùng chấp nhận và cùng hiểu đúng về backlog item .
5. Format cho AC:
Không có một format nào đúng hoặc sai trong cách viết AC của một user story, hãy lựa chọn một format phù hợp
Có 2 format chính để viết AC:
5.1. Hướng ngữ cảnh ( Given/ When/ Then) - Scenario oriented (GWT)
- Ngữ cảnh: tên của hành vi ngữ cảnh
- Given: Trạng thái đầu của ngữ cảnh
- When: Một hành động mà người dùng thực hiện
- Then: Outcome của hành động tại When
- And: Sử dụng khi mỗi thành phần GWT cần có nhiều hơn 1
Ví dụ:
Như là một user, tôi muốn lấy lại mật khẩu của tôi, để tôi có thể login lại tài khoản
AC của user story sẽ như sau:
Ngữ cảnh: Quên mật khẩu
Given: User được điều hướng vào trang Login
When: Khi user click vào nút 'Forgot Password' , hiển thị ô nhập email,
And: User nhập email hợp lệ vào ô địa chỉ
Then: User nhận được email từ hệ thống tới email ở trên
5.2 Hướng theo rule (Rule oriented) :
Trong một số trường hợp, format theo hướng ngữ cảnh có thể không phù hợp như là AC cho 1 user story đòi hỏi về mặt UX hay design, hoặc một user story không cần check về mặt ngữ cảnh
Ví dụ:
User story:
Là 1 user, tôi muốn sử dụng phần ô search để input postal code của tôi, như vậy tôi có thể tìm thấy những gian hàng trong khu vực đó
Acceptance Criteria sẽ như sau:
- Phần placeholders biến mất khi user bắt đầu nhập kí tự
- Phần tìm kiếm bắt đầu thực hiện khi user bấm vào phím Enter trên bàn phím hoặc bấm vào nút Tìm kiếm
- Phần kí tự input chỉ chấp nhận chữ số
- Số lượng kí tự input không được nhiều hơn 8 kí tự
- ...
6. Một AC được coi là hiệu quả:
- Các AC có thể dễ dàng test được, kết quả có thể nhìn thấy ngay chứ không cần cài cắm hoặc diễn dải bằng những thuật ngữ, triết lý, tài liệu dài dòng hàn lâm, chỉ đơn giản là pass hoặc không pass khi follow theo AC
- AC cần rõ ràng và ngắn gọn, không nênđi kèm những từ phủ định như "không", vì sẽ gây ra nhiều case theo các cách hiểu khác nhau
ví dụ: "Form đăng nhập không nên nhấp nháy đỏ khi người dùng nhập kí tự sai" nên " Những ô input trong form đăng nhập sẽ được set border màu đỏ và có chú thích khi người dùng nhập sai kí tự" - Mọi người cần được hiểu được: AC khi bạn viết mà developer không hiểu thì AC đó không hữu dụng, nếu từ bản thân người viết AC vẫn mơ hồ thì nên clear rõ ràng, tránh viết chung chung như kiểu, giống một chức năng nào đó ở đâu đó
- Nên sử dụng ngôn ngữ hành động hành động . Ví dụ thay vì viết " Bộ lọc A cần được thực hiện trong chức năng search" hãy cung cấp thêm thông tin "Người dùng sử dụng bộ lọc A để tìm kiếm được những sản phẩm đạt tiêu chí..."
- AC nên viết dưới góc nhìn của người sử dụng: Nên viết dưới dạng hành vi sử dụng của người dùng, với tính năng đó hành vi của người dùng sẽ như nào, họ mong muốn ra sao
- AC không nên quá hẹp cũng không nên quá rộng
0 comments:
Post a Comment