軟體估算的本質：Kent Beck 揭露時間預測的真相

軟體開發最令人困擾的問題之一，莫過於回答「這個功能什麼時候能完成」這個看似簡單的問題。每當主管或客戶提出這個問題時，開發人員總是陷入兩難 - 給出確切日期怕承諾過度，不給答案又顯得不專業

極限編程（Extreme Programming）的創始人 Kent Beck，在「現代軟體工程」頻道的訪談中，深度剖析了軟體估算這個令人頭痛的議題。他的見解不僅顛覆了我們對估算的傳統認知，更提出了實用的解決之道

估算問題的核心：誰想知道？為了什麼？

Kent Beck 以自己的親身經歷為例，生動地說明了估算問題的複雜性。他曾經管理一個團隊，負責開發適用於美國各州的軟體系統。在完成了大約 15 個州的版本後，經理不斷詢問「什麼時候能全部完成」

Kent 堅持不給出具體的完成日期，原因很簡單 - 每個州的情況都不同，缺乏明確的文件規範，而且團隊已經深刻體會到幾乎每個州都是特例，無法預測其複雜程度

更重要的是，Kent 發現了一個關鍵問題：給出具體日期對團隊而言是一個不對稱的風險。如果沒有達到預定日期，團隊會承受巨大壓力和責難；但如果提前完成，卻沒有相應的獎勵。這種風險分配對團隊士氣造成了負面影響

面對這種情況，Kent 會反問：「誰想知道這個答案？這個答案將會影響什麼決策？」他認為，理解問題背後的真實意圖，比提供一個不準確的數字更為重要

影片中提到了一個有趣的現象：「N 個人對於估算有至少 N+1 種理解方式」。這種理解上的分歧是造成估算問題的根本原因之一

Kent 引用了《每個程式設計師都應該知道的 97 件事》一書中 Giovanni Asperoni 的觀點，強調我們需要區分三種不同的情況

當有人告訴你「這個功能必須在聖誕節前完成」，這是一個目標。在這種情況下，團隊需要根據固定的時間點來調整功能範圍，確保能在期限內交付有價值的成果

當被要求做出承諾時，這會觸發開發人員完全不同的思考模式。承諾意味著責任和問責，需要更仔細的規劃和風險評估

如果只是想了解可能的耗時，這應該被視為一個機率分佈問題。軟體開發的時間分佈往往不是對稱的，更可能出現「長尾效應」——延遲的可能時間範圍遠大於提前完成的時間範圍

為什麼軟體估算如此困難？Kent 指出了幾個關鍵原因

許多軟體專案涉及開發前所未有的功能。我們無法根據過往經驗來預測全新功能的開發時間，因為根本沒有可參考的歷史資料

這是軟體開發特有的現象：當你越接近完成時，你反而發現專案的真實規模變得更大。就像觀察海岸線一樣，放大觀察的倍率越高，測量到的長度就越長

Kent 提到了一個典型的例子：某公司報告某個任務完成了 52.5%。這種精確到小數點的數字給人一種精確的錯覺，但實際上只是「虛假的精確性」。在充滿不確定性的軟體開發中，這樣的數字毫無意義

軟體專案的「完成」定義本身就在不斷變化。客戶需求、技術環境、業務優先級都可能在開發過程中發生改變，這使得任何基於固定範圍的估算都變得不可靠

Kent 和主持人最終得出了一個重要結論：軟體估算確實可以被「修正」，但這並非透過追求更高的數字精確度，而是透過釐清問題的本質

這本質上是一項「建立關係」的工作，需要與提出估算要求的人進行深入的溝通和理解

根據不確定性程度，我們可以將任務分為三類

估算不僅是技術問題，更是溝通問題。我們需要學會

作為一個有多年開發經驗的程式設計師，我深深認同 Kent Beck 的觀點。回想起過去參與 Scrum 開發的經歷，我發現估點數的真正價值並不在於數字本身，而在於團隊成員圍繞 Story (需求) 進行的討論

當團隊坐在一起為某個使用者故事估點時，最有價值的不是最終得出的數字，而是討論過程中

這個過程讓整個團隊對即將開展的工作有了共同的認知，這比任何精確的時間估算都更有價值

軟體開發本質上是一個充滿不確定性的創造性工作。與其追求不可能的精確預測，不如學會更好地管理和溝通這種不確定性

Kent Beck 的見解提醒我們，估算問題的解決之道不在於更好的工具或方法，而在於更深刻的理解和更有效的溝通。當我們停止將估算視為一個純粹的技術問題，而開始將其視為一個關係和溝通的問題時，我們就找到了真正的解決方案

下次當有人問你「這個功能什麼時候能完成」時，記住 Kent Beck 的智慧：先弄清楚他們真正想知道的是什麼，然後再決定如何回答這個問題

如果這篇文章對您有幫助，歡迎透過贊助連結支持我持續撰寫優質內容。您的支持是我前進的動力！

圖片來源：AI 產生