Mở đầu — vì sao bài này quan trọng
Nếu phải chọn ra một khái niệm trong Scrum Guide vừa hay bị hiểu sai nhất, vừa xuất hiện nhiều nhất trong đề thi PSM I, thì Definition of Done (DoD) chắc chắn nằm trong top đầu. Lý do rất đơn giản: DoD nghe có vẻ "chỉ là một danh sách checklist kỹ thuật" — nhưng thực ra nó là một trong những cơ chế quan trọng nhất để Scrum tạo ra minh bạch (transparency) và đảm bảo chất lượng (quality) của sản phẩm.
Trong các bài trước, bạn đã học về Increment như một artifact, và mỗi artifact đều có một commitment đi kèm. Với Increment, commitment đó chính là Definition of Done. Bài này sẽ đi sâu vào bản chất của DoD: nó là gì, ai sở hữu nó, nó tạo ra giá trị như thế nào, và những hiểu lầm chết người mà thí sinh PSM I hay mắc phải.
Tôi muốn bạn ghi nhớ một điều ngay từ đầu: trong kỳ thi PSM I, rất nhiều câu hỏi không kiểm tra việc bạn có "biết DoD là gì" hay không, mà kiểm tra việc bạn có hiểu đúng theo Scrum Guide vai trò và quyền sở hữu của nó hay không. Một chữ sai trong cách hiểu có thể khiến bạn chọn sai đáp án dù nội dung nghe rất hợp lý. Vậy nên hãy đọc bài này chậm và kỹ.
Khái niệm cốt lõi
DoD là gì?
Theo Scrum Guide 2020, 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 chuẩn chất lượng cần thiết cho sản phẩm. Nói cách khác, DoD là sự đồng thuận chung về việc "thế nào là HOÀN THÀNH" đối với bất kỳ Product Backlog Item nào.
Hãy chú ý từ "chất lượng" (quality). DoD không nói về cái gì được làm (đó là việc của Product Backlog Item, của Sprint Goal), mà nói về mức độ tốt mà công việc phải đạt được trước khi có thể coi là xong. DoD là tiêu chuẩn, là thước đo, là ranh giới giữa "đã làm" và "đã hoàn thành".
DoD là commitment của Increment
Đây là điểm mấu chốt mà bạn phải khắc cốt ghi tâm cho kỳ thi. Trong Scrum Guide 2020, mỗi artifact gắn với một commitment:
- Product Backlog gắn với Product Goal
- Sprint Backlog gắn với Sprint Goal
- Increment gắn với Definition of Done
Quy tắc vàng: chưa đạt DoD = không phải Increment
Scrum Guide nói rất rõ: "The moment a Product Backlog item meets the Definition of Done, an Increment is born." (Khoảnh khắc một Product Backlog item đáp ứng Definition of Done, một Increment ra đời.)
Hệ quả trực tiếp:
- Một item làm xong 90% nhưng chưa đạt DoD thì không được coi là done. Trong Scrum không có "done một phần", không có "done nhưng còn thiếu test", không có "done 80%".
- Item chưa đạt DoD sẽ quay trở lại Product Backlog để được xem xét lại trong tương lai. Nó không "treo lơ lửng" ở Sprint cũ.
- Công việc chưa done không được trình diễn tại Sprint Review như thể nó đã hoàn thành.
Ai sở hữu DoD?
Đây là khu vực bẫy kinh điển của PSM I. Có hai trường hợp:
- Nếu tổ chức có một DoD chuẩn (organizational standard): tất cả các Scrum Team phải tuân theo như mức tối thiểu. Các Developers không được phép hạ thấp tiêu chuẩn này.
- Nếu tổ chức KHÔNG có DoD chuẩn: chính Scrum Team phải tạo ra một Definition of Done phù hợp với sản phẩm. Trong thực tế, Developers là những người chủ yếu định nghĩa các tiêu chí kỹ thuật, vì họ là người hiểu rõ nhất "thế nào là chất lượng".
DoD tạo ra điều gì?
DoD phục vụ ba mục tiêu lớn:
- Minh bạch: mọi người trong và ngoài Scrum Team đều hiểu chung "done nghĩa là gì". Không còn cảnh Product Owner tưởng done là đã deploy, còn Developers tưởng done là đã code xong.
- Chất lượng: DoD đảm bảo mỗi Increment đều đạt một chuẩn chất lượng nhất quán, không phụ thuộc tâm trạng hay áp lực deadline.
- Khả năng forecast: khi "done" có nghĩa rõ ràng và nhất quán, team có thể dự báo tốt hơn về lượng công việc thực sự hoàn thành mỗi Sprint.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "done nhưng chưa test"
Giả sử một nhóm phát triển tại một sàn thương mại điện tử lớn (lấy bối cảnh tương tự Tiki) đang làm tính năng "đặt hàng nhanh bằng một chạm". Trong Sprint Review, Developers trình bày tính năng và nói: "Đã code xong, đã chạy thử trên máy local, chỉ còn chưa viết automated test và chưa kiểm thử tích hợp với cổng thanh toán."
Product Owner hài lòng và đánh dấu item này là "done". Hai tuần sau, tính năng lên production, và lỗi thanh toán khiến 1.200 đơn hàng bị tính tiền hai lần. Khủng hoảng nổ ra.
Diễn giải: Vấn đề ở đây không phải kỹ thuật, mà là DoD. Nếu DoD của team có ghi rõ "đã viết và pass automated test, đã kiểm thử tích hợp với các dịch vụ phụ thuộc", thì item đó chưa đạt DoD và không bao giờ được coi là done. Việc gọi nó là done là vi phạm tính minh bạch — Product Owner và stakeholders đã nhận một thông tin sai về tiến độ thực sự.
Bài học: "Done một phần" không tồn tại trong Scrum. Một item hoặc đạt DoD hoàn toàn, hoặc quay về Product Backlog. Áp lực deadline không bao giờ là lý do để nới lỏng DoD trong một Sprint.
Tình huống 2 — Một fintech ở Singapore và DoD tiến hóa theo thời gian
Một startup fintech tại Singapore mới thành lập, đội ngũ 5 Developers. Khi mới bắt đầu, DoD của họ khá đơn giản: "Code review xong, merge vào nhánh chính, deploy lên môi trường staging." Họ chưa có khả năng tự động hóa kiểm thử bảo mật.
Sáu tháng sau, sau khi đầu tư vào hạ tầng CI/CD, team mở rộng DoD: thêm "pass automated security scan", "đạt code coverage tối thiểu 80%", "đã cập nhật tài liệu API". DoD trở nên chặt chẽ hơn theo thời gian.
Diễn giải: Đây là một ví dụ rất quan trọng vì nó cho thấy DoD không bất biến. Khi năng lực của Scrum Team trưởng thành, DoD nên được mở rộng và làm chặt hơn để nâng cao chất lượng sản phẩm. Một dấu hiệu của team trưởng thành chính là DoD ngày càng mạnh.
Bài học: DoD có thể (và nên) được rà soát, điều chỉnh. Sprint Retrospective là dịp tự nhiên để team thảo luận xem có nên nâng cấp DoD hay không. Nhưng lưu ý — việc thay đổi DoD giữa chừng cần thận trọng để không gây hiểu lầm về phạm vi công việc đã cam kết.
Tình huống 3 — Một agency ở TP.HCM với nhiều team trên cùng sản phẩm
Một công ty phần mềm gia công ở TP.HCM có 3 Scrum Team cùng làm trên một sản phẩm SaaS quản lý nhân sự. Mỗi team trước đây tự định nghĩa "done" theo cách riêng: team A coi "done" là đã deploy lên staging, team B coi là đã pass unit test, team C coi là đã có người QA xác nhận.
Kết quả: khi tích hợp Increment của ba team lại để release, chất lượng không đồng nhất, lỗi tràn lan, và không ai tin tưởng vào tiến độ báo cáo.
Diễn giải: Khi nhiều Scrum Team làm việc trên cùng một sản phẩm, họ phải cùng nhau tuân theo một Definition of Done chung cho sản phẩm, để Increment của các team có thể tích hợp được với nhau. Đây là yêu cầu rõ ràng của Scrum Guide.
Bài học: DoD gắn với sản phẩm, không phải gắn với từng team một cách rời rạc. Nhiều team trên cùng product = một DoD chung tối thiểu. Từng team có thể chặt hơn nhưng không được thấp hơn chuẩn chung.
Hướng dẫn từng bước
Nếu bạn đang giúp một Scrum Team xây dựng hoặc cải thiện DoD, hãy làm theo trình tự sau:
- Kiểm tra xem tổ chức đã có DoD chuẩn chưa. Nếu có, đó là mức tối thiểu bắt buộc. Team chỉ được làm chặt hơn, không được nới lỏng.
- Tập hợp Scrum Team để thảo luận. Developers đóng vai trò chính trong việc xác định tiêu chí kỹ thuật, nhưng cả Product Owner và Scrum Master đều tham gia để đảm bảo DoD phản ánh đúng chất lượng mà sản phẩm cần.
- Liệt kê các tiêu chí cụ thể, có thể kiểm chứng. Ví dụ: code đã review, automated test pass, không có lỗi nghiêm trọng tồn đọng, đã cập nhật tài liệu, đã deploy được lên môi trường mục tiêu. Tránh các tiêu chí mơ hồ như "code sạch" — hỏi tiếp "sạch nghĩa là gì?".
- Đảm bảo mọi tiêu chí đều khả thi trong Sprint. Nếu một tiêu chí (ví dụ "đã được khách hàng cuối phê duyệt") không thể hoàn thành trong Sprint, đừng đưa vào DoD — nếu không bạn sẽ chẳng bao giờ tạo ra được Increment done.
- Công khai DoD cho mọi người. DoD phải minh bạch với cả stakeholders. Treo nó lên tường, đưa vào wiki, nhắc lại trong Sprint Planning.
- Áp dụng nhất quán. Trong Sprint Planning, team chỉ nhận những item mà họ tin có thể hoàn thành đạt DoD. Trong Sprint, mỗi item đều được đo bằng cùng một thước DoD.
- Rà soát định kỳ. Dùng Sprint Retrospective để hỏi: DoD hiện tại có còn phù hợp không? Năng lực team đã đủ để nâng cấp DoD chưa?
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm DoD với Acceptance Criteria. Đây là nhầm lẫn phổ biến nhất. Acceptance Criteria (tiêu chí chấp nhận) là riêng cho từng Product Backlog Item, mô tả cái gì item đó phải làm được. DoD áp dụng cho mọi item, mô tả mức chất lượng chung mà tất cả phải đạt. Một item có thể đạt Acceptance Criteria của nó nhưng vẫn chưa "done" nếu chưa thỏa DoD (ví dụ chưa viết test). Hãy ghi nhớ: DoD là chung, Acceptance Criteria là riêng.
Lỗi 2 — Nhầm DoD với Definition of Ready. Definition of Ready (sẽ học kỹ ở Bài 41) là một kỹ thuật tùy chọn, không nằm trong Scrum Guide. DoD thì bắt buộc. Đừng để câu hỏi đánh tráo hai khái niệm này.
Lỗi 3 — Cho rằng Scrum Master hoặc Product Owner sở hữu DoD. Như đã phân tích, khi tổ chức chưa có chuẩn, chính Scrum Team tạo ra DoD, với Developers giữ vai trò chính về tiêu chí kỹ thuật. Đừng chọn đáp án "Scrum Master định nghĩa DoD".
Lỗi 4 — Tin rằng có thể nới lỏng DoD để "kịp deadline". Trong Scrum không có khái niệm hạ chuẩn DoD giữa Sprint để báo cáo done nhiều hơn. Làm vậy là phá hủy tính minh bạch. Nếu công việc không đạt DoD, nó đơn giản là chưa done.
Lỗi 5 — Coi DoD là cố định mãi mãi. DoD nên tiến hóa khi team trưởng thành. Một DoD không bao giờ thay đổi trong nhiều năm thường là dấu hiệu team đã ngừng cải tiến.
Mẹo thi cử: Khi gặp câu hỏi về DoD, hãy tự hỏi ba điều: (1) Nó có đang nói về chất lượng chung không (nếu nói về chức năng riêng thì là Acceptance Criteria)? (2) Quyền sở hữu có đúng là Scrum Team / Developers không? (3) Item chưa đạt DoD có được mô tả đúng là "chưa done, quay về Product Backlog" không? Trả lời đúng ba câu này thì hầu hết câu hỏi DoD đều xử lý được.
Bài tập thực hành
- Phân biệt khái niệm: Cho một Product Backlog Item "Người dùng có thể đặt lại mật khẩu qua email". Hãy viết 2 Acceptance Criteria riêng cho item này, và 3 tiêu chí thuộc DoD chung của team. Quan sát sự khác nhau giữa hai loại.
- Tình huống quyết định: Trong Sprint Review, một Developer trình bày item đã "code xong, chạy được nhưng chưa pass automated test", trong khi DoD của team yêu cầu pass test. Hãy mô tả: item này có được tính là done không? Nó sẽ đi về đâu? Stakeholders nên được thông báo điều gì?
- Soi DoD của chính bạn: Nếu bạn đang làm trong một team thật, hãy viết ra DoD hiện tại (nếu chưa có thì tự soạn). Sau đó tự đánh giá: có tiêu chí nào mơ hồ không? Có tiêu chí nào bất khả thi trong một Sprint không? Có nên nâng cấp tiêu chí nào không?
- Tự kiểm tra trí nhớ: Không nhìn lại bài, hãy trả lời nhanh: DoD là commitment của artifact nào? Ai sở hữu DoD khi tổ chức chưa có chuẩn? Khi nhiều team làm cùng một sản phẩm, họ dùng mấy DoD?
Tóm tắt
Definition of Done là commitment gắn với Increment artifact — một sự đồng thuận chính thức về chất lượng, xác định khi nào một Product Backlog Item được coi là thực sự hoàn thành. Hãy ghi nhớ những điểm cốt lõi:
- DoD nói về chất lượng chung áp dụng cho mọi item, khác với Acceptance Criteria vốn riêng cho từng item.
- Khoảnh khắc một item đáp ứng DoD, một Increment ra đời. Chưa đạt DoD thì không phải Increment, không được trình diễn như đã done, và quay về Product Backlog.
- Khi tổ chức có chuẩn, đó là mức tối thiểu bắt buộc. Khi chưa có, Scrum Team tạo DoD, với Developers giữ vai trò chính về tiêu chí kỹ thuật. Scrum Master hỗ trợ chứ không ban hành.
- Nhiều Scrum Team trên cùng một sản phẩm phải tuân theo một DoD chung để Increment tích hợp được.
- DoD nên tiến hóa và làm chặt hơn khi team trưởng thành; Sprint Retrospective là nơi thích hợp để rà soát.