Acceptance Criteria Là Gì? Cách Tạo AC Đơn Giản và Rõ Ràng

Cập nhật lần cuối vào 30/11/2023 bởi Nguyễn Quang Hoàng

Trong hành trình phát triển sản phẩm và quản lý dự án, Acceptance Criteria nổi lên như một yếu tố quyết định giữa thành công và thất bại. Đây không chỉ là những dòng yêu cầu khô khan; chúng là chìa khóa mở cánh cửa cho sự đồng thuận và hiểu biết chung.

Nhưng để tận dụng hết tiềm năng của chúng, chúng ta cần hiểu rõ không chỉ về “cách” chúng hoạt động mà còn về tầm quan trọng và cách tạo ra chúng một cách hiệu quả.

Hãy cùng khám phá hành trình này để biến Acceptance Criteria từ một khía cạnh kỹ thuật thành nghệ thuật làm cho dự án của bạn nổi bật và thành công.

Acceptance Criteria là gì?

Acceptance Criteria (AC) là một phần quan trọng của quy trình phát triển dự án, là tập hợp các điều kiện cụ thể mà một sản phẩm hoặc dịch vụ cần đáp ứng để được chấp nhận là hoàn thành và đáp ứng đúng yêu cầu của khách hàng hoặc bên mua. Đây là một công cụ quản lý chất lượng quan trọng, giúp định rõ và đo lường sự thành công của dự án.

Đặc điểm chính của Acceptance Criteria:

• Chỉ rõ và Cụ thể: Acceptance Criteria phải được mô tả một cách chi tiết và rõ ràng, không để lại diễn đạt mơ hồ, giúp mọi thành viên trong dự án hiểu đồng nhất về yêu cầu.

• Kiểm định Đạt hoặc Không đạt: AC giúp xác định cụ thể khi nào một tính năng hoặc sản phẩm được coi là đạt hoặc không đạt. Điều này giúp giảm sự hiểu lầm và mâu thuẫn trong quá trình đánh giá.
• Phản ánh Nhu cầu của Người Sử dụng: Các tiêu chí chấp nhận được đặc tả dựa trên nhu cầu và mong muốn của người sử dụng cuối cùng. Điều này đảm bảo rằng sản phẩm sẽ đáp ứng được mục tiêu kinh doanh và người dùng cuối cùng.
• Liên quan Trực tiếp đến Yêu cầu: AC thường phản ánh trực tiếp các yêu cầu chức năng và phi chức năng được xác định trước đó. Điều này giúp bảo đảm tính đầy đủ và toàn vẹn của hệ thống.
• Dựa trên Tiêu chuẩn Chất lượng: Các tiêu chí chấp nhận thường liên quan đến các tiêu chuẩn chất lượng cụ thể để đảm bảo rằng sản phẩm đáp ứng các yêu cầu về hiệu suất, bảo mật, và sự ổn định.
• Thay Đổi và Cập Nhật: AC không phải là cố định. Chúng có thể được điều chỉnh và cập nhật theo thời gian để phản ánh sự thay đổi trong yêu cầu hoặc mong muốn của khách hàng.

Acceptance Criteria không chỉ giúp đảm bảo rằng sản phẩm đáp ứng các tiêu chí chất lượng, mà còn là một công cụ quan trọng giúp tăng cường hiểu biết và giao tiếp giữa các bên liên quan trong dự án.

Mục Đích của Acceptance Criteria

Xác định Chuẩn Mực Chấp Nhận

Một trong những mục tiêu chính của Acceptance Criteria là mô tả một cách rõ ràng và chi tiết các điều kiện mà sản phẩm hay dịch vụ cần đáp ứng. Các điều kiện này thường liên quan đến chức năng, hiệu suất, và các yêu cầu khác được xác định từ trước.

Acceptance Criteria cũng giúp xác định ngưỡng chấp nhận, tức là giới hạn hoặc tiêu chí mà sản phẩm cần đạt đến để được chấp nhận. Điều này giúp đảm bảo rằng sản phẩm đáp ứng đúng và đủ các yêu cầu của khách hàng, đồng thời giúp người mua hàng hiểu rõ về mức độ chấp nhận của họ.

Tạo hiểu biết chung

Điều này bao gồm cả nhóm phát triển, bên mua, và những người quyết định trong dự án.

Bằng cách tạo ra một môi trường hiểu biết chung, Acceptance Criteria giúp đảm bảo rằng mọi người đều có cùng một cái nhìn về những gì sản phẩm hoặc dịch vụ cần đạt được.

Bên cạnh đó, Acceptance Criteria chính là công cụ để đảm bảo đồng nhất trong quá trình đánh giá sản phẩm và đưa ra quyết định chấp nhận. Các tiêu chí này tạo ra một khung làm việc chung cho việc kiểm tra và đánh giá, giúp mọi người đánh giá sản phẩm dựa trên cùng một tiêu chí.

Điều này làm giảm thiểu khả năng tranh cãi và tạo ra quyết định chấp nhận sản phẩm một cách công bằng và dựa trên các tiêu chí đã được xác định trước đó.

Hạn Chế Hiểu Lầm và Tranh Cãi

Bằng cách mô tả chi tiết và rõ ràng về những gì sản phẩm hoặc dịch vụ cần đáp ứng, AC giúp đảm bảo rằng mọi người trong dự án hiểu đúng về mục tiêu và yêu cầu của khách hàng.

Các tiêu chí chấp nhận được đặt ra trước khi sản phẩm hoặc dịch vụ được triển khai, giúp xác định ngưỡng chấp nhận cụ thể. Điều này giảm thiểu khả năng xung đột và tranh cãi về việc liệu sản phẩm có đáp ứng đúng yêu cầu hay không.

Bằng việc định rõ từ trước các tiêu chí, mọi bên liên quan có thể dựa vào một bộ chuẩn chung để đánh giá sản phẩm, đồng thời giảm sự không đồng nhất và tranh cãi trong quá trình chấp nhận.

Các Loại Cấu Trúc Acceptance Criteria

Acceptance Criteria, tùy thuộc vào tính chất của công việc và độ phức tạp của yêu cầu, có thể được mô tả theo nhiều định dạng khác nhau. Hai định dạng phổ biến nhất là scenario-oriented, sử dụng mẫu Given/When/Then, và rule-oriented, sử dụng mẫu checklist. Ngoài ra, có thể sử dụng định dạng tùy chỉnh phù hợp với nhu cầu cụ thể của dự án. Hãy đi sâu vào chi tiết của hai định dạng chủ đạo này:

Scenario-oriented acceptance criteria (Mẫu Given/When/Then):

Đúng như tên gọi, định dạng tiêu chí chấp nhận hướng kịch bản là loại tiêu chí chấp nhận được biểu diễn dưới dạng kịch bản và mô tả từng tiêu chí. Nó được tiếp cận thông qua chuỗi Given/When/Then (GWT) như sau:

• Given (Cho rằng): Mô tả trạng thái ban đầu hoặc điều kiện tiên quyết trước khi một hành động cụ thể xảy ra.
• When (Khi): Mô tả hành động hoặc sự kiện cụ thể mà người dùng thực hiện.
• Then (Thì): Chỉ định kết quả hoặc kết quả mong đợi sau khi hành động đó đã xảy ra.

Điều này được thừa hưởng từ phương pháp phát triển dựa trên hành vi (BDD) và cung cấp một cấu trúc nhất quán giúp người kiểm thử xác định khi nào bắt đầu và kết thúc kiểm thử cho một tính năng cụ thể. Nó cũng giảm thời gian viết các trường hợp kiểm thử vì hành vi của hệ thống được mô tả trước.

Mẫu tiêu chí chấp nhận trong định dạng này bao gồm các câu sau:

• Kịch Bản – Tên cho hành vi sẽ được mô tả.
• Given – Trạng thái ban đầu của kịch bản.
• When – Hành động cụ thể mà người dùng thực hiện.
• Then – Kết quả của hành động trong “When”.
• And – Được sử dụng để tiếp tục bất kỳ trong ba câu trước.

Khi kết hợp, những câu này bao gồm tất cả các hành động mà người dùng thực hiện để hoàn thành một công việc và trải nghiệm kết quả.

Ví Dụ 1: Quên mật khẩu

Người Dùng: Như một người dùng, tôi muốn có khả năng khôi phục mật khẩu của tôi, để có thể truy cập tài khoản của mình trong trường hợp tôi quên mật khẩu.

Mẫu Tiêu Chí Chấp Nhận Cho Việc Khôi Phục Mật Khẩu

• Kịch Bản: Quên mật khẩu
• Given: Người dùng di chuyển đến trang đăng nhập
• When: Người dùng chọn tùy chọn <quên mật khẩu>
• And: Nhập một địa chỉ email hợp lệ để nhận liên kết khôi phục mật khẩu
• Then: Hệ thống gửi liên kết đến email đã nhập
• Given: Người dùng nhận được liên kết qua email
• When: Người dùng di chuyển qua liên kết nhận được trong email
• Then: Hệ thống cho phép người dùng đặt mật khẩu mới

Rule-oriented acceptance criteria format (Sử dụng Checklist)

Trong một số trường hợp, việc đưa tiêu chí chấp nhận vào cấu trúc Given/When/Then có thể gặp khó khăn. Ví dụ, GWT sẽ khó ứng dụng trong các trường hợp sau:

• Bạn đang làm việc với các user story mô tả chức năng ở cấp độ hệ thống, cần các phương pháp kiểm thử chất lượng khác.
• Đối tượng của acceptance criteria không cần chi tiết chính xác của các kịch bản kiểm thử.
• Các kịch bản GWT không phù hợp với việc mô tả các ràng buộc thiết kế và trải nghiệm người dùng của một tính năng. Nhà phát triển có thể bỏ sót một số chi tiết quan trọng.

Trong những trường hợp như vậy, bạn có thể sử dụng định dạng rule-oriented acceptance criteria. 

Định dạng hướng quy tắc đòi hỏi rằng có một tập hợp các quy tắc mô tả hành vi của hệ thống. Dựa trên những quy tắc này, bạn có thể rút ra các kịch bản cụ thể.

Thường, tiêu chí được soạn thảo bằng cách sử dụng định dạng này trông giống như một danh sách đơn giản. Hãy xem xét một ví dụ.

Ví Dụ:

Người Dùng: Như một người dùng, tôi muốn có khả năng sử dụng ô tìm kiếm để nhập tên thành phố, tên đường, hoặc tên khách sạn, để có thể tìm kiếm các lựa chọn khách sạn phù hợp.

Tiêu Chí Chấp Nhận Cơ Bản Cho Giao Diện Tìm Kiếm:

• Ô tìm kiếm được đặt ở phía trên thanh điều hướng
• Tìm kiếm bắt đầu khi người dùng nhấp vào “Tìm kiếm”
• Ô chứa đoạn văn bản màu xám nhạt với văn bản: “Bạn đang đi đâu?”
• Đoạn văn bản mất đi khi người dùng bắt đầu nhập
• Tìm kiếm được thực hiện nếu người dùng nhập một thành phố, tên khách sạn, tên đường, hoặc tất cả kết hợp
• Tìm kiếm được thực hiện bằng tiếng Anh, tiếng Pháp, tiếng Đức, và tiếng Ukraina
• Người dùng không thể nhập hơn 200 ký tự
• Tìm kiếm không hỗ trợ ký tự đặc biệt. Nếu người dùng đã nhập ký tự đặc biệt, hiển thị thông báo cảnh báo: “Ô tìm kiếm không thể chứa ký tự đặc biệt.”

Như bạn có thể thấy từ ví dụ, định dạng tiêu chí chấp nhận hướng quy tắc có thể rất hiệu quả trong nhiều tình huống. Tuy nhiên, chúng không thể coi là một giải pháp toàn diện, và sử dụng chúng nên được xác định dựa trên bối cảnh cụ thể của dự án và đối tượng sử dụng cuối cùng.

Định Dạng Khác

Hầu hết câu chuyện người dùng có thể được bao phủ bằng hai định dạng được đề cập ở trên. Tuy nhiên, bạn có thể sáng tạo ra các tiêu chí chấp nhận của riêng mình miễn là chúng phục vụ mục đích của mình, được viết rõ ràng bằng tiếng Anh đơn giản và không thể bị hiểu lầm. Một số nhóm thậm chí sử dụng văn bản thuần túy.

Quy Trình Tạo Tiêu Chí Chấp Nhận

Có nhiều cơ hội để định nghĩa tiêu chí chấp nhận, bao gồm:

• Thảo luận với Khách Hàng hoặc Đối Tác: Mở rộng góc nhìn bằng cách thảo luận trực tiếp với khách hàng hoặc đối tác về những yêu cầu cụ thể và kỳ vọng của họ.
• Thảo luận với Các Bên Liên Quan: Kết nối với các bên liên quan để hiểu rõ hơn về các khía cạnh cụ thể mà họ quan tâm và đảm bảo sự đồng thuận.
• Trong Quá Trình Chỉnh Sửa Product Backlog: Trong quá trình tạo và chỉnh sửa Product Backlog, thảo luận về các điều kiện cụ thể để đạt được mục tiêu và sự hài lòng của người dùng.
• Trong Sự Kiện Lập Kế Hoạch Scrum Sprint: Trong sự kiện lập kế hoạch Sprint, thảo luận về acceptance criteria để đảm bảo rõ ràng về những gì cần đạt được trong kỳ Sprint đó.

• Trong buổi brainstorming: Sử dụng phiên Brainstorming để tìm kiếm ý kiến đa dạng từ các thành viên trong nhóm phát triển và đảm bảo rằng mọi người đều hiểu rõ về acceptance criteria.
• Sau Khi Đánh Giá Phản Hồi từ Khách Hàng hoặc Người Dùng Cuối: Tận dụng phản hồi từ khách hàng hoặc người dùng cuối để cập nhật và điều chỉnh acceptance criteria theo ý kiến và trải nghiệm thực tế.

Trên một đội Scrum, thường thì chủ sở hữu sản phẩm Product Owner có trách nhiệm viết những điều kiện chấp nhận này. Tuy nhiên, đội phát triển cũng cần và nên tham gia để đưa ra sự chuyên môn và phản hồi, đồng thời đảm bảo rằng họ đồng thuận với kỳ vọng của chủ sở hữu sản phẩm.

Scrum master cũng đóng vai trò hỗ trợ trong quy trình này bằng cách xác định sự mơ hồ có thể xuất hiện trong tiêu chí, giúp đội hiểu rõ mục đích của AC, và khuyến khích nhà phát triển nói lên nếu tiêu chí không rõ ràng.

Như vậy, đây là một công việc đồng đội, mặc dù thường thì sự gần gũi với khách hàng của chủ sở hữu sản phẩm sẽ là điểm xuất phát để tạo ra các tiêu chí này.

Người Chịu Trách Nhiệm Tạo Acceptance Criteria Là Ai?

Trên một dự án phần mềm, người chịu trách nhiệm viết tiêu chí chấp nhận thường là Chủ sở hữu Sản phẩm. Dưới đây là những lý do và vai trò chính của họ:

• Gần Gũi với Khách Hàng: Chủ sở hữu Sản phẩm thường có mối quan hệ gần gũi với khách hàng hoặc người sử dụng cuối cùng. Họ hiểu rõ những mong đợi và yêu cầu cụ thể của đối tượng sử dụng.
• Hiểu Biết Chi Tiết về Sản Phẩm: Chủ sở hữu Sản phẩm đảm bảo rằng họ có hiểu biết chi tiết về tính năng và chức năng cụ thể của sản phẩm. Điều này giúp họ có khả năng mô tả chi tiết và chính xác trong tiêu chí chấp nhận.
• Quyết Định Về Ưu Tiên: Chủ sở hữu Sản phẩm thường xác định những tính năng quan trọng và ưu tiên cho việc phát triển. Điều này giúp họ quyết định về việc viết tiêu chí cho những tính năng ưu tiên cao.
• Liên Kết Với Chiến Lược Sản Phẩm: Việc viết tiêu chí chấp nhận liên quan chặt chẽ đến chiến lược sản phẩm. Chủ sở hữu Sản phẩm có vai trò đảm bảo rằng tiêu chí phản ánh mục tiêu chiến lược của dự án.

Tuy nhiên, đôi khi người chịu trách nhiệm không chỉ là chủ sở hữu Sản phẩm. Trong môi trường Agile, đặc biệt là Scrum, đội phát triển cũng nên tham gia vào quá trình viết tiêu chí chấp nhận. 

Các lợi ích của việc này bao gồm:

• Chuyên Môn Hóa: Đội phát triển đem lại sự chuyên môn và kiến thức kỹ thuật để đảm bảo rằng tiêu chí chấp nhận là khả thi từ góc độ kỹ thuật và phản ánh đúng yêu cầu.
• Phản Hồi Tốt Hơn: Thông qua việc tham gia vào quá trình viết tiêu chí, đội phát triển có cơ hội để đưa ra ý kiến, góp ý và giúp làm rõ mọi mặt chi tiết kỹ thuật.
• Hiểu Biết Đồng Đội: Việc này giúp định rõ mục tiêu chung và tạo ra sự hiểu biết chung giữa các bên liên quan, từ chủ sở hữu Sản phẩm đến đội phát triển.

Nhìn chung, mặc dù chủ sở hữu Sản phẩm thường chịu trách nhiệm chính, việc tạo ra tiêu chí chấp nhận thực sự là một nỗ lực đồng đội, với sự hỗ trợ từ cả các bên liên quan khác trong quá trình phát triển phần mềm.

Các Lỗi Sai Cần Tránh Khi Tạo Acceptance Criteria

Mặc dù có nhiều cách để tùy chỉnh tiêu chí chấp nhận theo đội và ngữ cảnh của bạn, nhưng cũng có những sai lầm phổ biến mà thường đi ngược lại với mục đích của AC:

Bỏ Qua Quan Điểm của Người Dùng: Việc không xem xét quan điểm của người dùng là một lỗi lớn. Acceptance Criteria nên tập trung vào trải nghiệm người dùng và kỳ vọng của họ để đảm bảo sản phẩm đáp ứng nhu cầu thực tế.

Chỉ Đạo Nhà Phát Triển “Cách” Thực Hiện Công Việc: Việc chỉ định “cách” phát triển công việc có thể hạn chế sự sáng tạo và linh hoạt của đội phát triển. Acceptance Criteria nên tập trung vào “tại sao” và “điều gì” thay vì “làm thế nào.”

Viết Acceptance Criteria Quá Sớm: Việc viết tiêu chí chấp nhận quá sớm, trước khi có đủ thông tin, có thể dẫn đến sự hiểu lầm và cần phải điều chỉnh sau này.

Chờ Đến Khi Phát Triển Đã Bắt Đầu Trong Sprint Mới Viết Acceptance Criteria: Chờ đến khi sprint đã bắt đầu để viết tiêu chí chấp nhận có thể làm tăng nguy cơ thiếu rõ ràng và gây hiểu lầm trong quá trình phát triển.

Tiêu Chí Quá Rộng: Acceptance Criteria quá rộng có thể dẫn đến hiểu lầm về phạm vi và yêu cầu cụ thể của tính năng hoặc sản phẩm.

Tiêu Chí Mơ Hồ: Việc viết mơ hồ, không rõ ràng làm tăng khả năng hiểu lầm và tranh cãi sau này.

Số Lượng Tiêu Chí Quá Nhiều: Một lượng lớn tiêu chí có thể gây khó khăn trong việc quản lý và theo dõi. Điều này có thể là dấu hiệu cần phải chia nhỏ công việc thành các phần nhỏ hơn.

Hầu hết các chuyên gia Agile đều nhận thức rằng để hưởng lợi tốt nhất từ Acceptance Criteria, chúng cần được viết một cách rõ ràng, tập trung vào trải nghiệm người dùng và kỳ vọng của khách hàng.

So Sánh Acceptance Criteria và Definition of Done trong Quản Lý Dự Án

Acceptance Criteria và Definition of Done là hai khái niệm quan trọng trong quản lý dự án, đặc biệt là trong ngữ cảnh của các phương pháp phát triển như Agile và Scrum. Dưới đây là một so sánh giữa chúng:

Tóm lại, Acceptance Criteria tập trung vào yêu cầu cụ thể của tính năng hoặc sản phẩm, trong khi Definition of Done thiết lập tiêu chuẩn chung cho tất cả các công việc trong dự án. Cả hai đều quan trọng để đảm bảo chất lượng và sự hiểu biết đồng nhất trong đội ngũ.

Kết luận

Acceptance Criteria đóng vai trò quan trọng trong quản lý dự án, nhưng để hạn chế rủi ro và đảm bảo hiệu quả, cần tránh những lỗi thường gặp. Bao gồm việc tập trung vào trải nghiệm người dùng, không chỉ định “cách” thực hiện công việc, và viết tiêu chí ở thời điểm phù hợp.

Quá trình tạo Acceptance Criteria đòi hỏi sự hợp tác chặt chẽ và linh hoạt giữa các bên liên quan. Khi viết, hãy giữ nó đơn giản, rõ ràng và tập trung vào mục tiêu cuối cùng: đảm bảo sự đồng thuận và thành công của dự án. Acceptance Criteria không chỉ kiểm soát chất lượng mà còn là nghệ thuật diễn đạt ý kiến và yêu cầu, tạo ra một quá trình phát triển mạnh mẽ và hiệu quả.