Definition of Done / Ready

Delivery

Thiết lập DoD/DoR để team có cùng standard chất lượng và tránh tranh cãi sprint review.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Delivery cho PM/PO — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Delivery, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

DoR là checklist một story phải đạt TRƯỚC khi vào sprint; DoD là checklist nó phải đạt để được gọi là xong. Cả hai tồn tại để cùng một câu hỏi không phải hỏi lại mỗi sprint: “cái này xong chưa?”

Khi đã làm được

Đặt được hai checklist mà đội thật sự dùng: đủ chặt để ngăn story vỡ giữa sprint, đủ nhẹ để không giết tốc độ, và được xem lại mỗi quý. Giữ được nó khi gần deadline — đó là lúc chuẩn thật lộ ra.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/15 mục · còn khoảng 5 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Definition of Done / Ready là gì?

Hai checklist ở hai đầu của một story. DoR chặn ở đầu vào: story chưa đủ rõ thì không vào sprint. DoD chặn ở đầu ra: chưa đủ điều kiện thì chưa gọi là xong.

Giá trị thật không nằm ở nội dung checklist mà ở chỗ cả đội đã đồng ý trước — nên lúc gần deadline không phải tranh luận lại từ đầu.

Khi nào bạn gặp chuyện này

Tình huống	Bạn làm gì	Nếu không
Sprint review, PO nói chưa xong, dev nói xong rồi.	DoD viết ra và treo ở chỗ ai cũng thấy. Câu trả lời là tra checklist, không phải tranh luận.	Mỗi sprint lại tranh cãi từ đầu, và kết quả phụ thuộc ai kiên trì hơn hôm đó.
Một story vào sprint rồi vỡ giữa chừng vì thiếu thiết kế.	DoR phải có “design đã duyệt” và “dependency rõ”. Chưa đủ thì để lại refinement.	Đội mất nửa sprint chờ, và velocity trở nên vô nghĩa để dự báo.
Gần release, đội đề nghị bỏ qua phần monitoring cho kịp.	Hoặc giữ chuẩn, hoặc ghi thành nợ có tên và hạn trả. Không có lựa chọn thứ ba.	Tính năng lên production và không ai biết nó có chạy đúng không.

Definition of Ready (DoR)

Checklist một story phải đạt trước khi vào sprint. Mục đích: tránh story "blow up" giữa sprint do thiếu info.

User story format INVEST.
Acceptance criteria đầy đủ (happy + edge case).
Design mockup approved.
Dependency rõ (API, vendor, legal).
Estimate done.
Sample test data available.
Stakeholder sign-off cho scope.

Definition of Done (DoD)

Code reviewed + merged.
Unit test coverage đạt threshold (vd: 80%).
Integration test pass.
QA verified trên staging.
Documentation update (API doc, changelog, user help).
Feature flag config nếu rollout từng phần.
Monitoring/alerting setup.
PO accept demo.

DoD theo level

Story-level — như trên.
Sprint-level — release note ready, demo done, retro completed.
Release-level — performance test pass, security scan clean, rollback plan documented.

Phiên bản tối thiểu — bắt đầu từ đây rồi thêm

	Tối thiểu	Thêm khi đội đã quen
DoR	Có acceptance criteria; dependency rõ; đã ước lượng	Design đã duyệt; dữ liệu mẫu; stakeholder chốt phạm vi
DoD	Đã review code; QA kiểm trên staging; PO chấp nhận demo	Test tự động; tài liệu; monitoring; feature flag

Sai lầm thường gặp

Sai lầm	Vì sao hỏng	Làm thay bằng
DoD trên giấy mà không ai theo	Nó thành trang trí, và chuẩn thật là thứ khác.	Treo ở chỗ đội nhìn thấy, xem lại mỗi sprint.
Checklist quá khắt khe ngay từ đầu	Không khả thi, đội bỏ qua toàn bộ.	Bắt đầu bằng bản tối thiểu, thêm dần.
Bỏ qua khi gấp mà không ghi nợ	Ngoại lệ thành thông lệ.	Ghi thành một dòng có tên và hạn trả.
Không bao giờ xem lại	Checklist viết cho đội một năm trước không còn đúng.	Một mục trong retro mỗi quý.

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Product Owner	Bạn là người chấp nhận, nên DoD là công cụ của bạn nhiều nhất.
Business Analyst	DoR là nơi công việc của bạn được nghiệm thu — acceptance criteria thiếu edge case sẽ lộ ra ở đây.
Engineering Manager	Bạn giữ DoD khi có áp lực; đó là lúc nó có ý nghĩa.
Scrum Master	Bạn chủ trì việc xem lại và giữ nó sống.

Definition of done — dấu hiệu bạn đã đạt

Sprint review không còn câu hỏi “story này xong chưa?”.
DoR và DoD được treo ở chỗ cả đội nhìn thấy.
Mỗi lần bỏ qua đều thành một dòng nợ có hạn.
Cả hai được xem lại ít nhất mỗi quý.

Hai danh sách, hai mục đích — và vì sao cần cả hai

	Definition of Ready	Definition of Done
Kiểm khi	Trước khi nhận việc vào sprint	Trước khi coi việc là xong
Bảo vệ ai	Đội — khỏi việc chưa rõ	Người dùng và đội sau — khỏi việc làm dở
Ai sở hữu	PO chuẩn bị, đội chấp nhận	Đội định nghĩa, tổ chức tôn trọng
Thiếu nó thì	Sprint trượt vì hiểu sai	"Xong" nghĩa khác nhau với mỗi người

Vì sao cả hai đều là danh sách, không phải cảm giác: khi không viết ra, "sẵn sàng" và "xong" trở thành thứ mỗi người hiểu một kiểu — và bất đồng chỉ lộ ra vào lúc tệ nhất, tức là lúc bàn giao.

Definition of Done — mẫu dùng được ngay

Mã nguồn đã được người khác đọc và duyệt.
Đã có kiểm thử tự động cho đường thuận và ít nhất một ca lỗi.
Đã chạy trên môi trường giống môi trường thật.
Điều kiện xác nhận đã được kiểm, gồm cả ca ngoại lệ.
Tài liệu và ghi chú vận hành đã cập nhật — nếu người trực sự cố lúc 2 giờ sáng không hiểu, thì chưa xong.
Không tạo thêm nợ kỹ thuật chưa được ghi nhận. Tạo thì phải ghi.
Đã có cách đo xem nó có tác dụng không — sự kiện theo dõi đã được cài.

Mục cuối là mục hay thiếu nhất và đắt nhất khi thiếu. Một tính năng ra mắt mà không đo được sẽ không bao giờ trả lời được câu "nó có tác dụng không" — và ba tháng sau, việc cài thêm sự kiện theo dõi tốn nhiều hơn và dữ liệu quá khứ đã mất.

Về độ dài: danh sách dài 20 mục sẽ bị bỏ qua. Bảy tới mười mục, và mỗi mục phải kiểm được trong vài phút.

Khi nào được phép phá quy tắc

Danh sách cứng tuyệt đối sẽ bị phá lén. Tốt hơn là định nghĩa rõ khi nào được phá và cái giá là gì.

Tình huống	Được phép bỏ qua	Điều kiện bắt buộc
Sự cố nghiêm trọng đang diễn ra	Kiểm thử tự động, tài liệu	Ghi nợ vào danh sách, sửa trong 48 giờ
Thử nghiệm sẽ vứt đi	Phần lớn danh sách	Phải xoá thật sau khi thử xong, có hạn
Sửa lỗi nhỏ một dòng	Môi trường giống thật	Vẫn phải có người đọc duyệt

Nguyên tắc: phá quy tắc thì phải ghi nợ. Nợ không ghi là nợ không ai trả — và nó tích tụ cho tới khi không ai biết nó đến từ đâu.

Hiccups thường gặp và cách xử lý

Hiccup	Vì sao xảy ra	Xử lý
"Xong" của đội khác với "xong" của PO	Không viết ra	Viết danh sách, dán chỗ ai cũng thấy, đọc lại mỗi khi có tranh cãi
Danh sách quá dài, không ai theo	Thêm dần qua thời gian	7–10 mục; rà lại hằng quý và bỏ mục không còn ý nghĩa
Việc "xong" nhưng QA trả lại liên tục	Điều kiện xác nhận không nằm trong danh sách	Thêm mục kiểm điều kiện xác nhận gồm ca ngoại lệ
Nợ kỹ thuật tích tụ không ai biết	Phá quy tắc mà không ghi	Bắt buộc ghi nợ mỗi lần phá, kèm hạn trả
Tính năng ra mắt rồi không ai biết có tác dụng không	Thiếu mục đo lường	Sự kiện theo dõi là một phần của "xong", không phải việc làm sau

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Đội phát triển	Danh sách "xong" là thứ bảo vệ bạn khỏi áp lực giao hàng dở
Product Owner	Bạn tôn trọng danh sách của đội; đổi lại đội tôn trọng cam kết
QA	Bạn đưa điều kiện xác nhận vào danh sách để không phải trả việc lại nhiều lần
Scrum Master	Bạn giữ cho danh sách không phình ra và không bị bỏ quên
Người trực sự cố	Mục tài liệu vận hành là dành cho bạn lúc 2 giờ sáng