人月神話(一二章)摘要筆記

 

"人月神話"的字面意思就是

人是程序員，月是時間，若是一我的幹10個月等同10我的幹一個月，那就成神話。

 

Chapter_1 The Tar Pit（焦油坑）

對焦油坑的解釋

「過去幾十年的大型系統開發就如同一個焦油坑，不少大型和強壯的動物在其中劇烈地掙扎。他們中大多數開發出了可運行的系統--不過只有極少數的項目知足了目標、進度和預算的要求。各類團隊，大型的或小型的，龐雜的或精幹的，一個接一個地淹沒在了焦油坑中，表面上看起來好像沒有任何一個單獨的問題會致使困難，每一個問題都能得到解決，可是當它們互相糾纏和累積在一塊兒的時候，團隊的行動就會變得愈來愈慢。對於問題的麻煩程度，每一個人彷佛都會感到驚訝，而且很難看清問題的本質。不過若是咱們想解決問題，就必須試圖先去了解問題。」

 

編程系統產品的演進

編程系統產品開發的工做量是供我的使用的、獨立開發的構件程序的九倍(橫豎x3)。

 

編程的樂趣

1. 創造的純粹快樂
2. 源於開發出有價值的東西，這種價值體現於對別人有用。
3. 將相互齧合的零部件組裝在一塊兒，以精妙的方式運行着，並收到了預期效果。
4. 持續學習的快樂，源於這項工做的非重複特性。
5. 源於在易於駕馭的介質上工做。

編程行業的一些內在固有苦惱：

1. 將作事方式調整到追求完美的方向，是學習編程的最困難的部分。
2. 由其餘人來設定目標、供給資源和提供信息。，編程人員不多能控制環境和工做目標。(我的權威和他所承擔的責任是不相配的)實際權威來自於每次任務的完成.
3. 對其餘人的依賴，依靠其餘人的程序(每每設計不合理or實現拙劣or發佈不完整[無源碼或測試用例]or文檔記錄很糟糕)，在理想情況下這些程序本應是可靠完整的。
4. 尋找瑣碎bug是一項重複性的活動。調試和差錯每每是線性收斂的。測試一拖再拖，尋找最後一個錯誤比第一個將花費更多的時間。
5. 當產品即將或已經完成的時候，卻已通過時，同事和競爭對手已經在追逐新的、更好的構思了，甚至已經在安排了。

編程挑戰or任務：

在實際的進度和有效的資源範圍內，尋找解決實際問題的切實可行方案。

總結：

編程是一個許多人痛苦掙扎的焦油坑，樂趣遠大於困擾的創造性活動。

 

---

 

Chapter_2人月神話（The Mythical Man-Month）

缺少合理的進度安排是形成項目滯後的最主要緣由。

人月問題的產生

>>>對估算技術缺少有效的研究，反映出一種悄無聲息但並不真實的假設——一切都將運做良好。

>>>咱們採用的估算技術隱含地假設人和月能夠互換，錯誤地將進度與工做量相互混淆。

>>>因爲對本身的估算缺少信心，軟件經理一般不會有耐心持續地估算這項工做。

>>>對進度缺乏跟蹤和監督。

>>>當意識到進度的偏移時，下意識（以及傳統）的反應是增長人力。(這種行爲就像使用汽油滅火)

 

編程中的樂觀主義（Optimism）

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

Dorothy Sayers在她的《創造性的思想（The Mind of the Maker）》一輩子中，將創造性活動分爲三個階段：構思、實現和交流。

計算機編程基於十分容易掌握的介質，編程人員經過很是純粹的思惟活動——概念以及靈活的表現形式來開發程序。

第二個謬誤的思考方式是: 在估計和進度安排中使用的工做量單位：人月。

用人月做爲衡量一項工做的規模是一種危險和帶有欺騙性的神話, 主要是由於如下兩個緣由:  耗費時間的不肯定性和 人員數量與時間的不可互換.

 

人月概念適用的範圍

人月僅適用於：

（1）某個任務能夠分解給參與人員。

（2）而且人員之間不須要相互交流。

而任務因爲在次序上的限制不能分解時,人手的添加對進度沒有幫助,這種狀況就像生小孩這個任務,多參與幾我的也不能讓母親提早把孩子生下來.

溝通所增長的負擔由兩個部分組成：培訓和相互交流。

 

人員和時間之間的關係(從四種狀況考慮)：

(1)徹底能夠分解的任務

(2)沒法分解的任務

(3)須要溝通的可分解任務

(4)關係錯綜複雜的任務

軟件開發本質上是一項系統工做——錯綜複雜關係下的實踐，溝通、交流的工做量很是大，它很快會消耗任務分解所節省下來的我的時間。

系統測試

系統測試須要的時間以來於所遇到的錯誤、缺陷的數量以及其難以捕捉的程度。

系統測試進度的安排經常是編程中最不合理的部分。

經驗法則

對於軟件任務的進度安排，做者的經驗法則是：

• 1/3計劃、
• 1/6編碼、
• 1/4構件測試和早期系統測試、
• 1/4系統測試，全部的構件已經完成

這種安排方法：

（1）分配給計劃的時間比日常的多。

（2）對所完成代碼的調試和測試投入近一半的時間，這比日常的安排多不少。

（3）容易估計的部分：1/6編碼

大多數項目的測試實際上花費了進度中一半的時間，或者來講，除了系統測試，進度基本可以保證。

若是不爲系統測試安排足夠的時間將是一場災難。

系統測試的延遲具備不尋常的、嚴重的財務和心理上的反應，天天的人力成本也已經達到最大限度。更爲嚴重的是在用軟件支持其餘的商業活動（計算機硬件運送、新設備操做等）的狀況下，若在即將發佈時出現延誤，所付出的二次商業代價是很是高昂的。

空乏估算的兩種解決方案(如何讓估算更具說服力)：

（1）開發並推行生產率圖表、缺陷率圖表、估算規則等，而整個組織最終會從這些數據的共享上獲益。

（2）在基於可靠基礎的估算以前，專業人士的經驗和直覺比指望派生出的結果有時更可靠。

 

如何有效地應對重複產生的進度災難

除了加派人手,更爲靠譜的兩個方案:

1. 從新安排進度,避免小的誤差「Take no small slips.」
2. 當項目延期所致使的二次成本很是高時，削減任務成了惟一可行的方法。

加派人手而不調整任務的結果(培訓,任務的從新分配以及系統測試工做量)將是災難性的重複,這種狀況比不加派人手只調整任務進度所產生的產品更差.

Brooks法則

向進度落後的項目中增長人手，只會使進度更加落後。（Adding manpower to a late software project makes it later.）