1. “Definition of Done là một mô tả chính thức về trạng thái của Increment khi nó đáp ứng các tiêu chí chất lượng được yêu cầu cho sản phẩm.”(Translation: “Definition of Done (DoD) là một mô tả chính thức về trạng thái của Increment khi nó đáp ứng các tiêu chí chất lượng cần thiết cho sản phẩm.”)Increment: Thuật ngữ này đề cập đến phần công việc đã hoàn thành trong một Sprint, có thể phát hành 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 xem là hoàn thành và sẵn sàng để phát hành.

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

    1. Vai trò của DoD trong Scrum a. Tạo ra tính minh bạch
      DoD giúp tạo ra tính 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 cách hiểu chung về thế nào là “hoàn thành”.
      Khi một 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 trong 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 phát hành hoặc thậm chí trình bày trong 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 phát hành
      Khi một Increment đáp ứng DoD, nó có thể được phát hành ngay lập tức (nếu cần) mà không cần thêm bất kỳ công việc bổ sung nào.
      Điều này cho phép nhóm phát triển và Product Owner linh hoạt trong việc quyết định thời điểm phát hành sản phẩm.
    2. Definition of Done được tạo ra và sử dụng như thế nào

      Nếu một doanh nghiệp/tổ chức đã có DoD chung, tất cả các nhóm Scrum trong tổ chức đó phải tuân theo DoD này ở mức tối thiểu.
      Điều này đảm bảo tính nhất quán về chất lượng sản phẩm trong toàn bộ tổ chức.

      Nếu tổ chức không có DoD sẵn có, nhóm Scrum sẽ tự tổ chức và tạo ra DoD của riêng họ.
      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 một nhóm:

    • Mã nguồn đã được review và phê duyệt.
    • Unit test đã được viết và chạy thành công.
    • 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 Item đã 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 phát hành.
    Thời điểm các Product Backlog Item đáp ứng DoD chính là thời điểm Increment được tạo ra.
    Khi nói đến DoD, mọi người thường nghĩ đến các tiêu chí 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 phát hành.
    Các tiêu chí như review mã nguồn, unit test và kiểm thử tích hợp nhằm nâng cao chất lượng sản phẩm.
    DoD giúp tránh các tình huống “hoàn thành dở dang” hoặc “chưa sẵn sàng để phát hành”.

    1. Example of DoD
      Dưới đây là một ví dụ cụ thể về DoD:
    • Mã nguồn đã được review và phê duyệt: Tất cả mã nguồn mới phải được review bởi ít nhất một thành viên trong nhóm
    • Unit test đã được viết và chạy thành công: Unit test phải bao phủ ít nhất 80% mã nguồn.
    • Tài liệu đã được cập nhật: Tài liệu kỹ thuật và hướng dẫn người dùng phải được cập nhật.
    • Công việc đã được triển khai lên môi trường staging: Các tính năng phải được triển khai và kiểm thử trong môi trường staging.

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

    1. Định nghĩ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 xem là hoàn thành và được Product Owner hoặc khách hàng chấp nhận.

    Mục đích: AC giúp làm rõ các 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 cách hiểu về những gì cần phải hoàn thành.

    Vai trò của Acceptance Criteria trong Scrum

    a. Làm rõ yêu cầu
    AC giúp đảm bảo rằng nhóm phát triển và Product Owner có cùng một cách hiểu 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.

    • 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 đặt lại 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 cách hiểu 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 đóng vai trò là cơ sở để tạo các test case cho 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 thử đăng nhập thành công với email và mật khẩu hợp lệ.
    • Kiểm thử thông báo lỗi khi nhập sai mật khẩu.
    • Kiểm thử chức năng “Quên mật khẩu”.

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

    Product Owner chịu trách nhiệm chính trong việc định nghĩa AC, vì họ hiểu rõ nhất các yêu cầu của khách hàng và nhu cầu kinh doanh.
    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 khả thi về mặt kỹ thuật và phù hợp với năng lực của nhóm.

    AC được sử dụng trong quá trình 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 theo đú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 các yêu cầu.

    4. Specific Example of 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”:

    Đăng nhập thành công:

    • Users enter a valid email and password.
    • The system redirects the user to the dashboard page.

    Đă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 chính xác”

    Quên mật khẩu:

    • Người dùng bấm vào nút “Quên mật khẩu”.
    • Hệ thống gửi email chứ liên kết đặt lại 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ể.
    • Định nghĩa các điều kiện cụ thể mà một 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à tất cả công việc.
    • Định nghĩa các tiêu chuẩn chung về chất lượng và mức độ hoàn thành.

    ⇒ Một User Story chỉ được xem 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 chất lượng chung).

    6. Tại sao Acceptance Criteria lại 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 thực hiện.
    • Hỗ trợ kiểm thử: AC cung cấp cơ sở để tạo test case, đảm bảo rằng tính năng được kiểm thử đầy đủ.

III. The Sự khác biệt giữa Definition of Done (DoD) và Acceptance Criteria (AC)

Tiêu Chí Definition of Done (DoD) Acceptance Criteria (AC)
Định Nghĩa Một mô tả chính thức về trạng thái của Increment khi nó đáp ứng các tiêu chuẩn chất lượng. Những điều kiện cụ thể mà một User Story phải đáp ứng để được Product Owner chấp nhận.
Phạm Vi Áp dụng cho toàn bộ đội và tất cả công việc liên quan đến Product Backlog Items & Product Increment (User Story, Sprint, hoặc toàn bộ dự án). Áp dụng cho mỗi User Story cụ thể.
Mục Đích Để đảm bảo chất lượng tổng thể và tính hoàn chỉnh của công việc. Để đảm bảo rằng User Story đáp ứng các yêu cầu cụ thể của khách hàng hoặc Product Owner.
Tính Chất Tổng quát, rộng, áp dụng cho tất cả User Stories trong một Sprint. Cụ thể, chi tiết, phụ thuộc vào mỗi User Story.
Ai Định Nghĩa/Tạo Ra? Toàn bộ Scrum team (bao gồm Developers, Product Owner, Scrum Master). Product Owner (với đóng góp từ development team).
Khi Nào Sử Dụng? Vào cuối mỗi Sprint hoặc khi hoàn thành một phần công việc để xác nhận chất lượng. Trong Sprint planning và quá trình phát triển User Story.
Tính Linh Hoạt Ổn định, hiếm khi thay đổi trừ khi đội quyết định điều chỉnh tiêu chuẩn chất lượng. Linh hoạt, thay đổi theo từng User Story hoặc yêu cầu của khách hàng.
Liên Quan Đến Chất Lượng Tập trung vào đảm bảo chất lượng tổng thể của sản phẩm. Tập trung vào việc đáp ứng các yêu cầu cụ thể của mỗi User Story.
Kết Quả Increment đáp ứng các tiêu chuẩn chất lượng và sẵn sàng để phát hành. User Story được Product Owner chấp nhận.

Ví dụ

DoD bao gồm:

  1. Mã nguồn đã được review và phê duyệt:
    • Tất cả mã nguồn mới phải được review bởi ít nhất một thành viên trong nhóm.
  2. Unit test đã được viết và chạy thành công:
    • Unit test phải bao phủ ít nhất 80% mã nguồn.
    • Tất cả các test case phải pass
  3. Tài liệu đã được cập nhật:
    • Tài liệu kỹ thuật và hướng dẫn người dùng phải được cập nhật.
  4. Kiểm thử tích hợp:
    • Tính năng đăng nhập phải được kiểm thử tích hợp với các hệ thống liên quan (ví dụ: hệ thống xác thực, dịch vụ email).
  5. Triển khai lên môi trường staging:
    • Tính năng phải được triển khai và kiểm thử trong môi trường staging.
  6. Không có lỗi nghiêm trọng.

DoD chung cho tất cả User Story trong Sprint..
User Story 1: Là một người dùng, tôi muốn đăng nhập vào hệ thống bằng email và mật khẩu để truy cập tài khoản của mình.

AC bao gồm:

  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. Failed login:
    • 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 chính xác”.
  3. Forgot password:
    • 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 đặt lại mật khẩu đến địa chỉ email đã đăng ký.
  4. Security:
    • Mật khẩu phải được mã hóa khi lưu trong cơ sở dữ liệu.
    • Hệ thống phải chặn đăng nhập sau 5 lần đăng nhập thất bại liên tiếp.

Mỗi User Story yêu cầu các Acceptance Criteria khác nhau phải được viết ra.