“……我們的估算技術錯誤地將努力與進步相混淆，隱藏了人和月份可以互換的假設。”〜Frederick P. Brooks，Jr.
軟體開發估算很難，而且不可靠。這不是一個新問題；我們幾十年來一直在努力估算。然而，我們仍然堅持估算——它們提供了一種（很大程度上是錯誤的）安全感。
問題在於我們所做工作的性質。它通常需要推理和解決問題；我們需要坐下來思考問題，直到我們能夠“弄清楚”。我們的估算試圖為本質上不可預測的工作帶來一定程度的可預測性。
舉例來說，假設你熟悉國際象棋規則。如果我把棋盤放在你面前，正在對弈，我告訴你白棋三步就可以將死——你要花多長時間才能弄清楚這三步是什麼？記住，你知道規則，知道棋子如何移動，也知道棋盤現在是什麼樣子。換句話說，你擁有人們想象你需要的所有資訊.
一、為什麼估算很難正確
對於軟體專案，我們必須考慮許多因素，包括技術、人員、需求和外部依賴關係。其中每個因素都存在可變性。
技術本身就很複雜——有多種程式語言、庫和工具。當我們把所有這些放在一起時，經常會出現意想不到的問題。原本只需五分鐘就能升級庫版本的更改可能會變成兩天的努力，因為新庫版本與某個地方的其他庫不相容，這意味著也需要更改。反過來，這需要額外的測試。一行程式碼中的拼寫錯誤可能會導致數小時的除錯。
人們的工作效率也並不總是一樣的——估計假設我們的能力都是一樣的，而且無論我們是否疲憊、沮喪或生病，我們都會以恆定的速度工作。但在現實世界中，情況並非如此。中斷是常有的，有時有人需要花一兩個小時來幫助同事（這並不是壞事）。
需求可能不明確，也可能隨著新資訊的出現而改變（而且應該如此）。如果開發人員開始實施新需求並發現有些東西不太合理，他們需要找人來為他們澄清。但如果那個人休假了，或者當天剩餘時間都在開會怎麼辦？“等待時間”會導致整體延遲——這意味著圍繞需求的一個問題就可能使估算無效。
外部依賴關係比需求變更更難控制——如果我們進入一個依賴外部供應商的世界，我們就要遵守他們的 SLA 來解決問題。如果外部依賴關係是 API，則意味著我們引入了多個額外的故障點——我們的伺服器、供應商的伺服器或兩者之間的任何網路元件的任何問題都會導致延遲。
估算還會讓人認為工作是可以分擔的——如果估計開發某個功能需要 10 天，這是否意味著兩個開發人員可以在 5 天內完成？或者 10 個開發人員可以在一天內完成？事實上，增加更多開發人員來嘗試加快這一程序只會增加溝通負擔，這可能會使情況變得更糟。
二、為什麼利益相關者需要估算
不難理解為什麼我們的利益相關者想要估算。歸根結底，有人會為我們所做的工作買單。他們有預算，有最後期限，有客戶需要滿足，還有投資回報率需要計算。如果我們能告訴他們預期結果和時間，這個過程就會變得更容易。
在其他一些行業中，任務可以定義得足夠明確，以便我們能夠可靠地估計它們。如果我們執行一條組裝小部件的生產線，並且我們知道組裝一個小部件需要 10 分鐘，那麼我們知道我們可以在一小時內組裝六個小部件。但是，我們的小部件（與我們的軟體不同）是標準化的 - 因此除非生產線關閉，否則我們不太可能偏離常態。在其他行業中行之有效的相同思維不能擴充套件到軟體。我們構建的每個創新解決方案都涉及解決一個新的、新穎的問題。我們可以借鑑過去的經驗，但我們不是在執行生產線。
三、傳統的估算方法
1.小時
這是不言自明的——我們估計某項特定任務需要花費一定數量的小時才能完成。實際上，人類在這方面很差勁，我們通常會犯錯。這也很危險，因為不同團隊成員對小時的估計各不相同——對於擁有 10 年 Java 經驗的開發人員來說，需要兩小時才能完成的任務，對於一個月前才開始學習 Java 的畢業生來說，很可能不會是兩小時的任務。
2.故事點
這是Scrum提出的方法。
故事點數是將任務相互比較的相對度量單位。換句話說，我們將從一個代理任務開始，例如“新增一個包含五個欄位的螢幕、一個 API 端點和一個資料庫表”，併為其分配一個任意值（通常基於斐波那契數列）。如果我們的代理任務分配了五個故事點數，並且我們估計下一個任務——“新增一個包含十個欄位的螢幕、兩個 API 端點和一個資料庫表”——我們可能會認為該任務稍微複雜一些，併為其分配八個故事點數。故事點數不代表天數、小時數或任何其他特定時間的指標——它們只是比較不同任務的一種方式。
然後，我們計算團隊在衝刺過程中完成的故事點數，並以此確定團隊的“速度”，這是一個指標，可以指示我們在衝刺期間可以完成多少故事點。該指標基於整個團隊，而不是個人。
估算故事點的過程稱為“規劃撲克”，它發生在包括整個開發團隊的待辦事項整理會議期間。很多人反對故事點，但分配故事點的過程非常有價值，因為它允許整個團隊討論和理解一項任務。我個人認為這仍然是一種比試圖估算小時數更好的方法。
四、替代方法
我們利用估算來創造一種可預測性。雖然估算既困難又不可靠，但還有其他方法可以創造可預測性。
可預測性可以來自定期的交付節奏——換句話說，我們定期向生產交付一些東西（即每兩週的衝刺後部署一次）。雖然我們無法可靠地預測什麼會投入生產，但我們幾乎可以保證每兩週會部署一些東西。由於我們將故事定義為增加實際業務價值的工作單元，這意味著我們正在不斷向更好的狀態邁進。
雖然開發工作通常不可分割，但我們可以透過為某個問題分配更多腦力來簡化它——例如結對程式設計或群體程式設計。這不是分工，而是合作解決同一問題。這可以加快開發速度，因為實際工作是解決問題而不是打字——兩個人更擅長解決問題。
透明度是關鍵——意外的驚喜是正常的，但作為開發團隊，請確保您的利益相關者瞭解您的進展和遇到的問題。
將任務分解成小的、精細的單元。小段程式碼更容易開發、更容易測試，而且由於其範圍有限，更容易預測。
如果您必須提供估算，請明確說明估算的前提條件。例如，您估計需要三天時間來實現一項功能，可能假設需求不會改變、不會有任何庫衝突，並且所有外部 API 始終可用。這可能不現實，但透過明確說明，您也可以幫助利益相關者瞭解潛在的複雜性。
總之，估算很難。將其作為指導方針和目標，但請記住，您的估算可能會出錯。不要試圖讓您的估算 100% 正確，而要專注於理解任務，逐步交付小部分工作，頻繁交付價值，並對您的利益相關者保持透明。