Login

Definition of Done: khi nào một công việc mới thật sự được coi là xong?

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Lập trình viên nói 'xong rồi', tester nói 'chưa xong', khách hàng nói 'sao chưa chạy được?'. Cả ba đều đúng theo cách hiểu riêng của mình. Definition of Done (DoD) là thỏa thuận chung để chấm dứt kiểu tranh cãi đó: một công việc chỉ xong khi đáp ứng cùng một bộ tiêu chuẩn.

Definition of Done là gì?

DoD là bản mô tả chính thức trạng thái của sản phẩm khi nó đạt chất lượng cần thiết. Trong Scrum, đây là cam kết gắn liền với Increment: một mục chỉ được tính là xong khi thỏa mãn DoD, và nếu không thì chưa thể đưa vào Increment hay trình bày ở Sprint Review. Nó là danh sách kiểm tra áp dụng cho mọi mục, khác với tiêu chí chấp nhận vốn riêng cho từng story.

Vì sao cần DoD?

  • Chung một cách hiểu: không còn 'xong theo kiểu của tôi'.
  • Giữ chất lượng ổn định: không bỏ qua kiểm thử hay tài liệu khi chạy deadline.
  • Tránh nợ ẩn: việc 'gần xong' tích lũy thành khối lượng khổng lồ cuối dự án.
  • Dự báo tiến độ chính xác hơn: số liệu về việc đã xong đáng tin cậy.

Ví dụ DoD cho một nhóm phát triển web

Một mục được coi là xong khi:

  1. Mã nguồn đã được review bởi ít nhất một đồng đội.
  2. Kiểm thử tự động mới và cũ đều qua trong CI.
  3. Không có cảnh báo từ công cụ kiểm tra mã (lint) ở mức lỗi.
  4. Tiêu chí chấp nhận đã được kiểm tra và Product Owner đồng ý.
  5. Đã triển khai lên môi trường staging và kiểm tra hoạt động.
  6. Tài liệu liên quan (API, hướng dẫn sử dụng) đã được cập nhật nếu cần.
  7. Không còn lỗi nghiêm trọng đã biết.
  8. Đã có giám sát hoặc log cần thiết cho tính năng mới.

Đây chỉ là ví dụ minh họa. DoD của bạn phải phản ánh thực tế và tiêu chuẩn chất lượng của chính nhóm.

Cách xây dựng DoD cho nhóm

  1. Cùng liệt kê: tổ chức một buổi ngắn, mỗi người ghi các việc cần làm để tin rằng một mục thật sự xong.
  2. Gom nhóm và chọn: giữ những mục thực sự cần, bỏ các mục chưa ai làm nổi.
  3. Bắt đầu vừa sức: tốt hơn là một DoD ngắn được tuân thủ nghiêm túc so với danh sách dài không ai theo.
  4. Đặt ở nơi dễ thấy: dán lên bảng hoặc đưa vào mẫu pull request.
  5. Tự động hóa những gì có thể: kiểm thử, lint, triển khai staging nên do CI kiểm tra.
  6. Nâng cấp dần: sau retrospective, thêm tiêu chuẩn mới khi nhóm sẵn sàng.

Dùng mẫu pull request như checklist

Nhiều nhóm đưa DoD vào mẫu mô tả pull request để người gửi tự đánh dấu:

## Truoc khi gop
- [ ] Da tu review code cua minh
- [ ] Da them hoac cap nhat kiem thu
- [ ] CI da xanh
- [ ] Da cap nhat tai lieu neu can
- [ ] Da kiem tra tren staging

Cách này biến DoD từ tài liệu thành thói quen hằng ngày.

Definition of Ready: người bạn đồng hành

Nếu DoD nói khi nào việc kết thúc, thì Definition of Ready (DoR) nói khi nào việc đủ rõ để bắt đầu: có mô tả, tiêu chí chấp nhận, đã được ước lượng, các phụ thuộc đã rõ. Lưu ý rằng DoR không phải một phần chính thức của Scrum Guide và dùng quá cứng nhắc có thể thành thủ tục gây cản trở. Hãy xem nó là hướng dẫn linh hoạt.

Những sai lầm thường gặp

  • Viết DoD đẹp rồi để đó, không ai theo.
  • DoD quá tham vọng so với năng lực hiện tại, nên bị phớt lờ.
  • Cho phép ngoại lệ liên tục dưới áp lực deadline.
  • Quên rằng DoD áp dụng cho từng mục, không chỉ cho cả sprint.
  • Nhầm lẫn giữa DoD và tiêu chí chấp nhận.

Kết luận

Definition of Done là lời hứa của nhóm với chính mình và với khách hàng về chất lượng. Hãy ngồi cùng đội, viết ra năm đến tám tiêu chí thực tế và bắt đầu áp dụng ngay sprint tới. Bạn sẽ thấy các cuộc tranh luận 'xong chưa' giảm hẳn.

Nếu muốn học cách đảm bảo chất lượng xuyên suốt dự án phần mềm, hãy xem các khóa học trên codebem.com.

author_photo
Nguyễn Đình Cường

0 comment