為什麼軟體工程師無法估算時間
source : https://medium.com/swlh/why-engineers-cannot-estimate-time-5639750df419 written by Hesham Meneisi
一種統計方法來解釋工程項目中的不良期限
無論您是具有20年經驗的初級，高級，項目經理還是高級經理，軟件項目時間的估算都不容易。無論他們是多麼有經驗或有天才，都無法聲稱自己確定某個軟件項目將花費多少確切時間。
這個問題在軟件工程中尤其普遍，但是其他工程學科也遭受同樣的失敗。因此，儘管本文著重於軟件工程，但在一定程度上它也適用於其他學科。
總覽
首先，讓我們對問題，後果和潛在的根本原因進行鳥瞰。在本系列文章中，我將介紹其中的大多數內容。
問題
軟件項目很少能按時完成。
後果
營銷工作可能會浪費，客戶可能會不滿意，開發人員可能會寫出質量低下的代碼來滿足截止日期並損害產品可靠性，最終，項目可能會被徹底取消。
已知原因
- 錯誤的時間估計（本文重點）。
- 在項目開始時需求不明確，後來又更改了需求。
- 鍍金：在工作範圍之外過分關注細節。
- 在研究和架構設計階段沒有花費足夠的時間，或者相反，花費了太多的時間。
- 忽略第三方集成的潛在問題。
- 渴望“在第一時間做到正確”
- 同時處理太多項目或分散注意力（過於頻繁地中斷流程）。
- 質量吞吐量規模不平衡。
過度樂觀，鄧寧·克魯格效應，純粹的不確定性還是數學？
很容易將過度樂觀的概念統統排除在外，因為通常的理解是，在設定截止日期之前，任何努力滿足截止日期的開發人員都不會感到樂觀。現在，如果項目管理不是來自工程學背景，並且他們在不知道自己在做什麼的情況下設定了截止日期，那麼這將是另一個完全不同的問題，不在本文討論範圍之內。
有些人還把不良的時間估計歸因於鄧寧-克魯格效應，但是，如果對時間估計不足而缺乏經驗或高估自己的能力，那麼肯定會有更多的經驗來緩解這個問題，對嗎？擁有幾乎無限資源的最大公司仍然缺少截止日期的比率非常高，因此這一假設被揭穿了。更不用說，我們所有人都經歷過這一點。在估算時間方面，更多的經驗幾乎無濟於事。
大多數開發人員，尤其是經驗豐富的開發人員，很快得出結論，這僅僅是純粹的不確定性。因此，時間估算永遠是錯誤的，這只是生活中的事實，而我們唯一能做的就是努力滿足客戶需求，並告訴開發人員在出現問題時要“緊縮”。我們都熟悉這種哲學帶來的壓力，垃圾代碼和絕對混亂。
瘋狂有辦法嗎？這真的是我們完成工作的最好方法嗎？好吧，我不這麼認為，這就是我踏上尋找合理的數學解釋的旅程的原因，這些解釋為何所有這些聰明的人都無法估計他們花時間去做某事。
這只是數學！
有一天，我正在完成一項本應花費10分鐘，而最終花費2個小時的任務。我開始考慮為什麼我會花10分鐘的時間，而根本原因卻導致該數字持續增加到2小時。我的思考過程有點有趣：
- 我認為這將花費10分鐘，因為我實際上100％知道我需要編寫的確切代碼。
- 實際上，我花了大約7-10分鐘的時間來完成代碼。然後花了2個小時，因為我完全不了解框架中的錯誤。
人們喜歡在項目管理中稱其為“不可抗力”。外部無法控制的延遲原因。
現在您可能會認為我只是在證明這種情況下的不確定性。好吧，是的，不是。讓我們縮小一點。當然，不確定性是延遲執行此特定任務的根本原因，因為我永遠都不會猜到該錯誤的存在。但是，是否應該為整個項目的延遲負責？
那就是我們需要區分一個任務不能代表該項目，反之亦然的地方。
我們如何“正常”估算時間
正態分佈在我們周圍，人腦已經習慣了它們。我們是根據天性正態分佈來估計事物的專家；這是通過曝光獲得經驗的基礎。
如果本月您去最近的7–11點近20次，每次都花了5分鐘，那一次，電梯需要維護，您不得不等待10分鐘，也許其他時候您決定等待幾對分鐘，直到停止下雨。您現在到那裡要花費多少時間，您的猜測是什麼？ 5分鐘？
我的意思是說15個是沒有意義的，因為這是罕見的事件，而除非外面下雨是7個。而且您很可能是對的。如果20分之18的時間花了5分鐘，那麼這次很有可能只花5分鐘（中值），大約有90％的機會（當然，沒有涉及到更複雜的代數）。
歪斜了！
即使您真的很擅長估算任務所需的時間，也不意味著您就會擅長估算項目所需的時間！從直覺上反駁，你會犯更多錯誤。
現在，所有現在讀書的數學書呆子（或數據科學家/統計學家）必須已經認識到前一個模因中的那個小圖是右偏正態分佈。讓我放大並澄清一下：
看到這裡怎麼會出錯嗎？ 我們的“自然”猜測基於中位數，該中位數使我們正確猜測的可能性最大化，但是，當“事件”發生足夠次數時，真實數字將始終接近均值。 換句話說：您執行的任務越相似，錯誤累積的內容就越多！
一個項目上的編程任務通常非常相似，或者至少分為幾個相似的集群！此等式還意味著該問題是可擴展的！儘管我們希望軟件項目中的所有內容都具有可伸縮性，但是肯定不歡迎出現問題。
那麼，如何利用這些知識呢？
老實說，在撰寫本文時，我並不打算基於此假設給出任何“指示”。這只是一種探索性分析，其中包含一個假設，由讀者決定，讀者可以根據自己的意願進行解釋。
但是，我確實知道，很多人會對這個開放性結論感到失望，所以我個人對此是這樣。
- 與確切說出要花多長時間相比，說出任務X是否要花更多/更少/相同的時間要容易得多。這是因為如果曲線的偏斜度大致相同，則比較中位數的效果與比較均值的效果一樣（對於類似的任務也是如此）。
- 我不會回憶或記錄每一個類似的任務來進行數學運算並獲得平均值（並且找不到任何折磨的數據）。因此，我通常根據在開發環境中的舒適度來估算不可避免的錯誤（中位數）佔任務時間的百分比（取決於我對開發環境的適應程度（我喜歡這種語言/框架嗎？（40％））是否具有良好的調試工具（佔30％）和對IDE的良好支持（佔25％）……等等）。
- 我開始將sprint分成大小相等的任務，只是為了在時間估計過程中創建一些統一性。這使我受益於第1點，應該很容易判斷兩個任務在時間上是否大致相等。這也使任務更加相似，從而使假設更完美地適用，並且事情變得更加可預測。
- 遵循這些原則，如果您有足夠的資源，則可以進行“測試運行”。例如，如果在X1天內與Y1開發人員完成了統一任務的Z1，那麼只要我們知道Y2（可用開發人員）和Z2（剩餘任務總數），就可以輕鬆解決X2（天）。
最後，如果您不想錯過即將發表的有關其他原因造成延誤的文章，請務必遵循。
