Vì sao việc ước lượng thất bại (và vì sao nó vẫn cần thiết)

• Trong phát triển phần mềm, việc ước lượng công việc thuộc miền phức hợp (Complex), nên về bản chất không thể ước lượng chính xác tuyệt đối, dù là với đội ngũ dày dạn kinh nghiệm
• Phong trào #NoEstimates là phản ứng chính đáng trước thực tế ước lượng bị lạm dụng thành mục tiêu hiệu suất, nhưng nếu bác bỏ hoàn toàn việc ước lượng thì tổ chức sẽ mất khả năng điều phối
• Giá trị cốt lõi của ước lượng không nằm ở việc dự đoán tương lai mà ở giao tiếp và điều phối dưới điều kiện bất định, điều rất cần cho hợp đồng bên ngoài, phụ thuộc giữa các nhóm và đánh giá ROI
• Theo Cone of Uncertainty của Steve McConnell, ở giai đoạn đầu dự án sai số ước lượng có thể lên tới 4 lần, và chỉ thu hẹp lại nhờ quá trình học hỏi
• Cần thay đổi thói quen tổ chức biến ước lượng thành cam kết, và áp dụng cách ước lượng dựa trên khoảng, nêu rõ giả định, hiệu chỉnh dần theo tiến độ

---

Vấn đề mà phong trào #NoEstimates thực sự đã giải quyết

• Các nhóm liên tục bị yêu cầu ước lượng khi gần như chưa biết gì về vấn đề, rồi con số đó được đưa vào roadmap và biến thành lời hứa với khách hàng
• Khi thực tế lệch khỏi con số ước lượng, nhóm bị chỉ trích là “trễ deadline”, dù đó chưa bao giờ là deadline họ đã đồng ý
• Bệnh lý cốt lõi là việc ước lượng bị biến chất từ dự báo thành cam kết (commitment)
• Giải pháp “đừng ước lượng nữa” giống như phản ứng với một chiếc nhiệt kế hỏng bằng cách phủ nhận luôn khái niệm nhiệt độ
• Như Maarten Dalmijn nói, ước lượng không làm thay đổi khối lượng công việc thực tế; phát triển tính năng mất bao lâu thì vẫn mất bấy lâu
  • Điều mà ước lượng tác động tới không phải bản thân công việc mà là kỳ vọng (expectations) xung quanh nó
  • Quản lý kỳ vọng một cách trung thực và rõ ràng là công việc hoàn toàn đáng làm

Vì sao tổ chức thực sự cần ước lượng

• Điểm gần như luôn vắng mặt trong tranh luận #NoEstimates: ước lượng không phải cho nhóm thực hiện công việc, mà cho tổ chức xung quanh nhóm đó

• Có ba tình huống mà việc ước lượng là không thể tránh khỏi

• Cam kết bên ngoài (External commitments): hợp đồng khách hàng, phát hành gắn với chiến dịch marketing, deadline tuân thủ quy định... đều cần mô hình thời gian thực hiện để đánh giá tính khả thi

  • “Chúng tôi không làm ước lượng” không phải là câu trả lời có thể đưa cho khách hàng, và có thể dẫn tới mất hợp đồng

• Phụ thuộc giữa các nhóm (Inter-team dependencies): khi nhóm B phải chờ nhóm A hoàn thành, nếu nhóm A không đưa ra bất kỳ dự báo nào thì nhóm B không thể lập kế hoạch

  • Một tín hiệu thô như “có lẽ 6 tuần, tối đa 8 tuần” hữu ích hơn im lặng vô hạn, và đó không phải là kiểm soát mà là sự tôn trọng dành cho các thành viên của nhóm downstream

• Tính toán ROI: để quyết định nên xây tính năng X hay Y, cần một mô hình chi phí tương đối

  • Nếu mọi thứ đều bất khả tri thì không thể đưa ra trade-off hợp lý; mà nếu đằng nào cũng phải đoán thì phỏng đoán có cấu trúc, kèm giả định rõ ràng vẫn tốt hơn

Joseph Pelrine cho thấy bản chất khó khăn cố hữu của việc ước lượng

• Joseph Pelrine là Certified Scrum Trainer đầu tiên ở châu Âu, nghiên cứu Agile trong phần mềm qua lăng kính khoa học về độ phức tạp xã hội
• Ông thực hiện một thí nghiệm với hơn 300 người làm việc trong phát triển phần mềm Agile, yêu cầu họ đặt các hoạt động công việc hằng ngày vào các miền của khung Cynefin (mô hình tạo nghĩa của Dave Snowden)
  • Cynefin phân loại vấn đề thành bốn miền: Clear, Complicated, Complex và Chaotic
• Việc ước lượng công việc được xếp một cách nhất quán và lặp đi lặp lại vào miền Complex
• Điểm mấu chốt là sự khác biệt giữa Complicated và Complex:
  • Trong miền Complicated, quan hệ nhân quả có thể được nhận diện, chuyên gia có thể lần theo, và chuyên môn có thể tạo ra dự báo đáng tin cậy
  • Trong miền Complex, quan hệ nhân quả chỉ có thể nhận ra sau khi sự việc đã xảy ra, vì hệ thống quá đan xen, phụ thuộc bối cảnh và nhạy cảm với thay đổi nhỏ
• Đây là lý do phát triển phần mềm không giống sản xuất: gần như lúc nào cũng là xây thứ chưa từng tồn tại trên một codebase riêng, với động lực nhóm riêng
  • Phép so sánh với nghề mộc không hiệu quả vì tủ gỗ thì khá giống các tủ khác, còn một tính năng thì không hề gần giống một tính năng khác
• Ngay cả đội ngũ xuất sắc cũng chỉ có thể ước lượng ở mức bình thường, không phải vì thiếu năng lực mà vì độ chính xác trong miền Complex có giới hạn cố hữu
• Mục tiêu không phải là ước lượng cho đúng tuyệt đối, mà là đưa ra quyết định hữu ích dù biết rằng nó vốn sẽ không chính xác hoàn toàn

Cone of Uncertainty cho chúng ta biết điều gì

• Khái niệm Cone of Uncertainty của Steve McConnell: ở giai đoạn đầu dự án, sai số ước lượng có thể lệch 4 lần theo cả hai chiều (tức phạm vi tổng cộng tới 16 lần)
• Khi dự án tiến triển và các yếu tố chưa biết được xử lý (làm rõ yêu cầu, chốt kiến trúc, phát hiện và giải quyết vấn đề khó), chiếc nón sẽ thu hẹp lại
• Điều mỉa mai là: thời điểm ước lượng chính xác nhất lại là sát lúc hoàn thành, tức cũng là lúc nó ít cần thiết nhất
  • Giai đoạn đầu, khi ước lượng hữu ích nhất (vì vẫn còn có thể đổi hướng hoặc dừng dự án), lại là lúc ta biết ít nhất
  • Phần lớn tổ chức lại đưa ra những cam kết cứng nhất đúng vào giai đoạn sớm đó
• Hai hàm ý bổ sung:
  • Chiếc nón này là kịch bản tốt nhất của người ước lượng lành nghề, còn đa số nhóm còn làm kém hơn thế
  • Chốt ngày ngay từ giai đoạn ý tưởng ban đầu không phải là lập kế hoạch mà là ước điều ước rồi xếp lịch theo điều ước đó
  • Chiếc nón chỉ thu hẹp nhờ những quyết định loại bỏ bất định, chứ không phải chỉ vì thời gian trôi qua
  • Việc xác định phạm vi, giải quyết các ẩn số về kiến trúc, viết code thật và phát hiện trở ngại mới giúp nón thu hẹp; ngồi họp suốt 3 tuần thì không
• Cần nói rõ với stakeholder rằng “chất lượng của ước lượng phụ thuộc vào việc hiện ta đang ở đâu trong chiếc nón”
  • Tuần đầu tiên không thể đưa ra một con số kiểu “2 tuần”, nhưng có thể đưa ra khoảng và giải thích cần xác minh điều gì để thu hẹp nó
  • Phần lớn stakeholder sẽ chấp nhận nếu được giải thích về chiếc nón; chỉ là chưa ai từng nói với họ rằng có thể yêu cầu một khoảng thay vì một con số cố định

Vì sao dùng thang Fibonacci

• Tính phi tuyến của thang Fibonacci (1, 2, 3, 5, 8, 13, 21) thực hiện một công việc mang tính nhận thức luận
• Chênh lệch giữa 2 và 3 chỉ ở mức “nhận ra khác biệt tương đối”, nhưng bước nhảy từ 8 lên 13 mã hóa việc dải bất định đã rộng hơn chính giá trị ước lượng
  • Một story 13 điểm không có nghĩa là “chính xác là 13”, mà là “chắc chắn bất định hơn 8 nhưng chưa tới mức 21”
• Khoảng cách giữa các số Fibonacci phản ánh cách độ phức tạp thực sự mở rộng trong thực tế
  • Việc nhỏ có thể ước lượng tương đối được, còn việc lớn thì có nhiều ẩn số, điểm tích hợp và tình huống ngoài dự kiến nên khó dự báo theo cấp số nhân
  • Story từ 21 điểm (hoặc 13 điểm) trở lên thường có nghĩa là “ta chưa hiểu đủ công việc nên cần tách nhỏ nó ra”
• Một chức năng khác thường bị đánh giá thấp của ước lượng theo Fibonacci là những gì diễn ra trong cuộc trao đổi ước lượng
  • Nếu một người nói 3 còn người khác nói 13, bản thân con số hầu như không quan trọng; điều quan trọng là vì sao cùng một team lại nhìn cùng một story khác nhau như vậy
  • Có thể một bên phát hiện phụ thuộc nào đó, hoặc biết ràng buộc kỹ thuật không được ghi trong ticket
• Giá trị lớn nhất của ước lượng không nằm ở con số mà ở việc xác nhận liệu đã hình thành hiểu biết chung hay chưa
  • Nếu bỏ cơ chế ép buộc này đi, hiểu biết chung thường không hình thành cho đến tận ngày thứ ba của công việc, khi ai đó đụng phải độ phức tạp ẩn
• Đây là lý do khó đồng ý với lập luận của #NoEstimates rằng “họp ước lượng là lãng phí”: nếu vận hành tốt, chính cuộc trò chuyện đó tạo ra sự đồng thuận (alignment)
  • Câu trả lời cho những cuộc họp được tổ chức tệ không phải là hủy mọi cuộc họp

Bẫy cam kết (Commitment Trap) và cách tránh

• Rối loạn chức năng sâu nhất mà phong trào #NoEstimates phản ứng lại là việc ước lượng bị biến thành cam kết thông qua áp lực xã hội chứ không phải bằng logic
• Một kiểu thất bại liên quan: người không làm việc trực tiếp tạo timeline rồi ném xuống cho team, tạo ra tổ hợp tệ nhất là ước lượng sai + team không có quyền sở hữu với con số đó
  • Khi thực tế lệch đi, không ai biết ai chịu trách nhiệm nên mọi người đổ lỗi cho nhau
  • Những người thực thi công việc luôn phải là người sở hữu ước lượng; áp đặt ước lượng từ bên ngoài không phải là lạc quan mà là điềm báo của trò chơi đổ lỗi
• Khi nỗi ám ảnh deadline chiếm ưu thế, mọi cuộc trò chuyện đều co lại thành “làm sao kịp deadline?”, còn câu hỏi liệu ta có đang xây đúng thứ hay không biến mất khỏi tầm nhìn
• Cần tách riêng ba thứ mà đa số tổ chức hay nhầm lẫn:
  1. Ước lượng (Estimate): dự báo xác suất ở mức bất định hiện tại, cần đi kèm phát biểu rõ ràng về khoảng và các giả định
     • Ví dụ: “Nếu không đổi yêu cầu và nhận được câu trả lời cho các câu hỏi về API trước thứ Sáu tới, chúng tôi ước khoảng 4–6 tuần”
  2. Kế hoạch (Plan): cam kết về quy trình, không phải về kết quả
     • Ví dụ: “Chúng tôi sẽ làm trong 2 tuần rồi rà soát tiến độ và cung cấp dự báo cập nhật”
  3. Cam kết (Commitment): lời hứa về kết quả, chỉ nên đưa ra hiếm hoi và cẩn trọng khi chiếc nón đã đủ hẹp
     • Cam kết từ giai đoạn ý tưởng ban đầu không phải là táo bạo mà là liều lĩnh
     • Khi bị ép phải cam kết, hãy cố cam kết vào mức độ ưu tiên thay vì timeline; nếu vẫn không được thì đưa mức độ tin cậy vào như một phần của cam kết
• Thực hành tổ chức coi ước lượng là cam kết ngay từ lúc phát biểu chính là gốc rễ của rối loạn chức năng
  • Giải pháp mang tính chính trị của #NoEstimates (không nói con số nào nữa) là điều có thể hiểu được, nhưng cái giá là tổ chức mất khả năng phân bổ nguồn lực, sắp thứ tự phụ thuộc và nói chuyện trung thực với stakeholder bên ngoài
• Giải pháp tốt hơn là dạy về chiếc nón, giáo dục stakeholder và luôn nói rõ sự khác biệt giữa ước lượng và cam kết mỗi khi đưa ra con số
  • Cách này khó hơn và mất thời gian hơn việc từ chối ước lượng, nhưng thay vì né tránh tình huống có thể làm vỡ niềm tin, nó xây dựng niềm tin

Thực hành ước lượng tốt

• Ước lượng muộn hơn: chiếc nón chỉ thu hẹp nhờ học hỏi, nên hãy spike, viết code thăm dò và nói chuyện với team liên quan trước
  • Cần chống lại áp lực phải đưa ra con số trước khi có đủ hiểu biết để tạo ra con số có ý nghĩa
• Đừng phân rã quá mức trước khi bắt đầu: khi đối diện bất định, ta dễ muốn bẻ công việc thành các mảnh nhỏ hơn, nhưng phân rã đủ sâu không tự động tạo ra ước lượng đáng tin
  • Lập kế hoạch quá chi tiết từ đầu sẽ bị đóng cứng, khiến team bám vào nó ngay cả khi thực tế đã thay đổi, và cuối cùng độ lệch càng gây hỗn loạn hơn
  • Hãy bắt đầu bằng một kế hoạch đơn giản, dễ điều chỉnh
• Đưa ra khoảng thay vì ước lượng điểm: “3–5 tuần” trung thực hơn “4 tuần” nhưng gần như vẫn hành động được ở cùng mức độ
  • Nếu buộc chỉ được đưa một con số, hãy đưa điểm giữa của khoảng nhưng phải nói rõ đó là giá trị trung vị của khoảng
  • Hãy thống nhất với stakeholder về việc sử dụng Cone of Uncertainty và tham chiếu lại nó mỗi lần truyền đạt ước lượng
• Làm giả định trở nên hữu hình: ước lượng chỉ tốt bằng các giả định mà nó dựa vào, nên cần nói rõ như giả định không đổi phạm vi, giả định về cách tiếp cận kỹ thuật cụ thể, giả định team khác bàn giao vào ngày nào đó...
  • Những giả định chỉ nằm trong đầu sẽ trở thành hiểu lầm bùng lên đúng lúc tệ nhất
• Theo dõi độ chính xác nhưng không trừng phạt: mục tiêu là hiệu chỉnh (calibration), không phải đổ lỗi
  • Một team cùng ước lượng trong 6 tháng và xem lại độ chính xác sẽ dần phát triển cảm nhận chung về chỗ nào họ thường ước lượng quá cao hay quá thấp
  • Nếu trừng phạt ước lượng sai, team sẽ phòng thủ bằng cách thổi phồng ước lượng, và ước lượng bị thổi phồng còn vô dụng hơn ước lượng trung thực nhưng bất định
  • Trong miền Complex, ước lượng sai không phải là khuyết điểm tính cách mà là thuộc tính của chính miền đó
• Trên 8 thì phải tách: story Fibonacci 13 hoặc 21 gần như luôn chứa độ phức tạp ẩn chưa được bộc lộ
  • Hành động tách nhỏ buộc team phải diễn đạt rõ thực sự mình biết gì
  • Thường sẽ phát hiện trong 3 story con thì 2 cái nhỏ, còn mọi bất định dồn vào 1 cái

Sự thật khó chịu với cả hai phe

• Ước lượng không phải là tính toán mà là một hình thức giao tiếp; mục tiêu không phải đoán đúng tương lai mà là hỗ trợ điều phối và ra quyết định dưới bất định
• Các kiểu thất bại của ước lượng không ngẫu nhiên mà có tính hệ thống: ước lượng quá sớm, coi khoảng như điểm, coi ước lượng như cam kết, bỏ qua vị trí nhận thức luận trong chiếc nón bất định, và áp đặt ước lượng lên người thực thi
• Điều Dalmijn gọi là Complex Work Estimation Fallacy: niềm tin rằng nếu ước lượng thường xuyên hơn, cải tiến quy trình hơn và làm việc cùng nhau lâu hơn thì cuối cùng sẽ đạt được ước lượng chính xác
  • Trong miền Complex, giới hạn độ chính xác của ước lượng không phải là hàm của độ trưởng thành team mà là hàm của chính miền đó
  • Team có thể khá hơn nhưng không thể trở nên chính xác tuyệt đối; nhầm lẫn giữa hai điều này sẽ khiến tổ chức trừng phạt team vì những thứ vốn nằm ngoài khả năng kiểm soát của họ
• Từ chối ước lượng chỉ là rút khỏi trò chơi điều phối
  • Điều đó có thể khả thi với những team vận hành hoàn toàn độc lập, continuous delivery liên tục và không có cam kết bên ngoài, nhưng phần lớn sự nghiệp không diễn ra trong bối cảnh như thế
• Lựa chọn không phải là “ước lượng tệ” hay “không ước lượng”, mà là giữa ước lượng vô thức, chất lượng thấp (thứ tổ chức vẫn sẽ tự tạo ra dù không có bạn) và ước lượng tường minh, khiêm tốn, dựa trên khoảng, với giả định được phơi bày
• Vì ước lượng công việc nằm trong miền Complex, ta phải tiếp cận nó bằng tư duy về độ phức tạp: khám phá, quan sát, phản hồi, ước lượng, theo dõi, hiệu chỉnh, rồi lặp lại
• Chiếc nón không thu hẹp nhờ chờ đợi mà thu hẹp nhờ học hỏi