Ước lượng phần mềm: three-point, reference class, T-shirt

Câu hỏi khó nhất mà một tech lead phải trả lời - "việc này mất bao lâu?" - không có lời đáp trung thực dưới dạng một con số đơn lẻ. Câu trả lời trung thực luôn là một khoảng kèm mức tin cậy. Chương này dạy bốn kỹ thuật để cho ra một khoảng đủ vững để bảo vệ, hướng dẫn khi nào nên dùng cái nào, và cách giữ cho team trung thực với chính mình về việc hiệu chỉnh ước lượng theo thời gian.

Khi nào ước lượng thật sự cần phải chính xác?

Có ba tình huống cần độ chính xác cao. Còn lại, sai số ở mức bậc cường độ là đã đủ.

Cam kết ràng buộc với bên ngoài. Một deadline pháp lý, một hợp đồng có điều khoản phạt với khách hàng, hay một chiến dịch marketing đã gắn vào ngân sách quảng cáo. Doanh nghiệp phải chi tiền dựa trên ước lượng, vì vậy ước lượng phải đi kèm khoảng tin cậy chứ không thể là phỏng đoán mơ hồ.

Lập kế hoạch quý. Tổ chức cần biết quý này sẽ làm xong những gì để sắp xếp dependency giữa các team. Ước lượng kém ở khâu này gây xáo trộn dây chuyền tới nhiều team khác.

Quyết định build vs buy. Lựa chọn giữa "tự xây" và "license SaaS" xoay quanh chi phí. Khi đó, ước lượng cho phương án build phải đủ chắc chắn để bảo vệ được trước hội đồng.

Còn lại - các sprint thông thường, các spike khám phá, các công cụ nội bộ - thì "size sơ bộ" là đủ. Ước lượng quá kỹ cũng là một loại chi phí.

Cái giá của việc ước lượng kém là gì?

Có ba kiểu lỗi thường lộ ra về sau.

Sprint hành quân kiểu tử thần. Dự án cam kết một ngày dựa trên ước lượng số đơn lẻ trong trường hợp lạc quan. Khi thực tế ập đến, team phải làm cuối tuần để kịp ngày. Chất lượng đi xuống, tỉ lệ nghỉ việc đi lên.

Pad ước lượng quá tay. Team học được bài học từ lần hành quân tử thần trước đó và bắt đầu nhân ba mọi ước lượng cho chắc. Bây giờ, ước lượng thật sự là 6 tuần nhưng họ báo 18 tuần; lãnh đạo dần dần mất niềm tin vào con số.

Tê liệt khi ra quyết định. "Chưa quyết được build hay buy đến khi nào ước lượng được phương án build." Việc ước lượng kéo dài cả một tháng. Đến lúc đó, phương án buy đã đổi giá rồi.

Bộ công cụ ước lượng tối thiểu trông thế nào?

Có bốn kỹ thuật, tăng dần về độ chi tiết và độ chính xác:

flowchart LR
    TS[T-Shirt sizing<br/>S/M/L/XL<br/>5 phút] --> RC[Reference class<br/>3-5 dự án cũ<br/>30 phút]
    RC --> TP[Three-point<br/>best/likely/worst<br/>1 giờ mỗi item]
    TP --> PP[Planning poker<br/>cả team<br/>2 giờ mỗi backlog]

Mỗi kỹ thuật phù hợp với một giai đoạn khác nhau. T-shirt dùng ở giai đoạn ý tưởng; reference class dùng ở kickoff; three-point dùng khi planning chi tiết; planning poker dùng khi backlog đã được chia thành story. Phần lớn team nhảy thẳng vào planning poker và bỏ qua các kỹ thuật ở thượng nguồn - vốn là chỗ bắt được những lỗi sai về bậc cường độ.

Three-point estimation chạy thực tế ra sao?

Với mỗi task, hãy hỏi ba con số:

• Best case (B) — mọi thứ diễn ra đúng ý.
• Most likely (M) — phỏng đoán trung thực.
• Worst case (W) — các bất ngờ trong khâu tích hợp ập đến.

Sau đó tính ước lượng theo PERT và độ lệch chuẩn:

estimate = (B + 4M + W) / 6
stddev   = (W - B) / 6
range    = estimate ± 2 * stddev   (95% tin cậy)

Ví dụ: một task có B=2 ngày, M=4 ngày, W=10 ngày sẽ cho ra estimate = (2 + 16 + 10) / 6 = 4.67 ngày, stddev = 1.33 ngày, khoảng tin cậy 95% = 2-7 ngày. Khi báo, hãy báo khoảng chứ đừng báo điểm.

Cộng các estimate và stddev trong toàn dự án (variance có tính chất cộng được) để có khoảng ở cấp dự án. Cú sốc của phần lớn team là phát hiện ra cái khoảng đó rộng đến mức nào khi các con số W cộng dồn lại - và đó chính là điểm cốt yếu: cho lãnh đạo nhìn thấy phép toán bằng chính mắt họ.

Log reference class cụ thể là gì?

Đây là một file yaml đơn giản trong repo của team, được cập nhật sau mỗi retrospective:

reference_class:
  - project: "Admin dashboard cho billing"
    started: "2026-01-15"
    shipped: "2026-03-10"
    elapsed_weeks: 8
    initial_estimate_weeks: 4
    actual_vs_initial: 2.0x
    pattern: "Admin CRUD + 2 report"
    surprises: "rate limit auth provider; QA env unstable 1 tuần"

  - project: "Tích hợp webhook inventory"
    started: "2026-02-20"
    shipped: "2026-04-05"
    elapsed_weeks: 6
    initial_estimate_weeks: 3
    actual_vs_initial: 2.0x
    pattern: "tích hợp API third-party"
    surprises: "edge case không tài liệu của vendor SDK"

  - project: "Pipeline re-index search"
    started: "2026-03-01"
    shipped: "2026-04-10"
    elapsed_weeks: 6
    initial_estimate_weeks: 6
    actual_vs_initial: 1.0x
    pattern: "migration Elasticsearch"
    surprises: "không - đã có dự án trước tương tự"

Có hai điểm đáng chú ý. Một là actual_vs_initial thường xuyên ở mức ~2x với những pattern lần đầu làm và ~1x với những pattern đã lặp lại. Hai là cột surprises ghi lại lý do cụ thể, và đây sẽ trở thành đầu vào cho risk register của quý sau (chương 3).

Ước lượng ở quy mô đa team thì khác ra sao?

Có ba thay đổi khi quy mô vượt 50+ engineer và nhiều team:

• Đơn vị là capacity, không phải duration. Dự án lớn được ước lượng theo team-quý, chứ không phải người-ngày. Đơn vị là kiểu "việc này cần Team A trong một quý và Team B trong hai tháng".
• Gantt dependency. Các dependency liên team bắt đầu xuất hiện. Khi việc của Team B phụ thuộc vào API của Team A, các slip ở trường hợp xấu sẽ cộng dồn theo dây chuyền. Dùng Mermaid gantt trong chương planning để lộ rõ chuỗi phụ thuộc.
• Cửa sổ tin cậy theo từng phase. Discovery có ~50% tin cậy; build có ~80%; launch có ~95%. Khoảng ước lượng sẽ thu hẹp dần khi các unknown được đóng lại. Khi báo, hãy báo kèm mức tin cậy ở thời điểm đó.

Sai lầm lớn nhất ở quy mô này là coi kế hoạch quý như một hợp đồng cố định. Thực ra nó là một dự báo có khoảng tin cậy, và cái khoảng đó sẽ thu hẹp lại theo thời gian.

Ước lượng có thể tạo ra những kiểu lỗi nào?

• Neo vào con số đầu tiên. PM nói "chúng tôi hy vọng 4 tuần" và rồi mọi three-point estimate của team đều xúm quanh con số 4. Cách phòng: hỏi từng engineer riêng lẻ trước, sau đó công khai cùng lúc; planning poker được tạo ra chính để code-hoá nguyên tắc này.
• Pad cho an toàn. Team học được rằng ước lượng sẽ thành cam kết, nên nhân ba mọi con số. Cách phòng: theo dõi minh bạch estimate vs actual ở mức team, và thưởng cho việc hiệu chỉnh đúng chứ không thưởng cho việc kịp ngày.
• Decomposition như sân khấu. Chia một task 4 tuần thành 40 task một ngày trông có vẻ chỉn chu nhưng không cung cấp thêm thông tin gì. Các unknown lớn không nằm trong việc phân rã. Cách phòng: spike thử cái unknown rủi ro nhất trong 1-2 ngày trước, rồi mới re-estimate.
• Một phương pháp dùng cho mọi việc. Dùng planning poker cho mọi quyết định là phí thời gian. Dùng T-shirt cho bức tranh lớn, three-point cho các dự án có cam kết, còn planning poker chỉ cho cấp sprint.

Khi nào ước lượng chi tiết là lãng phí thời gian?

Có hai trường hợp.

Khám phá có hạn thời gian rõ. "Có hai tuần để xem cái này có khả thi không." Khi đó không cần ước lượng; chỉ cần báo kết quả đúng vào deadline là xong.

Việc thực sự bắt buộc phải làm. Một bản vá bảo mật phải deploy trong tuần này. Việc ước lượng mất bao lâu không thay đổi quyết định bạn có làm hay không. Cứ làm rồi báo.

Kỷ luật ước lượng đáng giá khi lãnh đạo phải cam kết tài nguyên ra bên ngoài dựa trên câu trả lời. Dưới ngưỡng đó, "size sơ bộ + báo cáo thứ Sáu" tốt hơn là một nghi lễ ước lượng phức tạp.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: theo dõi rủi ro và issue

• artifact giúp bắt được những bất ngờ mà ước lượng không nhìn thấy. Sau đó, stakeholder và comms sẽ nói về cách truyền tải cái khoảng tin cậy này một cách trung thực mà không làm mất niềm tin của các bên liên quan.