人月神話(huà)讀書(shū)筆記
人月神話(huà)這本書(shū)幾年前就聽(tīng)別人說(shuō)是本很經(jīng)典的軟件開(kāi)發(fā)方面的書(shū)，這本書(shū)的成功之處在于他思想的前衛性，以至于不只是軟件行業(yè)的人在讀�！ 倪@本書(shū)的內容來(lái)看，對于一個(gè)項目經(jīng)理來(lái)說(shuō)肯定會(huì )有更大的收獲，這本書(shū)主要是針對軟件開(kāi)發(fā)管理方面的內容，這主要原因可能是因為作者以前就是項目的管理者，他是站在管理者的角度寫(xiě)的。即便這樣，對于一個(gè)從來(lái)沒(méi)有參與過(guò)真實(shí)項目開(kāi)發(fā)，更沒(méi)有領(lǐng)導過(guò)團隊的我還是有一定的吸引力，這本書(shū)中我最喜歡的就是前四章(焦油坑、人月神話(huà)、外科手術(shù)隊伍、貴族專(zhuān)制、民主政治和系統設計)和沒(méi)有銀彈這章。這本書(shū)里面為了論證某一觀(guān)點(diǎn)，會(huì )舉出許多實(shí)際的項目作為證據，這一點(diǎn)非常好，事實(shí)勝于雄辯嘛!這些例子也許對于作者那個(gè)年代的人來(lái)說(shuō)很好理解，但是放在30年后來(lái)看這些例子又有些陳舊和難懂了。另外，從文中我發(fā)現作者非常注重文檔，一個(gè)優(yōu)質(zhì)的文檔就是項目成功的保證，這一點(diǎn)與傳統的軟件工程很相似，但是卻與極限編程的觀(guān)點(diǎn)相悖。下面就是一些讀書(shū)的總結了。
焦油坑 1. 編程系統產(chǎn)品開(kāi)發(fā)的工作量是供個(gè)人使用的、獨立開(kāi)發(fā)的構件程序的九倍。
2. 編程行業(yè)的一些內在固有苦惱：
l 將做事方式調整到追求完美，是學(xué)習編程的最困難部分。
l 由其他人來(lái)設定目標，并且必須依靠自己無(wú)法控制的事物。
l 真正的權威來(lái)自于每次任務(wù)的完成。
l 任何創(chuàng )造性活動(dòng)都伴隨著(zhù)枯燥艱苦的勞動(dòng)，編程也不例外
l 人們通常期望項目在接近結束時(shí)(bug、工作時(shí)間)能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢。
l 產(chǎn)品在即將完成時(shí)總面臨著(zhù)陳舊過(guò)時(shí)的威脅。 人月神話(huà) 1. 缺乏合理的時(shí)間進(jìn)度是造成項目滯后的最主要原因，它比其他所有因素加起來(lái)影響還大。
2. 良好的烹飪需要時(shí)間，某些任務(wù)無(wú)法在不損害結果的情況下加快速度。
3. 我們的構思是有缺陷的，因此總會(huì )有bug。
4. 我們圍繞成本核算的估計技術(shù)，混淆了工作量和項目進(jìn)展。人月是危險和帶有欺騙性的神話(huà)，因為它暗示人員數量和時(shí)間是可以相互替換的。
5. 在若干人員中分解任務(wù)會(huì )引發(fā)額外的溝通工作量--培訓和相互溝通。
6. 關(guān)于進(jìn)度安排，作者的經(jīng)驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。
7. 因為我們對自己的估計技術(shù)不確定，所以在管理和客戶(hù)的壓力下，我們常常缺乏堅持的勇氣。
8. brook法則：向進(jìn)度落后的項目中增加人手，只會(huì )使進(jìn)度更加落后。
9. 向軟件項目中增派人手從三個(gè)方面增加了項目必要的總體工作量：任務(wù)重新分配本身和所造成的工作中斷;培訓新人員;額外的相互溝通。 外科手術(shù)隊伍 1. 同樣有兩年經(jīng)驗而且在受到同樣的培訓的情況下，優(yōu)秀的專(zhuān)業(yè)程序員的.工作效率是較差程序員的十倍。關(guān)于這一條我在極限編程里看到，sackman和humphrey分別做了實(shí)驗發(fā)現優(yōu)秀程序員工作效率比較差程序員的工作效率最高要高達28倍。
2. 小型、精干隊伍是最好的。這一點(diǎn)在軟件工藝和極限編程里都得到了充分的體現。
3. 兩個(gè)人的團隊，其中一個(gè)項目經(jīng)理，常常是最佳的人員使用方法。
4. 對于真正意義上的大型系統，小型精干的隊伍太慢了。
5. 實(shí)際上，絕大多數大型編程系統的經(jīng)驗顯示出，一擁而上的開(kāi)發(fā)方法是高成本、速度緩慢、不充分的，開(kāi)發(fā)出的產(chǎn)品無(wú)法進(jìn)行概念上的集成。
6. 一位首席程序員、類(lèi)似于外科手術(shù)隊伍的團隊架構提供了一種方法，既能獲得由少數頭腦產(chǎn)生的產(chǎn)品完整性，又能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量。圖1是10人的程序開(kāi)發(fā)隊伍溝通模式。 圖1 10人程序開(kāi)發(fā)隊伍溝通模式
貴族專(zhuān)制、民主政治和系統設計 1. 概念完整性是系統設計中最重要的考慮因素。
2. 為了獲得概念完整性，設計必須由一個(gè)人或者具有共識的小型團隊來(lái)完成。
3. 對于非常大型的項目，將設計方法、體系結構方面的工作與具體實(shí)現相分離是獲得概念完整性的強有力方法。
4. 紀律、規則對行業(yè)是有益的。外部的體系結構規定實(shí)際上是增強，而不是限制實(shí)現小組的創(chuàng )造性。
5. 體系結構、設計實(shí)現、物理實(shí)現的許多工作可以并發(fā)進(jìn)行。 畫(huà)蛇添足 1. 盡早交流和持續溝通能使結構師有較好的成本意識，以及使開(kāi)發(fā)人員獲得對設計的信心，并且不會(huì )混淆各自的責任分工。
2. 結構師如何成功地影響實(shí)現：
i. 牢記是開(kāi)發(fā)人員承擔創(chuàng )造性的實(shí)現責任;結構師只能提出建議。
ii. 聽(tīng)取開(kāi)發(fā)人員在體系結構上改進(jìn)的建議。
3. 第二個(gè)系統是人們所設計的最危險的系統，通常的傾向是過(guò)分地進(jìn)行設計。關(guān)于這一點(diǎn)也許是正確的，但是這是一個(gè)回避不了的問(wèn)題，如果沒(méi)有開(kāi)發(fā)第二個(gè)系統經(jīng)驗的人，就不可能有開(kāi)發(fā)第三個(gè)系統經(jīng)驗的人了。 貫徹執行 1. 即使是大型的設計團隊，設計結果也必須由一個(gè)或兩個(gè)人來(lái)完成，以確保這些決定是一致的。
2. 必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說(shuō)明一致。
3. 出于精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來(lái)加深理解。
4. 允許體系結構師對實(shí)現人員的詢(xún)問(wèn)做出電話(huà)應答解釋是非常重要的，并且必須進(jìn)行日志記錄和整理發(fā)布。
5. 項目經(jīng)理最好的朋友就是他每天要面對的敵人--獨立的產(chǎn)品測試機構/小組。 為什么巴比倫塔會(huì )失敗? 1. 巴比倫塔項目的失敗是因為缺乏交流，以及交流的結果的組織。
2. 因為左手不知道右手在做什么，從而進(jìn)度災難、功能的不合理和系統缺陷紛紛出現。由于對其他人的各種假設，團隊成員之間的理解開(kāi)始出現偏差。
3. 團隊應該以盡可能多的方式進(jìn)行相互之間的交流：非正式、常規項目會(huì )議，會(huì )上進(jìn)行簡(jiǎn)要的技術(shù)陳述、共享的正式項目工作手冊。 胸有成竹 1. 僅僅通過(guò)對編碼部分的估計，然后乘以任務(wù)其他部分的相對系數，是無(wú)法得出對整項工作的精確估計的。
2. 構建獨立小型程序的數據不適用于編程系統項目。
3. 程序開(kāi)發(fā)與程序規模成指數增長(cháng)趨勢。
4. 當使用適當的高級語(yǔ)言時(shí)，程序編制的生產(chǎn)率可以提高5倍。 削足適履
這一章主要是要解決項目投資與磁盤(pán)空間和內存之間的矛盾，但是這個(gè)矛盾在電腦硬件發(fā)展到現在的層次已經(jīng)可以忽略掉了。
提綱挈領(lǐng) 1. 軟件項目的要求：目標、用戶(hù)手冊、內部文檔、進(jìn)度、預算、組織機構圖和工作空間分配。
2. 即使是小型項目，項目經(jīng)理也應該在項目早期規范化上述的一系列文檔。 這一章強調文檔重要性，但并沒(méi)有將一些教條主義的道理讓你相信文檔的重要性，而是給項目經(jīng)理給出了實(shí)實(shí)在在的操作步驟。
未雨綢繆 1. 對于大多數項目，第一個(gè)開(kāi)發(fā)的系統并不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。系統的丟棄和重新設計可以一步完成，也可以一塊塊地實(shí)現。這是個(gè)必須完成的步驟，如果將開(kāi)發(fā)的第一個(gè)系統丟棄原型發(fā)布給用戶(hù)，可以獲得時(shí)間，但是它的代價(jià)很高。對于用戶(hù)，使用極度痛苦;對于重新開(kāi)發(fā)的人員，分散了精力;對于產(chǎn)品，影響了聲譽(yù)，即使最好的再設計也難以挽回名聲。
2. 用戶(hù)的實(shí)際需要和用戶(hù)感覺(jué)會(huì )隨著(zhù)程序的構建、測試和使用而變化。
3. 軟件產(chǎn)品易于掌握的特性和不可見(jiàn)性，導致了它的構建人員面臨著(zhù)永恒的需求變更。
4. 目標和開(kāi)發(fā)策略上的一些正常變化無(wú)可避免，事先為它們做準備總比假設它們不會(huì )出現要好得多。
5. 對于一個(gè)廣泛使用的程序，其維護總成本通常是開(kāi)發(fā)成本的40%或更多。
6. 維護成本受用戶(hù)數目的嚴重影響。用戶(hù)越多，所發(fā)現的錯誤也越多。
7. campbell指出了一個(gè)顯示產(chǎn)品生命期中每月bug數的有趣曲線(xiàn)，它先是下降，然后攀升。
8. 缺陷修復總會(huì )以(20-50)%的機率引入新的bug。
9. 在每次修復之后，必須重新運行先前所有的測試用例，從而確保系統不會(huì )以更隱蔽的方式被破壞。
10. 同樣，設計實(shí)現的人員越少、接口越少，產(chǎn)生的錯誤也就越少。
11. 所有修改都傾向于破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統退化到不可修復混亂的進(jìn)程。 干將莫邪
項目經(jīng)理應該制訂一套策略，以及為通用工具的開(kāi)發(fā)分配資源，與此同時(shí)，他還必須意識到專(zhuān)業(yè)工具的需求。
禍起蕭墻 1. 一天一天的進(jìn)度落后比起重大災難，更難以識別，更不容易防范和更加難以彌補。
2. 根據一個(gè)嚴格的進(jìn)度表來(lái)控制項目的第一個(gè)步驟是制訂進(jìn)度表，進(jìn)度表由里程碑和日期組成。
3. 里程碑必須是具體的、特定的、可度量的事件，能進(jìn)行清晰能定義。
4. 如果里程碑定義得非常明確，以致于無(wú)法自欺欺人時(shí)，程序員很少會(huì )就里程碑的進(jìn)展弄虛作假。 另外一面 1. 對于軟件編程產(chǎn)品來(lái)說(shuō)，程序向用戶(hù)所呈現的面貌與提供給機器識別的內容同樣重要。
2. 即使對于完全開(kāi)發(fā)給自己使用的程序，描述性文字也是必須的，因為它們會(huì )被用戶(hù)和作者所遺忘。
3. 文檔能在整個(gè)軟件開(kāi)發(fā)的生命周期對程序員克服懶惰和進(jìn)度的壓力起促進(jìn)激勵作用，但向編程人員成功地灌輸對待文檔的積極態(tài)度是一件困難的事情。
4. 為了使文檔易于維護，將它們合并至源程序是至關(guān)重要的，而不是作為獨立文檔進(jìn)行保存。 沒(méi)有銀彈
人狼的傳說(shuō)可能有人聽(tīng)過(guò)也可能沒(méi)聽(tīng)過(guò)，人狼是一種具有人和狼兩種特征的恐怖生物，而銀彈是消滅它的一種最有效的子彈，如果看過(guò)《吸血鬼傳說(shuō)》也許就能和容易的理解這一點(diǎn)。作者將軟件開(kāi)發(fā)比作人狼，而將提高軟件開(kāi)發(fā)效率的方法比作銀彈。作者預言未來(lái)十年，想要試圖通過(guò)尋找一種有效地銀彈將軟件開(kāi)發(fā)效率提高一個(gè)甚至幾個(gè)數量級，這種銀彈不可能出現。
沒(méi)有銀彈這篇文章里作者列舉出了當時(shí)一些非常先進(jìn)的技術(shù)或思想理念，例如ada和其他高級編程語(yǔ)言、面向對象編程、人工智能、專(zhuān)家系統、"自動(dòng)"編程、圖形化編程、程序驗證、環(huán)境和工具、工作站等。雖然這些先進(jìn)技術(shù)在一定程度上提高了軟件開(kāi)發(fā)的效率，但是始終沒(méi)有達到銀彈的效果。距離作者的預言已經(jīng)過(guò)去有20多年了，縱觀(guān)現在的軟件開(kāi)發(fā)領(lǐng)域，雖然新技術(shù)層出不窮，但是還是沒(méi)有一種銀彈能夠讓軟件開(kāi)發(fā)產(chǎn)生一次革命。
更多相關(guān)
【人月神話(huà)讀書(shū)筆記】相關(guān)文章：
《光環(huán)效應——背離真相的商業(yè)神話(huà)》萬(wàn)字讀書(shū)筆記09-14
招聘個(gè)人月度總結01-06
古代神話(huà)勵志故事08-24
神話(huà)經(jīng)典臺詞12-03
《幸福的神話(huà)》推薦08-28
中國神話(huà)學(xué)重構之作—《中國神話(huà)學(xué)文論選萃》簡(jiǎn)評08-08
店長(cháng)個(gè)人月工作總結01-15
個(gè)人月工作計劃范文10-27
個(gè)人月工作總結模板12-24
招聘個(gè)人月度總結6篇01-06