每個開發(fā)者在沖刺規(guī)劃會上都心知肚明，卻沒人說出口：

用小時估算，結(jié)果永遠偏低。

資深工程師估低，是想顯得高效。新人估低，是不想顯得慢。整個團隊估低，是因為產(chǎn)品經(jīng)理就在會議室里。然后沖刺結(jié)束，一半工單延期，所有人假裝驚訝。

多年觀察不同團隊、語言和技術(shù)棧之后，我越來越確信：問題不是我們不擅長估算小時數(shù)，而是"小時"本身就是錯誤的單位。

我現(xiàn)在改用復(fù)雜度估算。它帶來更好的軟件、更好的團隊——意外的是，還有更靠譜的截止日期。

大多數(shù)團隊掉進同一個陷阱：把復(fù)雜度和時間當成同一回事，只是換了把尺子量。它們不是。這是兩個獨立的維度。

想想翻譯。把一段英文譯成西班牙語，很簡單，幾乎沒復(fù)雜度。但翻譯整本圣經(jīng)呢？依然簡單——每句話的認知負荷沒變，只是篇幅長。簡單不等于快。

反過來。復(fù)雜的分布式系統(tǒng)遷移，聽起來該花幾周。但如果你的平臺恰好有現(xiàn)成的工具，可能一個下午就搞定。復(fù)雜不等于慢。

一旦內(nèi)化這一點，基于小時的估算游戲就開始顯得荒謬。你在把兩個維度壓成一個，還假裝結(jié)果有意義。

我待過的團隊最終采用類斐波那契數(shù)列：3、5、8、13。超過13不算估算，而是信號——任務(wù)該拆分了。

數(shù)字本身不重要。重要的是它們代表什么：

你可以疊加不確定性、耦合度、影響范圍、依賴關(guān)系、團隊熟悉度等維度。但目標不是建立精確的量表，而是給團隊一套共享詞匯，用來討論"這事有多難"，獨立于"要花多久"。

關(guān)于故事點數(shù)，沒人告訴你的真相是：它們比小時更好，不是因為更準確。說實話，絕對精度上可能更差。

它們更好，是因為改變了對話方式。

問"這事要花多久？"，對話是個人化的、防御性的。最懂的人拋出一個數(shù)字，其他人點頭。真正干活的新人默默恐慌——他們知道做不到，但反駁等于承認自己慢。

問"這事有多復(fù)雜？"，對話是集體性的。為什么這是5不是3？有哪些模塊？哪里可能出錯？新人看著資深工程師推理問題，邊學邊做。資深工程師偶爾會發(fā)現(xiàn)，自己說的" trivial "其實并不 trivial。團隊在動手之前，先理解了要做什么。