Definition of Ready và Definition of Done là gì?

Một story “xong rồi” nhưng chưa ai dùng được

Đây là một tình huống minh họa. Bạn là PO của một app đặt bàn nhà hàng. Story “Khách tự hủy đặt bàn trong app” đã nằm ở cột Done trên board từ hai ngày trước. Tới buổi Sprint Review, bạn mời quản lý nhà hàng vào xem demo.

Dev mở app trên máy của mình và bấm hủy. Màn hình báo hủy thành công. Quản lý hỏi: “Vậy email báo hủy có gửi cho khách không? Nhân viên lễ tân có thấy bàn trống lại không?” Dev trả lời email chưa làm vì “cái đó chắc là story khác”. QA nói chưa kịp test vì code chưa lên môi trường staging. Còn lễ tân thì chưa ai báo.

Không ai nói dối. Mỗi người chỉ hiểu chữ “xong” theo một cách. Với dev, xong là code chạy trên máy. Với QA, xong là đã test. Với quản lý nhà hàng, xong là nhân viên và khách dùng được. Definition of Done sinh ra để gom các cách hiểu đó về một danh sách chung, viết ra trước, áp dụng cho mọi việc.

Bài này giải thích Definition of Done (DoD) và Definition of Ready (DoR) là gì, khác acceptance criteria ra sao, cách cùng team tạo DoD đầu tiên, và khi nào nên hoặc không nên có một checklist sẵn sàng.

Definition of Done là gì?

Theo Scrum Guide 2020, Definition of Done là mô tả chính thức về trạng thái của Increment khi nó đạt các chuẩn chất lượng cần có cho sản phẩm. Increment là phần sản phẩm dùng được mà team làm ra. Nói gọn: DoD là danh sách những điều mọi việc phải đạt trước khi được gọi là xong.

Scrum Guide nêu vài điểm đáng nhớ:

• DoD là cam kết gắn với Increment. Nó áp dụng cho mọi việc, không riêng một story nào.
• Việc chưa đạt DoD thì chưa được phát hành, thậm chí chưa được trình bày ở Sprint Review. Nó quay về Product Backlog để xem xét tiếp.
• Nếu tổ chức đã có chuẩn DoD, team phải theo chuẩn đó như mức tối thiểu. Nếu chưa có, cả Scrum Team phải tự tạo một DoD phù hợp với sản phẩm.
• Nhiều team cùng làm một sản phẩm thì dùng chung một DoD.
• Ở Sprint Retrospective, team xem lại sprint vừa qua, trong đó có cả DoD của mình.

Điểm cuối cùng quan trọng với người mới: DoD không phải văn bản viết một lần rồi cất. Nó được xem lại và chỉnh dần theo khả năng thật của team. Phần sau của bài sẽ nói cách làm việc đó.

Quay lại tình huống ở trên. Nếu team có một DoD ghi “QA đã kiểm hết AC trên staging” và “Bộ phận vận hành liên quan đã được báo thay đổi”, story hủy đặt bàn sẽ không nằm ở cột Done. Buổi demo cũng sẽ không thành một cuộc tranh luận về định nghĩa.

Definition of Ready là gì, có bắt buộc không?

Definition of Ready là một checklist một số team dùng để xem một story đã đủ rõ để đưa vào sprint hay chưa, ví dụ đã có acceptance criteria, đã ước lượng, đã biết phụ thuộc.

Điều cần nói rõ: DoR không có trong Scrum Guide 2020. Scrum Guide chỉ nói các mục backlog mà team có thể làm xong trong một sprint được xem là sẵn sàng để chọn trong Sprint Planning, và chúng thường đạt độ rõ đó nhờ refinement, tức việc tách nhỏ và làm rõ dần các mục backlog. Scrum.org có bài viết gọi DoR là một thực hành bổ sung, không phải phần chính thức của Scrum.

Một số tác giả còn cảnh báo về DoR. Barry Overeem trên Scrum.org viết rằng DoR dễ biến thành một bản hợp đồng giữa dev và PO thay vì một hướng dẫn, kéo team về lối làm tuần tự qua từng cổng duyệt. Mike Cohn ở Mountain Goat Software cho rằng DoR đòi mọi thứ phải hoàn tất trước khi vào sprint sẽ đẩy team về quy trình kiểu thác nước, và khuyên ưu tiên hướng dẫn hơn là quy tắc cứng.

Cả hai tác giả không bảo bỏ hẳn việc kiểm tra độ sẵn sàng. Overeem vẫn ủng hộ dùng checklist khi refine để nâng chất lượng backlog, miễn là không dùng như cổng chặn. Cohn thấy hữu ích khi DoR chặn đúng những vấn đề cụ thể, như story quá lớn hoặc phụ thuộc vào team khác chưa xong.

Quan điểm của bài này: với PO mới, DoD là thứ nên có trước. DoR thì không bắt buộc. Nếu team hay mang vào sprint những story còn mơ hồ, một checklist sẵn sàng ngắn có thể giúp, với điều kiện thiếu một dòng thì cả team bàn, không tự động loại.

DoR, DoD và acceptance criteria khác nhau thế nào?

Ba khái niệm này hay bị trộn lẫn vì cùng là danh sách điều kiện. Khác nhau nằm ở chỗ chúng áp dụng cho cái gì và dùng vào lúc nào. Acceptance criteria (AC) là điều kiện để một story cụ thể được chấp nhận; bài “Acceptance criteria viết sao cho kiểm thử được” đã đi sâu vào phần này.

Một cách nhớ: AC nói story này phải làm gì, DoD nói mọi việc phải được làm tới mức nào, DoR nói khi nào nên bắt đầu. Nếu bạn thấy mình chép “đã viết unit test” vào AC của mọi story, dòng đó thuộc về DoD. Nếu bạn thấy DoR dài bằng cả một tài liệu đặc tả, nó đang làm thay việc refine.

• Acceptance criteria viết sao cho kiểm thử được

Vì sao team dễ nhầm hoặc bỏ qua DoD?

• Chữ “xong” nghe hiển nhiên. Không ai nghĩ cần viết ra, cho tới khi một buổi demo như ở trên xảy ra.
• DoD bị nhầm là việc của QA hay của PO. Thực ra Scrum Guide giao việc tạo DoD cho cả Scrum Team khi tổ chức chưa có chuẩn. PO không viết một mình rồi giao xuống.
• Team chép một DoD mẫu rất dài từ mạng. Không ai làm được hết, nên dần dần không ai nhìn vào nữa.
• Áp lực tiến độ. Khi sắp hết sprint, bỏ qua một dòng DoD “lần này thôi” có vẻ vô hại. Lặp lại vài lần thì DoD chỉ còn trên giấy.
• DoR bị dùng để đổ lỗi. Dev từ chối story vì thiếu một dòng nhỏ, PO thấy bị chặn, hai bên bắt đầu đứng về hai phía thay vì cùng làm rõ.

Điểm chung của các lỗi trên: danh sách được xem như luật áp từ ngoài vào, không phải thỏa thuận cả team cùng giữ. Cách tạo DoD bên dưới đi theo hướng ngược lại.

Cách cùng team tạo Definition of Done đầu tiên

Bạn có thể bắt đầu với một buổi khoảng 45 đến 60 phút, có đủ dev, QA và PO, cho bản đầu tiên. Có thể làm ngay trong buổi retrospective. Đường đi gồm bốn bước.

Bước 1, kể hiện trạng. Mỗi người viết ra giấy note những việc mình đang làm trước khi coi một story là xong. Dev có thể ghi “tạo pull request”, QA ghi “test trên staging”, PO ghi “báo cho bộ phận CSKH”. Gom lại, bạn sẽ thấy chỗ trùng và chỗ hở giữa các vai trò.

Bước 2, chọn dòng làm được ngay. Đây là bước quan trọng nhất. Chỉ giữ những dòng team làm được với mọi story ngay từ sprint tới. Dòng nào hay nhưng chưa làm nổi, ví dụ “có test tự động cho mọi tính năng” khi team chưa có hạ tầng test, thì ghi vào mục “muốn thêm sau”. Một DoD ngắn mà giữ được có ích hơn một DoD dài mà ai cũng bỏ qua.

Bước 3, viết để kiểm được. Mỗi dòng phải trả lời được có hoặc không bởi bất kỳ ai trong team. “Đã test” chưa đủ, vì không rõ ai test, test ở đâu, test gì. “QA đã kiểm hết AC trên staging” thì kiểm được.

Bước 4, dán lên và dùng. Đặt DoD ở chỗ team nhìn thấy khi kéo thẻ: phần mô tả của board, mẫu checklist trong ticket, hoặc một trang chung. Trước Sprint Review, PO có thể lướt nhanh các story ở cột Done và hỏi “story này đạt hết DoD chưa?”.

Vai trò của PO ở đây: không viết thay, nhưng mang góc nhìn của người dùng và bộ phận vận hành vào. Dev và QA dễ nghĩ tới code và test. PO là người dễ nhớ tới những dòng như “CSKH đã biết thay đổi” hoặc “hướng dẫn cho người dùng đã cập nhật”.

Làm sao để DoD tốt dần qua từng sprint?

Scrum Guide đặt DoD vào nội dung của Sprint Retrospective, nên đó là chỗ tự nhiên để chỉnh nó. Ba câu hỏi gọn cho phần này:

• Sprint vừa rồi có story nào bị kéo sang Done mà sau đó lộ ra thiếu sót? Thiếu sót đó có nên thành một dòng DoD không?
• Có dòng nào team liên tục bỏ qua? Vì dòng đó chưa làm nổi, hay vì nó không còn cần?
• Có dòng nào trong mục “muốn thêm sau” mà giờ team đã đủ sức làm với mọi story?

Mỗi lần đổi, ghi số phiên bản và ngày lên đầu DoD. Việc này giúp người mới vào team biết đang dùng bản nào, và giúp team nhìn lại mình đã nâng chuẩn được bao nhiêu sau vài tháng.

Một lưu ý: thêm dòng vào DoD nghĩa là mọi story từ giờ tốn thêm công. Khi bàn ở retro, hãy nói rõ điều này và cân nhắc với lượng việc team nhận ở các sprint tiếp theo.

Khi nào cần checklist sẵn sàng, và giữ nó nhẹ thế nào?

Nếu team hay phải dừng giữa sprint vì story chưa rõ, một vài câu kiểm tra trước Sprint Planning có thể giúp. Hãy dùng chúng như câu hỏi khi refine, không như cổng duyệt. Mỗi câu trả lời “chưa” dẫn tới một việc cần làm, không phải lý do để loại story.

Để ý câu cuối của sơ đồ: chi tiết nhỏ được phép làm rõ trong sprint. Mike Cohn nhấn mạnh điểm này. Đòi mọi thứ phải xong 100% trước khi bắt đầu sẽ làm chậm team hơn là giúp team.

Phần chuẩn bị cho buổi Sprint Planning được nói kỹ hơn trong bài “Sprint planning: PO chuẩn bị gì”.

• Sprint planning: PO chuẩn bị gì

Ví dụ: sửa một DoD mơ hồ thành DoD kiểm được

Ví dụ minh họa: team app đặt bàn ở đầu bài có một DoD cũ năm dòng, chép từ đâu đó. Sau buổi demo không như ý, team ngồi lại và sửa từng dòng theo bước 3. Ngưỡng thời gian tải trong bảng là con số team tự chọn để bắt đầu, ghi lại để xem lại sau vài sprint.

Team cũng thêm một dòng mới từ chính buổi demo: “Bộ phận vận hành liên quan đã được báo thay đổi trước khi phát hành”. Story quay lại backlog vì chưa được kiểm trên staging, tức chưa đạt DoD, đúng như Scrum Guide nói. Còn chuyện email báo hủy là thiếu AC của story, không phải thiếu DoD, nên PO bổ sung nó vào AC.

Đây là chỗ đáng tách bạch: không phải lỗ hổng nào cũng nên sửa bằng DoD. Hỏi một câu: điều này cần đúng với mọi story, hay chỉ story này? Mọi story thì vào DoD. Chỉ story này thì vào AC.

Mẫu DoD và checklist sẵn sàng để dùng ngay

Hai mẫu dưới đây là điểm bắt đầu để mang vào buổi họp với team, không phải bản chốt. Xóa dòng nào team chưa làm được với mọi story, chuyển nó xuống mục “muốn thêm sau”.

Definition of Done của team [tên team]
Phiên bản [số], cập nhật [ngày]
Áp dụng cho mọi story và bug trước khi chuyển sang Done.

Code
- [ ] Ít nhất một dev khác đã review và duyệt
- [ ] Đã merge vào nhánh chính, build chạy qua
- [ ] Test tự động liên quan chạy qua (nếu team đã có)

Kiểm thử
- [ ] QA đã kiểm hết AC của story trên môi trường [tên môi trường test]
- [ ] Không còn lỗi mức nghiêm trọng hoặc cao đang mở
- [ ] Đã thử trên [thiết bị hoặc trình duyệt team hỗ trợ]

Vận hành và người dùng
- [ ] Bộ phận liên quan ([CSKH, vận hành, kinh doanh]) đã được báo thay đổi
- [ ] Hướng dẫn hoặc tài liệu đã cập nhật nếu hành vi thay đổi
- [ ] Có cách tắt hoặc quay lại bản cũ nếu cần (khi áp dụng)

Muốn thêm sau (chưa áp dụng):
- [dòng]

Xem lại ở retrospective: [mỗi sprint hoặc mỗi hai sprint]

Checklist sẵn sàng (dùng khi refine, không phải cổng chặn)
Story: [tên hoặc link]

- [ ] Nói được trong một câu: giúp ai, thay đổi điều gì
- [ ] Có AC đủ để QA viết kịch bản kiểm thử
- [ ] Team đã ước lượng và thấy vừa một sprint
- [ ] Phụ thuộc ngoài team đã có người nhận và ngày dự kiến
- [ ] Thiết kế đủ để bắt đầu, chi tiết nhỏ chốt trong sprint

Câu hỏi còn mở (ai trả lời, trước ngày nào):
- [câu hỏi]

Thiếu một dòng: cả team bàn ở planning có nhận story hay không, không tự động loại.

Những lỗi hay gặp với DoD và DoR

• PO tự viết DoD rồi giao cho team. Dev và QA không thấy đó là cam kết của mình, nên dễ bỏ qua khi gấp. Hãy tạo nó cùng nhau.
• Chép một DoD hai mươi dòng từ mạng. Bắt đầu với những dòng team làm được ngay, thêm dần qua retro.
• Viết dòng không kiểm được. “Code chất lượng”, “đã test kỹ” sẽ thành tranh luận. Mỗi dòng phải trả lời được có hoặc không.
• Bỏ qua DoD “một lần thôi” khi sắp hết sprint. Nếu một dòng liên tục bị bỏ, đem ra retro để sửa hoặc bỏ hẳn, đừng để nó tồn tại chỉ trên giấy.
• Nhét yêu cầu riêng của một story vào DoD. Điều chỉ đúng với một story thuộc về AC.
• Dùng DoR như cổng chặn. Dev từ chối story vì thiếu một chi tiết nhỏ, hoặc PO phải hoàn tất đặc tả trước khi được bàn. Checklist sẵn sàng là để làm rõ cùng nhau, không phải để đẩy việc qua lại.

Tóm tắt

• Definition of Done là chuẩn chất lượng chung cho mọi việc, là phần chính thức của Scrum. Việc chưa đạt DoD thì chưa được phát hành hay trình bày ở Sprint Review.
• Definition of Ready không có trong Scrum Guide. Nếu dùng, giữ nó ngắn và dùng như hướng dẫn khi refine, không phải cổng chặn.
• Acceptance criteria là điều kiện riêng của từng story. Điều cần đúng với mọi story thì vào DoD, chỉ đúng với một story thì vào AC.
• Tạo DoD đầu tiên cùng cả team: kể hiện trạng, chọn dòng làm được ngay, viết để kiểm được, dán lên và dùng.
• Xem lại DoD ở mỗi retrospective, ghi phiên bản và ngày, nâng chuẩn dần theo sức thật của team.

Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.

• Nhận bài mới qua email

Câu hỏi thường gặp

Definition of Done là gì?

Definition of Done (DoD) là danh sách chuẩn chất lượng mà mọi story hay bug phải đạt trước khi team gọi là xong, ví dụ đã review code, đã kiểm hết acceptance criteria trên môi trường test. Theo Scrum Guide 2020, việc chưa đạt DoD thì chưa được phát hành và chưa được trình bày ở Sprint Review.

Definition of Ready có bắt buộc trong Scrum không?

Không. Scrum Guide 2020 không nhắc tới Definition of Ready; đây là thực hành tùy chọn một số team dùng khi refine backlog. Nếu dùng, nên giữ nó ngắn và xem như hướng dẫn, không phải cổng chặn việc vào sprint.

Definition of Done khác acceptance criteria thế nào?

Acceptance criteria là điều kiện riêng của từng story, nói tính năng đó phải làm được gì. Definition of Done là chuẩn chung áp dụng cho mọi việc của team. Một story chỉ xong khi đạt cả hai.

Nguồn kiểm tra

• Scrum Guide 2020: Definition of Done
• Scrum.org: Why isn't the Definition of Ready described in the Scrum Guide?
• Mountain Goat Software: The Dangers of a Definition of Ready
• Scrum.org: Definition of Done vs Acceptance Criteria
• Scrum.org: What is the Definition of Ready in Scrum?

Bài liên quan

• User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
• Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
• Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
• Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.