chapter 2 人月神話
在對於任務分解上，看似越多的人會減少個人工作的時間，實則不然，人員的增多會導致其他方面諸如培訓和交流之間的開銷的增加，導致很快會消耗掉任務分解所節省下來的時間，有時未必會減少時間。不要妄圖以減少時間爲目的進行相關的人員方面的變動，或是項目上的調整，提速是可以的，但是首先不要貪心，其次記住欲速則不達。不是人越多效率越高。樂觀主義 所有的編程人員都是樂觀主義者。… “這次她肯定會運行的” “我剛剛找到了最後一個錯誤” 人月 第二個謬誤是在估計和進度安排中使用的工作單位﹣人月。暗示着時間和人員可以相互替換。
雖然從理論上來說，在系統開發的過程中錯誤的數量的確應該爲0，事實上我們永遠都不可能做到，甚至儘量減少到最低也是很難的，在測試的時候就需要花上更多的時間，雖然未必會找到最後一個bug，但是總比花的時間少要來的好得多…當項目進度落後之後你會怎麼做？作爲項目經理，亞力山大啊…如果增加人手，可能造成的風險會滾雪球一樣增長，通常項目管理會因爲人的因素而增加太多的不確定性，這個是特別難估計的部分，或許這就是爲什麼項目經理也是越老越吃香的原因，可以通過經驗來進行項目初期的預算估計以及項目計劃的制定，但是，當有新的技術手段出現時，使用經驗進行估算顯然是不是用的，那麼有沒有一個優秀的估算模型進行計劃的制定呢？？？系統開發的時間安排 1／3 計劃 1／6 編碼 1／4 構件測試和早期系統測試 1／4 系統測試，所有構件已完成 需要特別指出的是，不爲系統測試安排足夠的時間簡直就是一場災難
簡化Brooks的法則：向進度落後的團隊增加人手，只會讓進度更加落後。
思考，”The Cathdral and the Bazaar”一文中提到的關於開源軟件的管理方式是違背了Brooks法則的，但是仍舊能夠成功，爲什麼？？？？
chapter 3 外科手術隊伍
其實現在的大多數團隊都是採用了這種開發方式進行開發，但是正如作者所提出的問題一樣，如何組建一個大規模的團隊是最重要的事情，並且，如果逐層按照小型隊伍的組建方式進行大型隊伍的建立，那麼在決策階段不可避免會產生衝突，如何解決此種衝突矛盾？如何協調各個小型團隊之間的工作進度以及團隊交流？這些研究表明，效率高和效率低者之間個體差異非常大，經常能夠達到數量級的水平。 Mills的建議 大型項目的每一個部分有一個團隊來解決，但是該隊伍以類似外科手術的方式組建，並非一擁而上 10人程序開發隊伍的溝通模式
chapter 4 貴族專制、民主政治和系統設計
最危險的情況就是設計的過程中程序員覺得無事可做，出於無所事事的狀態，實際上對於硬件和軟件平臺的熟悉以及前期知識的掌握理論上應該放在這個部分進行。此時的狀態應該是設計師大致設計出了系統的雛形以及確定了系統中所涉及到的相關軟件技術和硬件平臺，所以程序員應該可以依據此進行相關信息的搜索和知識的補足，直到完整的設計完成，開始進行編碼。我主張在系統設計概念中，概念完整性應該是最重要的考慮因素。 體系結構同實現必須仔細地區分開來。體系結構陳述的是發生了什麼，而實現描述的是如何實現。 對於貴族專制的問題，必須回答＂是＂或者＂否＂。就只能存在少數結構師而言，答案是肯定的…這實際上是一種無需任何歉意的貴族專制統治。
Chapter 5 畫蛇添足
中國人講的＂藝高人膽大＂，＂擅泳者溺＂大概有一點點這樣的意味，一開始的時候往往小心謹慎，通常是人之常情，這會是第一個項目無論是在項目週期上還是項目具體實現上均大致符合預期發展，不會帶來較大的出入的原因，在第二個項目的設計上，往往就會出現“因爲有經驗了，所以覺得可以根據第一次成功的背景將一些次要方案加入設計的想法。”往往會失敗，不僅僅是作項目，很多事情都會是這樣（難道這也有心理學的解釋麼喲喂…）。所以解決這個問題的關鍵？如果是搭配兩個結構師進行設計（一個老鳥一個新手），那麼風險是降低了，但是新手一旦進行獨立的真正意義上的第二個項目時間是不可避免還是會遇到同樣的問題，因此項目經理或是負責人員分配的高管必須尤其注意這個問題，或者讓這種第二次設計放在一個所需承擔風險較小的項目中？減少因項目失敗而帶來的損失。或是系統評估人員需要首先對於設計出的系統方案進行評估，每一次的改進或是功能的設計劃分都需要進行自習的後果評估和風險評估後才能進行實施？…這種書果然要看實際的案例才能分析啊啊…（我果然不是PM的料（ーー；））在開發第一個系統時，結構師傾向於精煉和簡潔。他知道自己對正在進行的任務不夠了解，所以他會仔細謹慎地工作。 一種普遍傾向是過分的設計第二個系統，向系統添加很多的修飾功能和想法，他們曾在第一個系統中被小心翼翼地放在次要位置。
Chapter 6 貫徹執行
這一章主要講的是文檔和例會的重要性，文檔是各個項目組成員之間溝通的唯一方式，例會是解決問題的好方法。在進行文檔寫作時需要注意的是要用至少兩種語言或者形式進行描述，一種爲主要描述的方法，另一種爲輔助描述的方法。這樣可以保證無論是開發人員還是項目組的其他人員均可對於該項目有較爲準確地認識。但是最重的項目實施完畢後很有可能與最初的設想是不一致的，此時應該儘量以機器上的代碼和以測試完畢可運行的程序爲準，而非強求按照文檔規定進行修改，除非出入極大（我感覺這種情況不大可能發生，周例會的時候就是爲了避免或者說規避這種風險的產生）。進一步根據文檔的小修小改可以作爲下一階段的迭代目標以趨於理論上的美好（好吧…這又是程序員的天生樂觀的氣質…（ーー；））。在文檔纂寫的過程中，爲什麼需要同一人員進行纂寫呢…因爲文檔需要有前後的一致性和連貫性，若是多人纂寫的文檔最後還是交由一兩人進行整理較爲妥當，並且在文檔纂寫的過程中，最好對於相關術語單獨構建編寫術語表進行文檔中提到的一些相關術語的解釋較好（我感覺啊…大型項目還是有必要弄個，簡單的搞個表格什麼的，不然寫到最後基本上就忘記了…個人觀點）。規範的文檔其實還是蠻重要的，口頭上的溝通一是沒有什麼規範性可言，二是口語化的東西太多，即便是書面化了都會有這樣那樣多樣化的表達，更別說是口頭的…所以吧…文檔和例會這種我們平時基本不屑的東西是必不可少的，我們之所以沒有感受到其重要性那是因爲我們沒有參與過大型項目的開發，甚至中型規模的都沒有…手冊是產品的外部規格說明，它描述和規定了用戶所見的每一個細節，同樣的，它也是結構師主要的設計產物。 精確往往比生動更重要。 通常的周例會每週一次，每次半天。 定期組織的例會建議上爲每6個月一次。解決周例會中堆積起來的問題。 當文檔和機器產生衝突的時候以機器爲準，因爲文檔更容易修改。
Chapter 7 爲什麼巴比倫塔會失敗
巴比倫塔具備了所有的我們認爲的必備條件，爲什麼還會失敗呢。
原文中是上帝制造了混淆，使得各個部落之間互相猜忌最終導致了項目的徹底失敗。在實際的項目中，可以說這種混淆是不可避免會存在的，不是人爲主觀製造，首先一個項目在需求的獲取過程中就會存在着用戶與需求獲取人員之間的理解差異，或許同樣的一句話，經過獲取人員的理解轉述後就會有不一樣的意義，更別說轉義爲書面語言正式成爲文檔，即便是在看文檔的過程中，再規範的文檔都會有令人迷惑的部分，此時就體現出了交流的重要性，團隊中的每個人員都有必要進行積極的交流，以求在交流的過程中消除混淆，保證項目的正常進行。團隊之間的交流途徑，通過可能的所有途徑：他們還缺乏兩個方面﹣交流，以及交流的結果﹣組織。
工作手冊不是一個嚴格的項目技術文檔。非正式途徑：電話… 會議：常規項目會議 工作手冊：在項目的開始階段應該準備正式的項目工作手冊。
我的理解是這個所謂的工作手冊在今天看來實際上就可以說是項目的wiki（注意這本書的作者是在1986年寫的啊啊啊啊）和show diff的選項。•大型項目的組織結構它是對項目必須產出的一系列文檔進行組織結構的一部分
在各個職能安排何劃分中，產品經理和技術主管的角色安排是最難的，通常情況下，會有幾種方案：讓我們考慮一下樹狀編程隊伍，以及要使他們有效，每棵子樹所必須具備的基本要素： 1、任務（a mission） 2、產品負責人（a producer） 3、技術主管或結構師（a technical director or architect） 4、進度（a schedule） 5、人力的劃分（a division of labor） 6、各部分之間的接口協議（interface definitions among parts）
在構建大型開發團隊時，往往還是產品經理作爲決策者，我們可不可以這樣認爲，在以後的公司訴求中，會有這麼一種情況發生，就是技術主管可以先由小的項目開始進行鍛鍊，加上相關管理知識的學習以及在大型項目中充當副手見習的經驗漸漸轉型爲可以勝任產品經理工作的人？也就是說，一個好的公司運作，不僅僅是要有好的技術人才，其實更需要的是一個產品經理對其產品進行高瞻遠矚式的決策以減少相應的損失。綜上，團隊內外量好的溝通以及良好的團隊架構均是一個項目能否成功的關鍵所在。1、技術主管和產品經理是同一個人。適用於6人左右的團隊，通常這兩種技術兼具的人相當少。 2、產品負責人指揮，技術主管充當左右手。這種情況相當難，很難在技術主管不參與任何管理工作的同時，建立起其在技術上的權威。 3、技術主管作爲總指揮，產品經理作爲其左右手。還是適用於小型團隊。
Chapter 8 胸有成竹
根據Portman的數據說明我們可以看出，在項目進行過程中僅僅通過項目的技術部分的工作對於項目整體做出完全的估算是不切實際的，其中一點就是，其實對於技術工作的估算就是有很大難度的，我們通常都會有一定的偏差值，多數情況下都是過多估計了技術所花費的時間，實際上花在非技術層面上的時間更多（ーー；）•Portman的數據 日誌顯示，事實上他的團隊僅僅用了50%的工作周來進行實際的編程和調試，估算上的失誤完全可以由該情況進行解釋。簡言之，估算對於每個人年的技術工作時間數量作了不現實的假設。
這個表示的實際上是大型複雜系統開發的現狀。生產率同樣的被劃分爲兩個類別：控制程序的生產率大約是600指令每人年，語言翻譯大約是2200指令每人年。
總結：生產率會根據任務本身複雜和困難程度表現出顯著差異。 在複雜程度估計這片“沼澤”上的指導原則是：編譯器的複雜度是批處理程序的3倍，操作系統的複雜度是編譯器的3倍。
實際上現在大多數的程序構建均是使用高級語言完成的，極少情況下使用低級的指令語言或是機器語言。那也可以認爲說是針對不同的項目，使用不同的語言進行開發也是對於生產率有一定的影響的，但是，就項目整體而言，未必會有很大的生產率上的提高，畢竟花在編程上的時間並不是最多的，這個部分也不是最難的。這一章比較難有一個形象的認識，雖然Brooks用了大量的數據加以說明，但是因爲沒有參與過，也沒有管理過大型的項目，因此，還是沒有比較形象的認識，故，以後再慢慢回味吧，暫且只記結論。•對於常用編程語句而言，生產率似乎是固定的。這個固定的生產率包括了編程中需要的註釋，並可能存在錯誤的情況。 •使用適當的高級語言，編程的生產率可以提高5倍。
Chapter 9 削足適履
當時的系統硬件資源十分寶貴，所以在進行系統開發的時候必須詳細計算好所佔用的系統的硬件資源以謀取軟件和硬件的一個較大的獲得的利益，但是在硬件顯得看上去如此廉價的今天，我們還是要注意這個問題，怎樣合理地利用有限的硬件資源纔是關鍵，浪費用戶硬件資源的軟件都不是好軟件(<_<)，在每一次軟件的計劃開發中都應當是恰當地使用硬件資源，而不是無節制地浪費。•作爲成本的程序空間 同任何開銷一樣，規模本身不是壞事，單不必要的規模是不可取的
也就是說，首先還是對於項目大小最好由於個較爲徹底和詳細地認識，並且對每個部分能夠做醋比較好的劃分，再次是溝通溝通溝通，不管多大的項目還是溝通最重要。每個開發者都應當爲別人，從項目整體角度考慮爲最終的用戶考慮，而不是一味追求技術上的創新和自己模塊的最優化。對於項目經理而言，規模的控制既是技術工作的一部分，也是管理工作的一部分。 第一個道理很清楚：在制定駐留空間預算一樣，應該制定總體規模的預算；在制定規模預算一樣，應該制定後臺存儲訪問的預算。 第二個道理也很清晰：在指明模塊有多大的同時，確切定義模塊的功能。 第三個教訓，項目本身很大，缺乏管理和溝通，以至於每個團隊成員都認爲自己是爭取小紅花的學生而不是構建系統軟件產品的人員。
也就是說，第一個方法實際上就是在設計軟件實現時將其每個部分的粒度設計的比較細，最好可以使用戶獨立進行定製，這樣一來實際是減少了開發人員的負擔，使其只需要關注小粒度的部分，設計時需要注意設計好每部分的接口即可。第二個觀點是設計公共庫，最好是兩個，一個是以空間換時間，另一個是以時間換空間。並且我覺得公共庫的開發更符合軟件重用的思想。也更容易維護。•空間技能 技能一：功能交換尺寸。 技能二：考慮空間﹣時間的折衷。
實際上計算機所做的大部分的工作就是數據的處理，所以在整個處理的過程中數據結構是怎樣的回直接對於程序性能的好壞有很大的影響。數據表現形式是程序的根本
Chapter 10 提綱挈領
這章的內容相當少也相當簡單，主要闡述的就是文檔的重要性，就和章節標題所顯示的那樣﹣提綱挈領，其實這就是文檔主要的工作。一開始的時候我們其實都會很疑惑文檔到底是用來做什麼的，甚至在很長的一段時間裏面，大家都是糊差事，糊弄完文檔了事，認爲文檔是一個十分無關緊要的雞肋，實際上並非如此，我們認爲其無關緊要，甚至很多時候都是弄完代碼之後再進行文檔的補足，表面上看起來可以交出比價理想的差事，實際上是因爲我們所參與的項目規模十分十分的小（可以用微型來解釋麼(<_<)）。在大型，其實是比較正式的一個項目中，我們要寫的文檔其實是十分必要而且作用也是十分重要的，規定了軟件大致的骨架，其實也是團隊內部同志們之間進行交流的一項較爲有利的依據。最近的敏捷也好，極限也好，有同志們簡單的覺得是不需要寫文檔的，代碼即文檔。我覺得不妥，除非隊員之間默契度十分的高，或者是項目各項需求及邊界規範的十分明確，大家不會有任何歧義，否則文檔就是必要的，哪怕是隻言片語…又或者是，除非代碼風格十分優秀，可以保證註釋的質量相當的高，另當別論。•爲什麼要有正式的文檔 首先，書面記錄決策是很有必要的。只有記錄下來，分歧纔會明朗，矛盾纔會突出。 第二，文檔能夠作爲同其他人的溝通渠道。 最後，項目經理的文檔還可以作爲數據基礎和檢查列表。