Trong các phương pháp phát triển phần mềm theo Agile và Scrum, hai khái niệm Definition of Ready (DoR) và Definition of Done (DoD) đóng vai trò then chốt trong việc bảo đảm tính minh bạch, thống nhất và chất lượng của công việc. Đây là những tiêu chuẩn được nhóm phát triển cùng thỏa thuận để xác định:

• Khi nào một hạng mục trong Product Backlog đủ rõ ràng và sẵn sàng để được đưa vào Sprint (Definition of Ready).
• Khi nào một hạng mục hoặc một Increment được xem là hoàn tất, đáp ứng đầy đủ các tiêu chí chất lượng đã đề ra (Definition of Done).

Việc phân biệt rõ hai khái niệm này giúp nhóm phát triển quản lý tốt hơn đầu vào và đầu ra của Sprint, hạn chế rủi ro trong quá trình thực hiện và đảm bảo sản phẩm bàn giao thực sự có giá trị đối với khách hàng và tổ chức.

Đọc thêm: https://resources.scrumalliance.org/Article/definition-vs-ready

I. Definition of Ready (DoR) là gì?

Definition of Ready (DoR) là tập hợp các tiêu chí mà một hạng mục công việc (ví dụ: một user story trong Product Backlog) phải đáp ứng trước khi được nhóm phát triển đưa vào thực hiện trong Sprint hoặc Iteration. Nói cách khác, DoR đảm bảo rằng một mục backlog “đã sẵn sàng” – đủ rõ ràng, đủ thông tin và có thể hành động được – trước khi đội ngũ bắt tay vào phát triển, tránh tình trạng “đến khi vào Sprint mới bắt đầu hiểu yêu cầu”. Ví dụ, một user story cần có mô tả rõ ràng, tiêu chí chấp nhận (Acceptance Criteria), ước lượng effort, không phụ thuộc bên ngoài… thì mới được xem là “Ready” để đưa vào Sprint.

DoR thường được các nhóm Scrum sử dụng như một thỏa thuận làm việc nội bộ (working agreement) nhằm đảm bảo tính minh bạch của Product Backlog – tức là mọi người có cùng cách hiểu về mức độ sẵn sàng của mỗi mục backlog trước khi chọn làm. Lưu ý rằng Scrum Guide không bắt buộc phải có DoR; đây là thực hành tùy chọn (không phải quy định chính thức của Scrum) và nếu lạm dụng có thể dẫn đến việc kiểm soát quá mức (quá quan liêu trong khâu chuẩn bị). Tuy vậy, nhiều nhóm Agile nhận thấy DoR hữu ích cho việc giảm rủi ro và cải thiện lập kế hoạch.

DoR gồm những gì? Thông thường, DoR được biểu diễn dưới dạng một danh sách kiểm tra (checklist) các tiêu chí đã được thống nhất trong nhóm. Các tiêu chí này có thể bao gồm: đã xác định và giải quyết các phụ thuộc liên quan, thiết kế đã được hoàn thiện, user story đã được refinement (làm rõ yêu cầu) đầy đủ, có tiêu chí chấp nhận rõ ràng, và nhóm hiểu rõ phạm vi cũng như giá trị của hạng mục đó. Nói ngắn gọn, **“Definition of Ready” nghĩa là hạng mục đó phải “có thể bắt đầu ngay lập tức” – rõ ràng, cụ thể, và actionable – trước khi được đưa vào Sprint.

II. Definition of Done (DoD) là gì?

Definition of Done (DoD) là một mô tả chính thức về trạng thái của một sản phẩm gia tăng (Increment) khi nó đáp ứng các thước đo chất lượng cần thiết cho sản phẩm đó. Hiểu đơn giản, DoD là một sự thống nhất chung trong nhóm về ý nghĩa của “hoàn thành” – tức là điều kiện để một hạng mục công việc được coi là hoàn tất một cách đúng nghĩa. DoD đảm bảo rằng Increment (phần chức năng hoặc sản phẩm hoàn thiện sau mỗi Sprint) đã đáp ứng mọi yêu cầu chất lượng đề ra cho sản phẩm.

Trong Scrum, DoD là một khái niệm bắt buộc và được xem như cam kết chất lượng đối với Increment. DoD thường được thể hiện dưới dạng danh sách kiểm tra các tiêu chí hoàn thành mà mọi Product Backlog Item (PBI) phải thỏa mãn khi chuyển thành Increment. Đây là một checklist toàn diện gồm tất cả các công việc cần hoàn tất để đảm bảo sản phẩm tăng trưởng đạt chất lượng mong muốn và thực sự “Done” (hoàn tất). Chẳng hạn, các tiêu chí trong DoD thường bao gồm: code đã được viết xong và tuân thủ chuẩn coding, đã có code review, đã viết unit test và tất cả test đều pass, tính năng đã được QA/Tester kiểm thử đầy đủ, tài liệu liên quan đã cập nhật, đảm bảo đáp ứng các tiêu chuẩn hoặc quy định cần thiết, v.v. Mục tiêu là sau khi thỏa mãn DoD, Increment không chỉ hoạt động đúng mà còn ở trạng thái sẵn sàng phát hành cho người dùng hoặc khách hàng.

Theo Scrum Guide, “Công việc chỉ được xem là một phần của Increment khi nó thỏa mãn Definition of Done”. Điều này có nghĩa là nếu một Product Backlog Item chưa đáp ứng DoD vào cuối Sprint, nó không được coi là hoàn thành và 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 lại vào Product Backlog để xem xét trong tương lai. DoD tạo ra tính minh bạch cho sản phẩm bằng cách cung cấp cho tất cả mọi người cùng một hiểu biết chung về những gì đã được làm xong trong Increment.

Ai định nghĩa và chịu trách nhiệm về DoD? Trong trường hợp tổ chức đã có sẵn chuẩn DoD ở cấp độ tổ chức, tất cả các Scrum Team trong tổ chức phải tuân thủ tối thiểu các tiêu chuẩn DoD đó. Nếu tổ chức chưa có DoD chung, Scrum Team sẽ tự xây dựng Definition of Done phù hợp với sản phẩm của mình (thường trong giai đoạn đầu của dự án). DoD sau đó có thể được điều chỉnh và nâng cấp qua các Sprint Retrospective để nâng cao chất lượng khi nhóm trưởng thành hơn. Mọi thành viên nhóm Scrum phải hiểu rõ và tôn trọng DoD, trong đó Development Team (Developers) có trách nhiệm đảm bảo mỗi hạng mục công việc họ hoàn thành đều đáp ứng DoD trước khi báo cáo “Done”. Nếu có nhiều Scrum Team cùng phát triển một sản phẩm (ví dụ trong mô hình Scaled Agile/SAFe), các nhóm phải thống nhất một DoD chung cho toàn sản phẩm và cùng tuân thủ DoD đó (mỗi nhóm có thể bổ sung tiêu chí riêng nhưng không mâu thuẫn với DoD chung).

III. Sự khác biệt giữa Definition of Done (DOD) và Definition of Ready (DOR)

Mặc dù cùng là những chuẩn mực giúp đảm bảo công việc trong Agile được thực hiện suôn sẻ, Definition of Ready và Definition of Done khác nhau cơ bản về mục đích, khi nào áp dụng, ai chịu trách nhiệm, và vai trò của chúng trong quy trình. Dưới đây là các điểm so sánh chính:

• Mục đích: Definition of Ready tập trung vào đảm bảo chất lượng đầu vào – tức là đảm bảo công việc chuẩn bị đầy đủ trước khi bắt đầu. DoR giúp đội ngũ chỉ đưa vào Sprint những hạng mục đã sẵn sàng triển khai ngay, qua đó giảm thiểu rủi ro mơ hồ, trễ tiến độ hoặc phải làm lại giữa chừng. Nó tăng độ tin cậy cho kế hoạch Sprint vì mọi thứ đưa vào đều rõ ràng. Ngược lại, Definition of Done tập trung vào đảm bảo chất lượng đầu ra – tức là đảm bảo sản phẩm sau khi phát triển đạt định nghĩa “hoàn thành” chung. DoD đặt ra một chuẩn chất lượng thống nhất mà mỗi tính năng/phần mềm phải đạt được khi kết thúc, giúp nhóm kiểm chứng rằng công việc thực sự hoàn tất với chất lượng cam kết (đầy đủ chức năng, đã test xong, sẵn sàng phát hành).
• Thời điểm áp dụng: DoR được áp dụng trước và trong khi lập kế hoạch. Cụ thể, DoR hữu dụng trong giai đoạn refinement (làm rõ yêu cầu) và đặc biệt là khi Sprint Planning, nhóm sẽ kiểm tra các hạng mục Product Backlog dự kiến đưa vào Sprint có đáp ứng DoR hay chưa. Bất kỳ mục nào chưa “Ready” thì nhóm từ chối đưa vào Sprint cho đến khi được làm rõ thêm. Ngược lại, DoD được áp dụng trong quá trình phát triển và khi hoàn tất công việc. Các tiêu chí DoD được nhóm phát triển sử dụng như thước đo để tự đánh giá trong suốt quá trình code, test… và đặc biệt là khi kết thúc một user story hoặc một Sprint. Trước khi một chức năng được coi là “xong” (Done), nhóm kiểm tra đối chiếu với DoD. Vào cuối Sprint, chỉ những hạng mục nào đạt DoD mới được trình bày trong Sprint Review và tính vào Increment hoàn thành của Sprint đó.
• Trách nhiệm: Việc thiết lập và tuân thủ DoR và DoD cũng khác nhau về mặt trách nhiệm. Definition of Ready thường là trách nhiệm chung của Product Owner và Nhóm Phát triển. Product Owner chịu trách nhiệm chính trong việc chuẩn bị backlog (viết rõ yêu cầu, bổ sung thông tin cần thiết), nhưng cả PO và nhóm Dev phải cùng phối hợp trong quá trình refinement để đảm bảo các mục Backlog đạt trạng thái “Ready” theo tiêu chí đã đề ra. Nhóm phát triển cũng có quyền từ chối nhận việc chưa “ready”, do đó họ tham gia định nghĩa DoR và tuân thủ nó nhằm bảo vệ năng lực Sprint của mình. Ngược lại, Definition of Done là trách nhiệm thuộc về cả nhóm Scrum, đặc biệt là đội phát triển đối với chất lượng sản phẩm. Thông thường, cả Scrum Team cùng định nghĩa DoD (trừ khi có sẵn chuẩn tổ chức), nhưng đội phát triển phải là người thực thi để mọi công việc hoàn thành đều thỏa mãn DoD. Product Owner quan tâm DoD ở chỗ: một khi tính năng chưa đạt DoD thì chưa thể coi là hoàn thành giá trị để bàn giao. Scrum Master có thể hỗ trợ nhắc nhở về DoD, nhưng cuối cùng Development Team là người chịu trách nhiệm chính cho việc đáp ứng DoD trước khi báo cáo hoàn thành công việc.
• Vai trò trong quy trình Agile: Có thể hình dung DoR như “điều kiện đầu vào” còn DoD là “điều kiện đầu ra” của quy trình phát triển Scrum. Cụ thể, DoR đóng vai trò như một cửa lọc ở đầu Sprint: đảm bảo chỉ những yêu cầu đã rõ ràng, khả thi mới được đưa vào thực thi, giúp dòng chảy công việc trong Sprint trôi chảy và hiệu quả hơn (tránh các trở ngại do yêu cầu chưa rõ gây ra). DoR liên quan chặt chẽ đến Product Backlog Refinement và Sprint Planning – nhờ có DoR, Product Backlog luôn duy trì ở trạng thái sẵn sàng với những mục chất lượng, và Sprint Planning chọn được các mục phù hợp năng lực nhóm. Trong khi đó, DoD là thước đo ở cuối quy trình phát triển: nó gắn với Increment và việc kiểm thử/chấp nhận kết quả. DoD đảm bảo rằng mọi thành phẩm tạo ra sau mỗi Sprint đều có giá trị và chất lượng ở mức có thể triển khai (potentially releasable). Về mặt minh bạch, DoD cung cấp một ngôn ngữ chung để cả nhóm Scrum lẫn các bên liên quan hiểu thế nào là “xong” – tránh hiểu lầm việc “làm xong” của developer chỉ mới code xong nhưng chưa test xong chẳng hạn. Nhờ DoD, Sprint Review tập trung vào những Increment đã hoàn thiện thực sự, và tổ chức có thể tự tin rằng những gì được gắn mác “Done” đã sẵn sàng để ra mắt hoặc chuyển giao.

Tóm lại, Definition of Ready và Definition of Done bổ sung cho nhau ở hai đầu quy trình phát triển Agile. DoR đảm bảo đầu vào của Sprint là tốt nhất có thể, còn DoD đảm bảo đầu ra của Sprint đạt chất lượng cam kết. Cả hai đều là những tiêu chuẩn làm việc quan trọng giúp nhóm Agile hoạt động hiệu quả hơn: DoR giúp giảm thiểu rủi ro trước khi làm, DoD giúp bảo đảm chất lượng sau khi làm. Việc hiểu rõ và áp dụng đúng cả DoR và DoD sẽ góp phần tăng cường tính minh bạch, nâng cao hiệu suất nhóm và tạo ra sản phẩm cuối cùng đáp ứng kỳ vọng một cách nhất quán.