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)
Last updated: August 21, 2025 Xem trên toàn màn hình
Recommended for you
- 04 Mar 2020
Kinh nghiệm lập dự toán chi phí dự án phần mềm theo phương pháp Man-Month 2371 - 01 Jul 2023 Phương pháp Shuhari - Làm sao học ít hiểu nhiều? 784
- 01 Aug 2022 "Sponsored Content" là gì? Khác nhau giữa Sponsored Content và Native Advertising? 672
- 04 Jan 2023 Phát triển phần mềm linh hoạt theo mô hình Big Bang 606
- 01 Feb 2022 Thách thức với doanh nghiệp chuyển đổi số trong thời đại VUCA 600
- 18 May 2021 Cây cầu hiện đại vô dụng nhất thế giới và câu chuyện cái kết của thay đổi yêu cầu 542
- 03 Oct 2021 Khác biệt giữa thiết kế phần mềm và thiết kế công trình xây dựng 483
- 15 Apr 2020 Phần mềm BPM là gì? So sánh với ERP và các phần mềm Workflows 454
- 03 Mar 2020 Giả định (Assumption ) là gì? Tại sao giả định rất quan trọng với dự án? 436
- 03 Feb 2020 Chất lượng là gì? Đẳng cấp là gì? Cùng tìm hiểu toàn diện từ góc nhìn chuyên gia. 416
- 03 May 2022 Mô hình Hybrid Agile là gì? 413
- 18 Mar 2021 Kỹ thuật ước lượng dự án phần mềm linh hoạt dựa vào Story Point - phương pháp T-Shirt Sizing 406
- 24 May 2022 Feedforward - phương pháp phản hồi hiệu quả trong thời đại mới 403
- 03 Feb 2020 Sản phẩm OEM và ODM là gì? 396
- 05 Aug 2021 Chu kỳ 4 giai đoạn Chuyển đổi - Tích hợp - Phát triển - Tối ưu là gì? 366
- 18 Aug 2022 Nhiệm vụ TIGO 2020-2025: Vấn đề của bạn, giải pháp của chúng tôi 353
- 02 Aug 2023 Tổng hợp một số project tham khảo khi xây dựng các ứng dụng theo mô hình Microservices 343
- 30 Jul 2021 14 Nguyên Tắc Quản Lý Của Deming Là Gì? 343
- 17 Mar 2020 Mô hình “Service Gaps Model” quản lý và cải thiện chất lượng dịch vụ 337
- 14 Apr 2019 Product Backlog là gì? Các đặc điểm cơ bản của một Product Backlog 335
- 12 May 2021 Các yêu cầu thay đổi (Change Requests) - nỗi ám ảnh của team dự án phần mềm 313
- 20 Jul 2021 Quản lý và đánh giá công việc theo quy trình TIGO SmartWork 313
- 04 Jan 2023 Đánh giá nhân sự theo chuẩn người Nhật 312
- 02 Aug 2021 Product Owner làm gì trước khi bắt đầu sprint đầu tiên của dự án (Sprint Zero)? 310
- 01 Aug 2023 Phân tích yêu cầu phần mềm sẽ nhìn vào thực trạng (AS-IS) hay tương lai (TO-BE)? 310
- 29 Jun 2020 TIGOWAY - nền tảng phát triển vững chắc của chúng tôi 296
- 28 Jun 2024 Tại sao các kỹ sư IT giỏi nhất lại là những người theo thuyết bất khả tri về công nghệ (technology agnostics)? 267
- 18 Jun 2021 Cost of Quality - Chi phí cho chất lượng sản phẩm là gì? 261
- 19 Mar 2023 Post-mortem và Retrospective: Khác biệt là gì? 225
- 17 Aug 2020 Mục tiêu dự án là gì? Làm thế nào để xác định mục tiêu? 203
- 14 Dec 2021 Kano Model Analysis là gì? 202
- 08 Jan 2022 Yêu cầu thay đổi (Change Request) là gì? Làm thế nào để kiểm soát Change Request? 198
- 14 May 2024 Chiến lược răng lược là gì? Làm thế nào để tận dụng chiến lược răng lược trong kinh doanh? 188
- 10 Aug 2019 Tại sao tôi chọn công thức "Work Smart" mà không phải "Work Hard"? 186
- 24 Mar 2019 Scrum giống như bà mẹ chồng, giúp bạn nhìn ra các lỗi sai 184
- 10 May 2021 Phát triển Phần mềm Tinh gọn (Lean Software Development) 180
- 08 Mar 2022 Mô hình nguồn mở hoạt động ra sao? 174
- 01 Sep 2020 Co-founder là gì? Vai trò của các Co-Founder khi lập nghiệp. 167
- 08 Feb 2021 Quy trình nâng cấp phần mềm quản trị doanh nghiệp TIGO ERP 166
- 21 Apr 2020 Bảo trì phần mềm là gì? Phân biệt các loại bảo trì 156
- 14 Dec 2022 Phương pháp kiểm tra Fagan Inspection là gì? 152
- 08 Mar 2020 Vì sao doanh nghiệp cần phải tạo Web bán hàng? 149
- 01 May 2023 [Tư vấn CNTT] Quản lý ngân sách CNTT cho doanh nghiệp 146
- 28 Jul 2021 Checklist là gì? Tầm quan trọng của checklist trong công việc 145
- 01 Apr 2022 Chi phí nhà thầu phụ chiếm bao nhiêu phần trăm gói thầu? 144
- 19 Aug 2020 Lift & Shift - Phương pháp tối ưu dịch chuyển hệ thống phần mềm qua đám mây 139
- 17 Feb 2018 Hệ luỵ khi sử dụng Web Hosting từ nhà cung cấp kém chất lượng 123
- 18 Mar 2018 Dịch vụ Hosting cho Website là gì? Các lời khuyên chọn Hosting tốt nhất 116
- 09 Feb 2021 Tầm nhìn là gì? Tí dụ minh họa cụ thể về tầm nhìn 113
- 25 Apr 2018 Bảo hộ bản quyền phần mềm dưới khía cạnh sở hữu trí tuệ như thế nào? 96
- 10 Aug 2020 Bạn có biết quy tắc thất bại nhanh: Fail early, fail often, fail cheap, but always fail forward 92
- 22 Jul 2020 Quản lý dự án phần mềm trong thực tế và câu chuyện thành công của InfoSys 86
- 08 Aug 2024 Phân biệt mô hình MLP với mô hình BVP 80
- 16 May 2025 Phân biệt Statement Of Work (SOW) và Project Scope Statement 74
- 13 Apr 2025 Phân biệt MLP (Minimum Lovable Product) và State-of-the-art Product 67
- 04 Feb 2022 Phân biệt lập trình viên (programmer) và kỹ sư phần mềm (software engineer) 59
- 07 Mar 2023 Google Maps: Bài Học Tỷ Đô Từ Một Ứng Dụng Miễn Phí 53
- 11 Mar 2025 Thiên hướng Hành động (Bias for Action) và Thiên hướng Quy trình (Bias for Process) tác động tiêu cực tới "đổi mới và sáng tạo" như thế nào? 49
- 29 Aug 2023 Phân biệt Accountable và Responsible? 47
- 05 Aug 2025 "Nói láo" khác với "nói dối" như thế nào? 27
- 16 Apr 2025 Lãnh đạo linh hoạt: Hành động (Bias for Action) hay không hành động (Non-Action)? 25
- 15 Aug 2025 Dự án phần mềm bị trì hoãn và vấn đề "akrasia" 22
- 01 Jun 2025 PMP Cheat Sheet: 25 Cặp Thuật Ngữ Dễ Nhầm Lẫn 21
- 09 Jul 2025 False Dilemma và Valid Dilemma: Hai "đường biên" trong chiến lược Quản trị chất lượng và Kiểm thử phần mềm 17
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
Khám phá thêm các chủ đề sau
Đọc thêm: Hướng dẫn hợp tác viết bài (guest blogging)
Các chủ đề được quan tâm nhiều nhất
CHIA SẺ BÀI VIẾT
Mới cập nhật
