AllianceProject Handbook
← Knowledge

Tổ chức công việc

Ước lượng và cam kết

Ước lượng là dự đoán, cam kết là lời hứa. Trộn hai thứ này là nguồn gốc của phần lớn xung đột giữa đội phát triển và phần còn lại của công ty.

Cập nhật 12/09/2026ước lượngkế hoạch

Phân biệt hai thứ hay bị trộn

Ước lượngCam kết
Bản chấtDự đoán có sai sốLời hứa
Ai đưa raNgười sẽ làm việc đóĐội, sau khi cân nhắc
Khi nào đúngXấp xỉ, có khoảngPhải giữ được
Khi sai thìCập nhật lại, chuyện thườngPhải báo sớm, đây là chuyện lớn

Sai lầm phổ biến: hỏi "làm bao lâu?", nghe "khoảng ba ngày", rồi ghi vào lịch như một lời hứa. Sau đó khi tới ngày thứ tư thì trách đội thất hứa — trong khi thực ra chưa ai hứa gì.

Quy tắc: không biến một ước lượng thành cam kết mà không hỏi lại người ước lượng.

Ước lượng thế nào

Chỉ ước lượng hạng mục đã đạt Definition of Ready. Ước lượng một thứ chưa rõ yêu cầu là đoán mò, và con số đoán mò vẫn sẽ bị ghi vào lịch như thật.

Dùng thang thô, không dùng số chính xác:

CỡNghĩaNgày công
SRõ ràng, đã làm thứ tương tự0,5 – 1
MRõ, nhưng có vài chỗ phải nghĩ2 – 3
LCó phần chưa chắc, cần tìm hiểu4 – 5
XLChưa đủ hiểu để ước lượngChẻ nhỏ, không nhận

XL không phải một cỡ, nó là tín hiệu dừng lại. Gặp XL thì tách một việc tìm hiểu có giới hạn thời gian (một ngày), xong rồi ước lượng lại.

Ước lượng thô thế này chính xác không kém số chi tiết, mà tốn ít thời gian hơn nhiều. Không ai đoán được "2,5 ngày" khác "3 ngày" ở chỗ nào.

Ai ước lượng

Người sẽ làm. Không phải chủ kỹ thuật, không phải người làm việc tương tự năm ngoái.

Khi nhiều người cùng ước lượng lệch nhau, đó là thông tin quý: người ước lượng cao thường đang thấy một rủi ro mà người kia chưa thấy. Hỏi họ thấy gì, thường lộ ra một trường hợp biên chưa ai nghĩ tới. Đây là shift left ở dạng rẻ nhất — phát hiện rủi ro trước khi viết dòng code nào.

Ước lượng luôn thiếu, và vì sao

Con người ước lượng thấp một cách có hệ thống, vì khi ước lượng ta hình dung đường đi thuận lợi và bỏ quên:

  • Review và sửa theo góp ý.
  • Viết test.
  • Trường hợp biên: rỗng, lỗi, mất mạng, quyền không đủ.
  • Cập nhật tài liệu.
  • Họp, hỗ trợ người khác, ngắt quãng.
  • Chờ người khác duyệt.

Cách chữa không phải là "cố ước lượng chính xác hơn". Cách chữa là:

  1. Definition of Done đã tính sẵn review, test, tài liệu — ước lượng phải bao gồm toàn bộ những thứ đó.
  2. Chỉ cam kết 70% sức chứa lý thuyết.
  3. Đo tốc độ thật của đội qua vài sprint, rồi dùng số thật thay vì dùng niềm tin.

Cam kết thế nào

Đội cam kết một phạm vi cho một sprint, sau khi đã xem ước lượng và sức chứa còn lại. Cam kết là của cả đội, không phải của từng cá nhân với quản lý.

Khi cam kết có nguy cơ vỡ, luật là: báo ngay khi biết, không chờ tới hạn.

Một cam kết trễ mà báo trước năm ngày thì còn xoay được: cắt phạm vi, đổi người, hạ kỳ vọng. Cùng cam kết đó báo vào đúng ngày hết hạn thì không còn lựa chọn nào. Che giấu tiến độ xấu gây thiệt hại lớn hơn nhiều so với bản thân việc trễ.

Trong đội này, báo trễ sớm không bị phạt. Che giấu thì có.

Hạn bên ngoài ấn xuống

Khi có hạn cứng từ bên ngoài — sự kiện, hợp đồng, mùa vụ — thứ được điều chỉnh là phạm vi, không phải chất lượng, không phải sức khoẻ đội.

Cách làm: chia hạng mục thành ba lớp ngay từ đầu.

LớpNghĩa
Bắt buộcKhông có thì bản release vô nghĩa
Nên cóLàm được thì tốt, thiếu vẫn dùng được
Nếu còn thời gianCắt đầu tiên, không tiếc

Đưa ba lớp này cho người đặt hạn xem từ đầu, và nói rõ lớp 3 rồi lớp 2 sẽ bị cắt nếu thiếu thời gian. Như vậy lúc cắt không ai bất ngờ.

Đo lại để ước lượng tốt hơn

Cuối mỗi sprint, ghi hai con số cho mỗi hạng mục: ước lượng và thực tế. Sau bốn sprint sẽ thấy hệ số lệch của đội — ví dụ thực tế thường gấp 1,4 lần ước lượng.

Dùng hệ số đó để hiệu chỉnh, đừng dùng để trách ai. Ước lượng là kỹ năng học được bằng cách đối chiếu lại, và chỉ học được khi người ước lượng không sợ bị phạt vì đoán sai.