《人月神話》第2章：人月神話

美酒的釀造須要年頭，美食的烹調須要時間；片刻等待，更多美味，更多享受。

Good cooking takes time, if you are made to wait, it is to serve you better, and to please you...

在衆從軟件項目中，缺少合理的進度安排是形成項目滯後的最主要緣由，它比其餘全部因素加起來的影響還要大。致使這種災難如此廣泛的緣由是什麼呢？

一、樂觀主義。咱們對估算技術缺少有效的研究，但都基於不真實的假設 - 一切都將動做良好。

二、人月互換。估算時隱含地假設人和月能夠互換，錯誤地將進度與工做量相互混淆。

三、因爲對本身的估算缺少信心，沒有耐心持續地進行估算並不斷更新，調整

四、對進度缺乏跟蹤和監督。

五、重複產生的進度災難。當意識到進度偏離時，下意識的反應是增長人力，但只是火上澆油，讓事情更糟。

樂觀主義

進度安排背後的第一個錯誤假設是：一切都將運做良好，每一項任務僅花費它所「應該」花費的時間。

《創造者的思想》一書中將創造性活動分爲三個階段：構思、實現和交流。對於創造者，只有在實現的過程當中，才能發現咱們構思的不完整性和不一致性。所以總會發現bug。

單個任務中，「一切都將運轉正常」的假設在進度上具備可實現性。

然而大型的編程工做，或多或少包含了不少任務，某些任務間還具備先後的次序，從而一切正常的機率變得很是小，甚至接近於零。

事實上，我發現不少的項目，在項目管理中都沒有識別出關鍵路徑，這樣的進度計劃很難說是合理的。

人月

第二個謬誤的思考方式是在估計和進度安排中使用的工做量單位：人月。它暗示着人員數量和時間是能夠相互替換的。

成本隨人數和時間呈線性變化，但進度卻並不是如此。

當任務因爲次序上的限制不能分解時，人手的添加對進度沒有任何幫助。遺憾的是，不少軟件開發工做都具備這種特徵。即使工做可分解，也會增長相互溝通的工做量：培訓和相互的交流。

系統測試

在進度安排中，順序限制所形成的影響，沒有哪一個部分比單元調試和系統測試所受到的牽涉更完全。系統測試進度的安排經常是軟件項目中最不合理的部分，這也每每是由於開發人員的盲目自信和樂觀主義。

軟件任務的進度安排，經驗法則：

• 1/3 計劃

• 1/6 編碼

• 1/4 構件測試和早期系統測試

• 1/4 系統測試，全部的構件已完成

爲調試和測試，分配了一半的時間。由於延遲發生在項目快完成的時候，直到接近項目的發佈日期，纔有人發現進度上的問題。所以，壞消息沒有任何預兆，很晚纔出如今客戶和項目經理面前。更嚴重的是，項目後期的進度延誤，成本很是高昂。

空泛的估算

爲了知足顧客指望的日期而形成的不合理進度安排，在軟件領域中比其餘任何工程領域要廣泛得多。

重複產生的進度災難

當一個軟件項目落後於進度時，一般的作法是什麼呢？天然是加派人手。

向進度落後的項目中增長人手，只會使進度更加落後。這也是前面講到的「人月」不能簡單互換，增長了人手，須要考慮培訓的時間，任務從新劃分和額外的系統測試。

更重要的是，項目落後的真正緣由是什麼？若是是由於估算過於樂觀，那還未完成的任務一樣也太樂觀估計。如僅僅按當前節點來評估未來的人力，並非聰明的作法。

項目的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量。