《人月神話》讀書筆記 md

class

這是一篇來自《人月神話》的讀書筆記，源自研一「軟體工程管理」一課的作業。

筆記的格式將先按章節的閱讀順序做一些摘記，最後用一部分文字進行通讀的總結。閱讀版本為清華大學出版社的40周年中文紀念版，布魯克斯作，汪穎翻譯

從程式設計的例子介紹了，程式設計之所以能讓人體會樂趣是源自建立事物的活動。但是諸如在自我創造（程式設計）中體會的快感是受到了許多限制的，如程式設計規範與模式，業務的需求、資源的供給**於他人，需要與不同的個體進行合作協商。也就是說，這種過程沒有本身的絕對權威。但是這些過程是都是客觀需要的。另一方面，可能還存在一些除錯與勞動付出的矛盾與苦惱等。

於是，本書將程式設計比作焦油坑

引入談到：在眾多軟體專案中，缺乏合理的進度安排是造成專案滯後的最主要原因，比其他所有因素加起來的影響還要大。列舉了如「錯誤將進度與工作量混淆」、「對自己的估算缺乏信心」、「缺乏對估計技術有效的研究」、「缺少進度跟蹤和監督」等理由。如下幾點，後附我的某些理解：

更年輕的計算機技術、更年輕的程式設計師，通常都是樂觀主義者。帶來第乙個錯誤假設——一切都會運作良好，每項分工僅僅花費理想的時間。

我們在進行程式設計等創造性活動時，其實往往會遇到一些實際問題，這些不曾預料或突發的情況是無法避免的，過於主觀的估計和判斷造成的樂觀思維是存在缺陷的。

人月——乙個錯誤的思考方式，在估計和進度安排中使用的工作量單位。成本隨開發的人數和時間是動態的，但是制定的進度卻不是如此。就是說人月——人員數量和時間相互替換。

也就是說，通過增加人手的方式來換取時間上的效率，不一定可行。有一些不可分解的任務可能根本無法起作用，另一些可能需要增加額外的時間、精力等成本去了解新的工作內容。

系統測試的進度安排往往不太合理，這個階段其實牽扯到所有子單元，遭遇的bug、錯誤往往難以估計，與樂觀主義所做的假設是有區別的。

這裡作者給出了乙個可能的經驗開發進度安排，1/3的時間給了計畫、1/6用於編碼，剩餘的1/2分成構件測試和系統測試的兩部分。其實，這個標準確實在理論上是合理的，但是許多的專案都不可能將專案的一般時間push到測試上，最後往往進度就在測試這裡delay了。我在實習期間經常遇上這種事。文章還說到，一旦進度delay，造成的損失和面臨的問題將會更多

專案經理或管理人員，在進行專案的緊急與重要程度的估計中沒有標準化的說明，一般都是經驗導向的。

重複產生的進度災難——在專案進度delay後，過於自然地加派人手，導致了代價分析的錯誤度量。將會導致進度進一步delay？

作者的觀點：需要協作溝通的人員數量影響著開發成本，因為成本的主要組成部分是相互溝通和交流，以及更正溝通不當所引起的不良結果。系統盡可能由少數人參與開發。另一方面，效率高的小而精團隊與一擁而上的大團隊在開發上是存在乙個選擇的。書中談到了乙個開發團隊的建設的建議。

這種團隊是與傳統隊伍建設不太一樣，不同人員之前角色不平等而是有差異的。個體間不存在利益間的建設。可能可以達到客觀的一致性。同時它也是一種專業化的分工。

這個結構在系統的構建上保留了完整性——有乙個系統結構師自頂向下的進行了所有的設計。系統結構師必須清楚地劃分體系結構和現實之間的界線，必須一絲不苟地專注於體系結構的建設。

小結： 這一章中主要是講到了乙個開發團隊的結構設計，從乙個系統結構師的角度去考慮，如何能夠給出一種可靠的隊伍建設的建議，並且給出了不通過角色的解釋。其實，這種隊伍的建設是我之前所沒有了解到的，可能我們之前大部分了解到的都是具體到專案的實現中，每個人負責乙個模組，各個模組是相互耦合和關聯的，在專案進行的過程中不會有人全程參與所有的系統設計。但是，在實際的專案開發中，許多人脫離了系統的本身，而專注於自身的任務，沒有了其他職責或背景的支援，可能在溝通和聯調中產生問題。

（續）但是，若對於乙個大型系統的開發而言，這樣的模式是否真的實用。隊伍擴充後，對不同的任務或職責所司專業人員的把控也不見得就有這麼契合吧？ 比如各類技術人員開發效率的差異與分化後的職責分配問題，會不會在系統級聯調的時候出現一些其他的問題？這是我的乙個小的疑問。

作者主張概念完整性是系統設計中最重要的考慮因素，從教堂建造的例子引入，提到了在系列連貫的設計思路中，可以省略一些不規則的特性與改進，哪怕對於一些很好的設計概念。

簡潔和直白來自概念的完整性。概念的完整性須由乙個人或非常少數的人來實現。這一點與進度壓力需要很多人員參與相矛盾，解決矛盾的方法可能是有限的。概念結構的完整性可能反映的是唯一的設計理念，但是經驗卻表示該開發模式下系統需要的開發會變得更加高效。

面對體系結構上的設計，結構師在第一次系統搞設計的時候，應該是盡早與需求商商議的、並且需要其持續的溝通，來保證系統的開發任務。在這個過程中如果出現未能預見的問題，一般的建議不是尋求體系結構的更變，因為這會導致和開發人員的矛盾和導致不必要的開發成本。

談到二次系統建設時，因為系統技術和功能的特殊性變化，系統結構師們應當有意識地關注，避免對於開發中功能上的過於裝飾和技術細化，還是依賴原始的系統設計理念，在確保原則的基礎上盡可能地保持完整性的開發過程。

從上兩章提出的概念完整性的保障：給出了一些可行的實施方案。包括了如何從文件化及手冊管理、形式化規則與定義、舉行會議和大會為保障、提供多重實現，並且在**日誌和產品測試方面進行記錄與監督。以上幾個方面，分別從不同的角度對系統設計開發中面臨的不同問題進行了可行性的建議，並分析了其效果與效率，一種可能的解釋是，在這些方向能夠貫徹實際落實的話，某乙個系統的概念的完整性是能夠實現的。這樣使得為系統更好地實現帶來了更多的概念支援。

巴比倫這個工程無論是在人力、物力和財力上都是具有足夠支援的，其失敗的原因在於缺乏了團隊的交流與合作，各子單位在爭吵中逐漸走向破裂，導致了最終的失敗。模擬到軟體專案的管理中來，這些經驗教訓能夠發揮很大的啟發作用。在大型專案地開發中，使用非正式途徑、會議或者工作手冊，加強同專案中各個人員的交流和合作，能夠有效的保障系統的順利開發。

其中，專案工作手冊是專案的一系列的組織結構與規範，涵蓋了所有的文件、說明、使用者手冊等內容。使用專案手冊不僅能夠保障專案文件本身的結構，還可以控制資訊發布的準則。專案手冊還提供了一種處理問題機制的方式方法。另一方面，專案的組織結構，需要從人員、任務、責任幾個方面出發，在進行人力劃分與職責分配時，要考慮相互溝通交流的因素。組織和交流，是需要管理者同軟體技術一樣重要的考慮點。

系統的程式設計程序及工作量的估計是需要有乙個合理且動態的調整郭晨的，專案的進展或工作量不僅僅是包含了編碼，還應該將開發人員的協調、溝通和交流都考慮進來，進行合理、實際的綜合評估，從而完成對專案的整體把握和控制。

書中另外在此章篇幅中給出了一些關於程式設計人員生產率研究的資料分析，來充分說明生產效率的矛盾性。

談到程式空間本身，也是作為成本的一部分，包含在程式開發的過程中。我們在開發過程中不僅僅要考慮編碼本身，還要考慮編碼之外甚至硬體的成本。所以，需要對專案規模進行乙個可細化的設定與分配，避免浪費了不必要的規模空間。

對專案經理而言，需要通過研究使用者及其需求，進行開發系統的規模控制，這是管理工作層面的。規模設定需要同其他工作進行動態的控制，需要對專案本身進行深入了解後進行一些技巧性的配置。作者通過os/360的例項，講到了規模的設定應該是從所有方面進行預算編入的而不僅是核心程式設計。另一方面，在設立單元核心模組的同時，應該對其設定訪問預算，專案分解成子模組本身也需要耗費一定的規模設計成本。

專案工作中，會存在許多文案，也就是技術之外的許多管理性的工作。在進行專案文件的管理開展中，需要注意一些關鍵點：

《人月神話》讀書筆記

p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...

人月神話讀書筆記

人數和時間的互換僅僅適用於以下情況 某個任務可以分解給參與人員，並且他們之間不需要相互的交流。當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。溝通所增加的負擔由兩個部分組成，培訓和相互的交流。相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照n n 1...

《人月神話》讀書筆記

外科手術隊伍 對於軟體開發來說，軟體開發隊伍的選擇往往是乙個難題。在我們的時間課程的當中，每個人都希望可以抱大牛的大腿，因為乙個熟練且經驗豐富的大牛可以抵得上十個新手，如果乙個小隊當中都是如此的大牛，那麼這個小隊可以稱之為當之無愧的精英小隊。對於大型的專案，小而美的團隊往往有些力不從心，精英也不可能...