Khác biệt giữa tiêu chí hoàn thành DOD (Definition of Done) với tiêu chí nghiệm thu (Acceptance Criteria)
Definition of Done (DoD) là một danh sách các yêu cầu mà các user story phải tuân theo để nhóm được xác nhận là hoàn thành một công việc. Trong khi đó Acceptance Criteria (tiêu chí chấp nhận) của một User Story bao gồm một danh sách các kịch bản kiểm thử cần được đáp ứng để xác nhận rằng “phần mềm” hoạt động giống như “kỳ vọng – hay yêu cầu” của khách hàng.
Sự khác biệt giữa DoD và AC ở chỗ: DoD là những yêu cầu chung nhất cho tất cả các User Story, trong khi đó AC sẽ được áp dụng cho những User Story cụ thể. Acceptance Criteria của mỗi User Story sẽ khác nhau, dựa trên yêu cầu của mỗi User Story.
DoD là tiêu chí cho nghiệm thu hạng mục công việc theo thời gian và khối lượng, phù hợp với hợp đồng T&M (Time and Material). AC là tiêu chí cho nghiệm thu toàn phần (các tính năng đã tích hợp và lắp ghép hoàn chỉnh, dữ liệu được liên thông). AC không thuộc vào một loại hợp đồng cụ thể nào. AC áp dụng cho mọi loại dự án.
Nói một cách khác, cả DoD và AC phải được đáp ứng để hoàn thành User Story. Phần tăng trưởng của sản phẩm không được xem là “hoàn thành”, trừ khi cả 2 danh sách này được thực hiện xong. Vì vậy, chúng ta cần định nghĩa cả 2 khía cạnh “Tiêu chí hoàn thành – DoD” và “Tiêu chí chấp nhận – AC” như hình dưới:
Khác Nhau Giữa Definition Of Done Và Acceptance Criteria
Definition of Done
Định nghĩa hoàn thành được viết như là một danh sách các nhiệm vụ, mỗi một nhiệm vụ sẽ được sử dụng để xác thực một “Story” hoặc PBI (Product Backlog Item), chúng tồn tại để đảm bảo rằng nhóm phát triển đồng thuận về chất lượng của công việc mà họ đang cố gắng hoàn thành. DoD đóng vai trò như một checklist được sử dụng để kiểm tra tính hoàn thiện của từng hạng mục sản phẩm tồn đọng (hay còn gọi là PBI – Product Backlog Item) hoặc User Story. Các yêu cầu trong định nghĩa hoàn thành (DoD) nhằm mục đích áp dụng cho tất cả các hạng mục trong Product Backlog, chứ không chỉ dành cho một User Story cụ thể. DoD có thể được tóm tắt như sau:
- Thuật ngữ DoD thường được áp dụng cho phần tăng trưởng sản phẩm như là một yêu cầu chung;
- Trong hầu hết các trường hợp, DoD hàm ý rằng, phần tăng trưởng sản phẩm có thể phát hành được;
- Thuật ngữ DoD được định nghĩa trong Scrum Guide;
- DoD được sử dụng như là một cách giao tiếp giữa các thành viên trong nhóm để: Đảm bảo chất lượng phần mềm; Xác định xem phần tăng trưởng có thể bàn giao, hay không;
Mục đích của DoD
- Xây dựng một hiểu biết chung trong nhóm về “Chất lượng” và “Tính hoàn thiện”;
- Được sử dụng như là một “danh sách kiểm tra – checklist” để kiểm tra các User Story (hoặc PBIs);
- Đảm bảo rằng phần tăng trưởng có thể bàn giao được vào cuối mỗi Sprint có chất lượng cao và “chất lượng cao” được hiểu rõ bởi tất cả các bên liên quan;
Thí dụ về DoD
Ví dụ trong ngành phần mềm, các nhóm có thể cần hỏi một số câu hỏi sau để đưa ra DoD của họ:
- Có cần review chéo code hay không?
- Như thế nào được xem là code đã “xong”?
- Chúng ta sẽ review code như thế nào?
- Unit test đã được kiểm tra hay chưa?
- Function test đã được kiểm tra hay chưa?
- Test chấp nhận đã được tiến hành xong chưa?
- Product Owner đã xem và chấp nhận tính năng mới này chưa?
Tiêu Chí Nghiệm Thu (Acceptance Criteria)
User stories là một trong các artifact chính trong phát triển sản phẩm bằng Agile, tuy vậy Scrum không yêu cầu bắt buộc phải sử dụng User Story hay Acceptance Criteria. Nếu các hạng mục Product Backlog được xem xét là quá lớn để đặt trong một sprint, nó thường được chia nhỏ thành các user story và các nhiệm vụ con giống như hình ví dụ sau:
Các User Story chứa các tiêu chí chấp nhận (Acceptance Criteria – AC), vì vậy chúng ta thường thấy định nghĩa hoàn thành (DoD) và tiêu chí chấp nhận (AC) cùng tồn tại trong quy trình phát triển Scrum. User Story cung cấp “ngữ cảnh – yêu cầu người dùng” của chức năng mà nhóm nên phát hành. Tiêu chí chấp nhận (AC) đưa ra các hướng dẫn chi tiết về các yêu cầu của chức năng và diễn tả cách khách hàng sẽ chấp nhận chúng.
Một vài tiêu chí chấp nhận sẽ được làm rõ trong sự kiện “làm mịn – Backlog Refinement” trước khi bắt đầu Sprint mới, và phần còn lại sẽ được làm rõ ngay sau phiên lập kế hoạch, khi nhóm thảo luận về các user story. Vì vậy tiêu chí chấp nhận (AC) là duy nhất cho một User Story hoặc một hạng mục Product Backlog.
- Thuật ngữ này áp dụng cho một PBI/Story;
- Tiêu chí chấp nhận là khác nhau cho mỗi PBI/Story;
- Nguyên tắc này không được định nghĩa trong Scrum Guide;
- AC được sử dụng như là một cách để thông báo cho tất cả các bên liên quan rằng một PBI/Story đã được hoàn thành;
- Tiêu chí chấp nhận trong một số trường hợp có thể là các Test Case;
Mục đích của AC (Acceptance Criteria)
- Làm rõ nhóm muốn xây dựng tính năng gì, như thế nào trước khi công việc bắt đầu (xem thêm: DoR - Định nghĩa về sự sẵn sàng);
- Chắc chắn rằng tất cả mọi người có chung hiểu biết về “vấn đề”;
- Giúp các thành viên trong nhóm biết rằng khi nào một Story được tính là hoàn thành;
- Giúp kiểm tra Story bằng các kiểm thử tự động;
Thí dụ về Acceptance Criteria
- Một user không thể “submit” dữ liệu khi chưa nhập tất cả các trường bắt buộc;
- Thông tin từ “form” được lưu trữ trong bảng “registrations” trong cơ sở dữ liệu;
- Có thể thanh toán qua thẻ tín dụng;
- Một email xác nhận được gửi tới người dùng sau khi “submit” form;
Thí dụ với một User Story áp dụng tiêu chí nghiệm thu Acceptance Criteria
User Story: Là người dùng, tôi muốn có thể đăng ký online để mua sắm online;
Definition of Done:
- Code cần được review bởi teamleader;
- Code cần được Function test;
- Code cần được Acceptance test;
- Code cần được Intergration test;
- Code cần được merge vào nhánh dev;
Acceptance Criteria:
- Người dùng chỉ có thể submit form sau khi nhập tất cả các trường bắt buộc;
- Email mà người dùng cung cấp phải là một email “cá nhân”;
- Một IP chỉ có thể submit form 3 lần trong 30 phút;
- Người dùng sẽ nhận một email thông báo sau khi đăng ký thành công;
Kết Luận
DoD là một bước quan trọng để hoàn thành công việc ở mức "đúng và đủ", là cơ sở để hai bên nghiệm thu từng đợt, từng phần, tương tự như xây dựng một chung cư sẽ diễn ra nhiều đợt nghiệm thu hoàn thiện khối lượng. Bạn sẽ không thể đòi hỏi nhà thầu phải hoàn thiện xong "phòng khách" thì mới giải ngân.
AC là tiêu chí nghiệm thu toàn phần, tương tự như hoàn thiện một căn nhà có đầy đủ phòng ở, WC, hệ thống điện, nước... Tuy nhiên AC sẽ có rủi ro thất bại nếu các hạng mục công việc đầu vào chưa rõ ràng, chưa minh bạch, thiếu giám sát dẫn đến thay đổi quá nhiều so với ban đầu. Đó chính là khái niệm DoR (Definition of Ready). Xem thêm: Khác nhau giữa DoR (Definition of Ready), DoD (Definition of Done) và AC (Acceptance Criteria)?
Tổng hợp và biên tập
