章節：人月神話
  當進度與計劃出現偏差時，千萬不要盲目的向開發團隊增加人手，那樣只能帶來毀滅性的災難，使開發進度變的更加緩慢。

章節：外科手術隊伍
  新型高效團隊的分工：外科醫生，副手，管理員，編輯，兩個秘書，程序員，工具維護員，測試人員，語言專家。
  當項目過大時，首先要做的是就是分派任務，然后進行協調，當然首先得要協調概念的完整性，這個時候的協調就不再是所有項目的開發者，而僅僅是那些“外科醫生”。

章節：貴族專制、民主政治和系統設計
  系統的結構師的工作是運用專業技術知識來支持用戶的真正利益。
  概念的完整性要求設計必須由一個人或者非常少數互有默契的人員來實現。
  產品的成本性能比很大程度上依靠實現人員,易用性很大程度上依賴結構師。

章節：畫蛇添足
  結構師要想成功的前提：
  1.牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，不能支配；
  2.時刻準備為所指定的說明建議一種實現的方法，同時準備接受其他任何能達到目標的方法；
  3.對建議保持低調和平靜；
  4.準備放棄堅持所作的改進建議；

  第二個系統是設計師們所設計的最危險的系統！避免危險的方法：自我約束準則。

章節：貫徹執行
  手冊強調的是精確。
  形式化定義的優點是精確性高，缺點是不易理解。填補這一確定的方法是插入記敘性文字。
  會議分成兩個級別：周例會和年度大會。
 1.周例會是每周半天的會議，由所有的結構師，加上硬件和軟件實現人員代表和市場計劃人員參與，由首席系統結構師主持，賦予首席系統結構師最終決斷權。
 2.年度大會一般持續兩周，一般是每六個月舉行一次，出席人員由體系結構小組，編程人員，實現人員的結構代表，編程經理，市場和實現人員參與，由項目經理主持，會議是為解決平時所堆積起來的問題而舉行的。
  結構師應該建立電話日志，并且每周交流一次。

章節：為什么巴比倫塔會失敗
  交流的缺乏導致爭辯，沮喪和群體猜忌。很快，團隊開始分裂---大家選擇了孤立，而不是相互爭吵。
  軟件項目開發時隊員交流途徑有電話，會議，工作手冊。
  項目手冊的第一步是對所有的備忘錄編號，接著就開始進行實時更新，在更新時必須在頁面上標記發生改變的文本，分發的變更頁附帶獨立的總結性文字，對變更的重要性以及批注進行記錄。
  徹底解決手冊太厚的方法：編程人員僅僅了解自己負責的部分，而不是整個系統的開發細節時，工作效率最高。但其先決條件是精確和完整地定義所有借口。
  產品負責人的角色：組建團隊，劃分工作及制訂進度表。他主要是與團隊外部，向上和水平地溝通，他建立團隊內部的溝通和報告方式。最后他確保進度目標的實現，根據環境的變化調整資源和團隊的構架。
  技術主管的角色：他對設計進行構思，識別系統的子部分，指明從外部看上去的樣子，勾畫它的內部結構。他提供整個設計的一致性和概念完整性；他控制系統的復雜程度。提供解決問題的答案，根據需要調整系統設計。他所做的工作幾乎完全是技術性的。
  大型項目中，產品負責人作為管理者是更適合的安排。
  開發中最重要的就是交流與溝通，特別是在大型的項目中。

章節：胸有成竹
  對常用編程語句而言。生產率似乎是固定的。這個固定的生產率包括了編程中需要的注釋，并可能存在錯誤的情況。
  使用適當的高級語言，編程的生產率可以提高5倍。

章節：削足適履
  數據的表現形式是編程的根本。

章節：提綱挈領
  項目經理文檔管理做法：項目開始時，立刻正式生成若干文檔作為自己的數據基礎，哪怕這些迷你文檔非常簡單：接著，他會和其他人員一樣要求各種文檔。文檔中必須包含以下幾點：
 1.產品開發目標。
 2.產品技術說明。
 3.時間進度表。
 4.資金預算。
 5.人員組織圖。
  永遠記?。喉椖拷浝淼娜蝿詹皇菦Q策，而是溝通！文檔建立也是為了實現這個目標！

章節：未雨綢繆
  組織架構的設計要盡量做到最小化成員間的接口，以便在將來能使系統在最大程度上易于修改。
  軟件維護主要包含對設計缺陷的修復。用戶越多，發現的錯誤就會越多。
  設計實現的人員越少，接口越少，產生的錯誤也就越少。
  不論是誰，即使是最數量的軟件維護工作，也只是放緩了系統退化到非穩態的進程。

章節：干將莫邪
  多種多樣的開發工具不但不會促進溝通，反而會妨礙溝通！項目經理應分配一個人專門用于管理工具。
  應分配固定的時間讓每個單元小組成員使用機器，這樣盡管機器的利用程度可能會有些降低，但有助于提高生產率。
  給每個小組開發成員分配一個區域，用來存放他的程序拷貝、測試用例以及單元測試需要的測試輔助例程和數據，在這個開發庫中，不存在任何限制開發人員的規定，他可以自由處置自己的程序，他是它們的擁有者。當開發人員準備將軟件單元集成到更大的部分時，他向集成經理提交一份拷貝，后者將拷貝放置在系統集成子庫中。此時，原作者不可以再改變代碼，除非得到了集成經理的批準。

章節：整體部分
  自頂向下的設計：開始是勾畫出能得到主要結果的，但比較粗略的任務定義和大概的解決方案。然后，對該定義和方案進行細致的檢查，以判斷結果與期望之間的差距。同時，將上述步驟的解決方案，在更細致的步驟中進行分解，每一項任務定義的精化變成了解決方案中算法的精化，后者還可能伴隨著數據表達方式的精化。
  關鍵的地方和構件無bug程序的核心，是把系統的結構作為控制結構來考慮，而不是獨立的跳轉語句。

章節：禍起蕭墻
  當人們聽到某個項目的進度發生了災難性偏離時，可能會認為項目一定是遭受了一系列重大災難。然而，通常災禍來自白蟻的肆虐，而不是龍卷風的侵襲。
  里程碑的選擇只有一個原則，它必須是具體的、特定的、可度量的事件，能夠進行清晰定義。

章節：另外一面
  將文檔負擔降低到最低的方法：
  1.借助那些出于語言的要求而必須存在的語句，來附加盡可能多的“文檔”信息。因此，標簽、聲明語句、符號名稱均可以作為工具，用來向讀者表達盡可能多的意思。
  2.盡可能地使用空格和一致的格式提高程序的可讀性，表現從屬和嵌套關系。
  3.以段落注釋的形式，向程序中插入必要的記述性文字。