Definition of Done  và Acceptance Criteria (AC) là hai khái niệm quan trọng trong quản lý dự án, đặc biệt là trong các phương pháp Agile. Mặc dù cả hai đều liên quan đến việc xác định khi nào một công việc được coi là hoàn thành, chúng có mục đích và phạm vi khác nhau.

Đọc thêm: https://www.visual-paradigm.com/scrum/definition-of-done-vs-acceptance-criteria/#:~:text=Definition%20of%20Done%20(DoD)%20is,software%20is%20working%20as%20expected.

I. Definition of Done là gì? Mục đích và phạm vi của DoD?

1. Định nghĩa của Definition of Done (Định nghĩa hoàn thành)

Theo Scrum Guide 2022, Definition of Done (DoD) được định nghĩa như sau:

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”

(Tạm dịch: “Định nghĩa hoàn thành (DoD) là một mô tả chính thức về trạng thái của Increment (phần tăng trưởng) khi nó đáp ứng các thước đo chất lượng cần thiết cho sản phẩm.”)

• Increment: Là phần công việc hoàn thành trong một Sprint, có thể release được và đáp ứng các tiêu chí chất lượng của sản phẩm.
• DoD là một công cụ để xác định khi nào một Increment được coi là hoàn thành và sẵn sàng để release.

https://resources.scrumalliance.org/Article/product-increment

2. Vai trò của DoD trong Scrum

a. Tạo sự minh bạch

• DoD giúp tạo sự minh bạch bằng cách cung cấp cho tất cả các bên liên quan (nhóm phát triển, Product Owner, Scrum Master, và khách hàng) một sự hiểu biết chung về những gì được coi là “hoàn thành”.
• Khi một Product Backlog Item (Product Backlog Item) đáp ứng DoD, nó trở thành một phần của Increment và có thể được trình bày tại Sprint Review.

b. Đảm bảo chất lượng

• DoD đảm bảo rằng tất cả các Increment đều đáp ứng các tiêu chuẩn chất lượng của sản phẩm.
• Nếu một Product Backlog Item không đáp ứng DoD, nó không thể được release hoặc thậm chí không được trình bày tại Sprint Review. Thay vào đó, nó sẽ được đưa trở lại Product Backlog để Product Owner xem xét trong tương lai.

c. Hỗ trợ quyết định release

• Khi một Increment đáp ứng DoD, nó có thể được release ngay lập tức (nếu cần thiết) mà không cần thêm công việc nào khác.
• Điều này giúp nhóm phát triển và Product Owner linh hoạt trong việc quyết định khi nào release sản phẩm.

3. Definition of Done được tạo ra và sử dụng thế nào

• Nếu doanh nghiệp/tổ chức đã có sẵn một DoD chung, tất cả các nhóm Scrum trong tổ chức đó phải tuân thủ DoD này ở mức tối thiểu.
• Điều này đảm bảo sự thống nhất về chất lượng sản phẩm trên toàn bộ tổ chức.
• Nếu tổ chức không có sẵn DoD, nhóm Scrum sẽ tự tổ chức và tạo ra DoD của riêng mình.
• DoD của nhóm phải phù hợp với sản phẩm và đáp ứng các tiêu chí chất lượng cần thiết.
• Ví dụ về các tiêu chí trong DoD của nhóm:
  • Code đã được review và approved.
  • Unit tests đã được viết và passed.
  • Tài liệu đã được cập nhật.
  • Công việc đã được triển khai lên môi trường staging.
• Increment là kết quả của một Sprint, bao gồm tất cả các Product Backlog Items đã hoàn thành và đáp ứng DoD.
• Khi một Product Backlog Item đáp ứng DoD, nó trở thành một phần của Increment và có thể được release.
• Thời điểm Product Backlog Items đáp ứng DoD chính là thời điểm Increment được sinh ra.
• Khi nói đến DoD, người ta thường nghĩ ngay đến các tiêu chí về chất lượng vì:
  • DoD đảm bảo rằng sản phẩm đáp ứng các tiêu chuẩn chất lượng trước khi được release.
  • Các tiêu chí như code review, unit tests, và kiểm thử tích hợp đều nhằm mục đích nâng cao chất lượng sản phẩm.
  • DoD giúp tránh tình trạng “hoàn thành một nửa” hoặc “chưa sẵn sàng để release”.

4. Ví dụ về DoD

Dưới đây là một ví dụ cụ thể về DoD:

1. Code đã được review và approved:
   • Tất cả code mới phải được review bởi ít nhất một thành viên trong nhóm.
2. Unit tests đã được viết và passed:
   • Unit tests phải bao phủ ít nhất 80% code.
3. Tài liệu đã được cập nhật:
   • Tài liệu kỹ thuật và hướng dẫn sử dụng phải được cập nhật.
4. Công việc đã được triển khai lên môi trường staging:
   • Tính năng phải được triển khai và kiểm thử trên môi trường staging

II. Acceptance Criteria là gì? Mục đích và phạm vi của AC?

1. Định nghĩa của Acceptance Criteria (AC)

Acceptance Criteria (AC) là một tập hợp các điều kiện cụ thể mà một Product Backlog Item (PBI) hoặc User Story phải đáp ứng để được coi là hoàn thành và chấp nhận bởi Product Owner hoặc khách hàng.

• Mục đích: AC giúp làm rõ yêu cầu của từng User Story, đảm bảo rằng nhóm phát triển và Product Owner có cùng một hiểu biết chung về những gì cần được thực hiện.

2. Vai trò của Acceptance Criteria trong Scrum

a. Làm rõ yêu cầu

• AC giúp làm rõ yêu cầu của từng User Story bằng cách cung cấp các tiêu chí cụ thể mà tính năng cần đáp ứng.
• Ví dụ: Đối với User Story “Người dùng có thể đăng nhập”, AC có thể bao gồm:
  • Người dùng nhập email và mật khẩu để đăng nhập.
  • Hệ thống hiển thị thông báo lỗi nếu thông tin đăng nhập không chính xác.
  • Người dùng có thể nhấn “Quên mật khẩu” để nhận email reset mật khẩu.

b. Đảm bảo sự đồng thuận

• AC giúp đảm bảo rằng nhóm phát triển và Product Owner có cùng một hiểu biết chung về yêu cầu của User Story.
• Điều này giúp tránh hiểu lầm và đảm bảo rằng tính năng được xây dựng đúng như mong đợi.

c. Hỗ trợ kiểm thử

• AC là cơ sở để tạo ra các test case cho việc kiểm thử chức năng.
• Ví dụ: Dựa trên AC của User Story “Đăng nhập”, nhóm QA có thể tạo các test case như:
  • Kiểm tra đăng nhập thành công với email và mật khẩu hợp lệ.
  • Kiểm tra thông báo lỗi khi nhập sai mật khẩu.
  • Kiểm tra tính năng “Quên mật khẩu”.

3. Acceptance Criteria được tạo ra và sử dụng thế nào?

• Product Owner là người chịu trách nhiệm chính trong việc xác định AC, vì họ là người hiểu rõ nhất yêu cầu của khách hàng và nghiệp vụ.
• Tuy nhiên, nhóm phát triển cũng tham gia vào quá trình này để đảm bảo rằng AC là khả thi về mặt kỹ thuật và phù hợp với khả năng của nhóm.
• AC được sử dụng trong quá trình lập kế hoạch Sprint (Sprint Planning) để giúp nhóm hiểu rõ yêu cầu của từng User Story.
• AC cũng được sử dụng trong quá trình phát triển để hướng dẫn nhóm xây dựng tính năng đúng yêu cầu.
• Cuối cùng, AC được sử dụng trong quá trình kiểm thử để xác nhận rằng tính năng đã đáp ứng đúng yêu cầu.

4. Ví dụ cụ thể về Acceptance Criteria

Dưới đây là một ví dụ cụ thể về AC cho User Story “Người dùng có thể đăng nhập”:

1. Đăng nhập thành công:
   • Người dùng nhập email và mật khẩu hợp lệ.
   • Hệ thống chuyển hướng người dùng đến trang dashboard.
2. Đăng nhập thất bại:
   • Người dùng nhập email hoặc mật khẩu không chính xác.
   • Hệ thống hiển thị thông báo lỗi “Email hoặc mật khẩu không đúng”.
3. Quên mật khẩu:
   • Người dùng nhấn nút “Quên mật khẩu”.
   • Hệ thống gửi email chứa liên kết reset mật khẩu đến địa chỉ email đã đăng ký.

5. Sự khác biệt giữa Acceptance Criteria và Definition of Done

• Acceptance Criteria (AC):
  • Áp dụng cho từng User Story cụ thể.
  • Xác định các điều kiện cụ thể mà User Story phải đáp ứng để được chấp nhận.
• Definition of Done (DoD):
  • Áp dụng cho toàn bộ nhóm và mọi công việc.
  • Xác định các tiêu chuẩn chung về chất lượng và hoàn thiện.

⇒ Một User Story chỉ được coi là hoàn thành khi nó đáp ứng cả Acceptance Criteria (yêu cầu cụ thể) và Definition of Done (tiêu chuẩn chung về chất lượng).

6. Tại sao Acceptance Criteria quan trọng?

• Giảm thiểu rủi ro: AC giúp tránh việc xây dựng sai tính năng hoặc bỏ sót các yêu cầu quan trọng.
• Tăng tính minh bạch: AC làm rõ yêu cầu của từng User Story, giúp tất cả các bên liên quan hiểu rõ những gì cần được thực hiện.
• Hỗ trợ kiểm thử: AC là cơ sở để tạo ra các test case, đảm bảo rằng tính năng được kiểm thử đầy đủ.

III. Sự khác biệt giữa DoD và Acceptance Criteria