讀書：《人月傳說》摘錄版1-5章
人月神話.PNG
第一章 焦油坑
並不是所有努力都是成功的。大專案的管理問題和小專案的管理問題區別很大－關鍵需要維持產品自身的概念完整性。我們想解決問題，就必須試圖先去了解問題-任何一個單獨的問題都能解決，但問題互相糾纏和累積在一起的時候，團隊的行動會越來越慢。
對問題的麻煩程度，每個人似乎都會感到驚訝，並且很難看清問題的本質。程式設計系統產品的演進：
image.png
左上部分程式。它本身是完整的，可以由作者在所開發的系統平臺上執行。它通常是車庫中產出的產品，以及作為單個程式設計師生產率的評估標準。有兩種途徑可以使程式轉變為更有用的，但是成本更高的產物［向右和向下］。
水平邊界以下，程式轉變成程式設計產品。這是可以被任何人執行、測試、修復和擴充套件的程式，可以在多種作業系統平臺上執行，供多套資料使用。要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須廣泛地適用於所有可以合理使用的基本演算法。接著，對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這就意味著必須準備、執行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和範圍。此外，要將程式提升為程式產品，還需要有完備的文件，每個人都可以加以使用、修復和擴充套件。經驗資料表明，相同功能的程式設計產品的成本，至少是經過測試程式的3倍。
垂直邊界右邊，程式轉變為程式設計系統中的一個構建單元。它是在功能上能互相協作、具有規範的格式、可以進行互動的程式集合，並可以用來組裝和搭建整個系統。要成為程式設計系統構件，程式必須按照一定的要求編制，使輸入和輸出在語法語義與精確定義的介面一致。同時程式符合預先定義的資源限制-記憶體空間、輸入輸出裝置、計算機時間。最後，程式必須同其他系統構建單元的介面一道，以任何能想象到的組合進行測試-由於測試用例會隨著組合不斷增加，所以測試範圍必須廣泛。因為一些意向不到的互動會產生許多不易覺察的bug，測試工作量將會非常耗時，相同功能的程式設計系統構件成本至少是獨立程式的3倍。
右下部分代表程式設計系統產品，其成本高達9倍。然而，只有它才是真正有用的產品，是大多數系統開發的目標。
程式設計的樂趣：快樂是一種建立事物的純粹快樂、快樂來自開發對他人有用的東西、內心深處，我們期望我們的勞動成果能夠被他人使用，並能對他們有所幫助、快樂來自於整個過程體現出一股強大的魅力－零件一直在一起精妙執行、持續學習的快樂，非重複性特性、在易於駕馭的介質上工作。程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。
職業的苦惱［過程並不全都是快樂－事先了解一些程式設計固有的苦惱，它真正出現時才能更加坦然地面對］：苦惱來自追求完美/苦惱來自由他人來設定目標、供給資源和提供資訊［個人權威和他所承擔的責任是不匹配的］，對他人依賴是非常痛苦的事情［他人的程式設計得並不合理、實現拙劣、釋出不完整－沒有原始碼或測試用例、或者文件記錄得很糟］，需要花時間去研究和修改/概念性設計是有趣的，但尋找瑣碎的bug卻只有一項重複性的活動［伴隨創造性活動，往往是枯燥沉悶的時間和艱苦的勞動］，除錯和差錯往往是線性收斂的，尋找最後一個錯誤比第一個錯誤將花費更多的時間/產品即將做完卻已顯得過時［更好的構思、替代方案］。誠然，產品開發所基於的技術在不斷進步，一旦設計被凍結在概念上就已經開始陳舊了。不過實際產品需要一步步按階段實現－實現落後與否的判斷應根據其他已有的系統，而不是未實現的概念。因此，我們所面臨的挑戰和任務是在實際進度和有效的資源範圍，尋找解決實際問題的切實可行方案。
第二章 人月神話
缺乏合理的進度安排是造成專案滯後最主要原因，它比其他所有因素加起來影響還要大。導致原因：對估算技術缺乏有效的研究，基於不真實的假設、採用估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆、對自己估算缺乏信心，軟體經理通常不會有耐心持續地估算這項工作、對進度缺乏跟蹤和監督－需要常規的追蹤技術和常規監督程式、意識到進度偏移，下意識的反應是增加人力。
樂觀主義：所有的程式設計人員都是樂觀主義者。“這次它肯定會執行”“我剛剛找出最後一個錯誤”。
第一個錯誤假設：一切都將運作良好，每一項任務所花費它所“應該”花費的時間。《創造者的思想》將創造性活動分為三個階段：構思、實現和交流。只有在實現過程中，才能發現我們構思的不完整性和不一致性。然而大型的程式設計工作，或多或少包含了很多工，某些任務還具有前後的次序，從而一切正常的概率變得非常小，甚至接近於零。
第二個謬誤思考方式：在估計和進度安排中使用的工作量單位人月－人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話，它暗示人員數量和時間是可以互相替換的。其基於的假設是：某個任務可以分解給參與人員，並且他們之間不需要互相的交流。當任務由於次序上的限制不能分解時，人手的增加對進度沒有幫助。對於可以分解，但子任務之間需要互相溝通和交流的任務，必須在計劃工作中考慮溝通的工作量（溝通所增加由兩個部分組成：培訓和互相的交流－每個人員需要進行技術、專案目標、總體策略以及工作計劃的培訓。這種培訓不能分解，該部分增加的工作量隨人員的數量呈線性變化+溝通工作量可能延長了而不是縮短了時間進度）。
單元測試和系統測試受順序限制，需要的時間依賴於所遇到的錯誤、缺陷的數量及其難以捕捉的程度，理論上缺陷數為零－實際上由於樂觀主義，通常實際出現的缺陷比例比預料的要多很多。因此，系統測試進度的安全常常是程式設計中最不合理的部分，作者的經驗法則：1/3計劃、1/6編碼、1/4構件測試和早期系統測試、1/4系統測試，所有的構件已完成。與傳統的進度安全方法不同（很少有專案允許為測試分配一半的時間，大多數專案的測試實際上是花費進度一半的時間）：分配給計劃的時間比平常的多。這樣只能勉強產生詳細和穩定的計劃規格說明，並不足以容納對全新技術的研究和探索。
對所完成程式碼的除錯和測試，投入近一半的時間，比平常的安排多得多。容易估計的部分，如編碼，僅僅分配了1/6的時間。
許多專案在系統測試之前還能保持進度。或者說，除了系統測試，進度基本能保證。特別需要指出的是，不為系統測試安排足夠的時間簡直就是一場災難－因為延遲發生在專案快完成的時候，此時此刻的延遲具有不尋常的、嚴重的財務和心理上的反應。早期規劃的系統測試時間是必要的。更為嚴重的是，當軟體用來支援其他商業活動（硬體運送、新裝置操作等）時，在即將釋出時出現延誤，所付出的二次商業代價是非常昂貴的。實際上，上述的二次成本遠遠高於其他開銷。
為滿足顧客期望日期而造成的不合理進度安排，在軟體領域中卻比其他任何工程領域要普遍得多。而且，非階段化方法的採用，少得可憐的資料支援，加上完全藉助軟體經理的直覺，這樣的方式很難生產出有力的、看似可靠的和規避風險的估計－需要開發並推行生產率圖表、缺陷圖表、估算規則等，從共享資料中獲益；或者專案經理堅持估算，憑藉經驗和直覺總比期望結果強得多。
軟體落後於進度通常做法：加人（考慮培訓時間，不考慮任務的重新劃分和額外的系統測試）、重新安排進度、削減任務等。向進度落後的專案增加人手，只會使進度更加落後。專案的時間依賴於順序上的限制，人員的最大數量依賴於獨立子任務的數量-可以推算出進度表，人員安排少，花費時間也較長（唯一的風險是產品可能會過時）。總之，在眾多的專案中，缺乏合理的進度安排是造成專案滯後的主要原因，它比其它所有因素加起來的影響還要大。
第三章 外科手術隊伍
需要協作溝通的人員數量影響著開發成本，因為成本的主要組成部分是互相的溝通和交流，以及更正溝通不當所引起的不良結果-也暗示系統應該由儘可能少的人員來開發。最好的和最差的表現生產率可能達到10:1，一擁而上的開發方法是高成本、速度緩慢、低效的，開發出的是無法在概念上進行整合的產品。但小型、精幹隊伍概念上的問題：對於真正意義上的大型系統，它太慢了。對於效率和概念的完整性來說，最好由幹練的人員來設計和開發；對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。
如何調和這兩方面的矛盾？建議大型專案的每一個部分由一個團隊解決，類似外科手術方式組建。同每個成員擷取問題某個部分的做法相反，由一個人來完成問題的分解，其他人給予他所需要的支援，以提高效率和生產力-很少人被包含在設計和開發中，其他許多人來進行工作的支援。如何運作（十個人有七個專業人士在解決問題，而系統是一個人或者最多兩個人思考的產物，客觀上達到概念的一致性，不一致則由外科醫生單方面解決），外科醫生和副手都瞭解所有的設計和全部的程式碼：
外科醫生，首席程式設計師。他親自定義功能和效能技術說明書，設計程式，編制原始碼，測試以及書寫技術文件。首席程式設計師需要極高的天分、十年的經驗和應用數學、業務資料處理或其他方面的大量系統知識和應用知識。
副手。他是外科醫生的後備，能完成任何一部分工作，但相對具有的經驗減少。他的主要作用是作為設計的思考者、討論者和評估人員。外科醫生試圖和他溝通設計，但不受他建議的限制。副手經常在於其他團隊討論有關功能和介面問題時代表自己的小組。他需要詳細瞭解所有的程式碼，研究設計策略的備選方案。顯然，他充當外科醫生的保險機制。他甚至可能編制程式碼，但對程式碼的任何部分，不承擔具體的開發職責。
管理員。外科醫生是老闆，必須在人員、薪酬、辦公空間等方面具有決定權，但他決不能在這些事務上浪費時間。需要一個控制財務、人員、工作地點和辦公裝置的專業管理人員，該管理員充當與組織中其他管理機構的介面。建議僅在專案具有法律、合同、報表和財務的需求時，管理者才有全職責任。否則，一個管理員可以為兩個團隊服務。
編輯。外科醫生負責文件的生成。無論對外部描述和內部描述。而編輯根據外科醫生的草稿或口述，進行分析和重新組織，提供各種參考資訊和書目，對多個版本進行維護，並監督文件生成的機制。
兩個文祕。管理員和編輯每個人需要一個文祕。管理員的文祕負責專案的協作一致和非產品檔案。
程式職員。他負責維護程式設計產品庫所有團隊的技術記錄。該職員接受文祕性質的培訓，承擔機器碼檔案和可讀檔案的相關管理責任。記錄或標識計算機輸入彙集到該職員，由他進行歸檔和編制索引。從個人藝術到公共實踐Mills-它向所有團隊成員展現了所有計算機的執行和產物，並將所有的程式和資料看作是團隊的所有物。程式職員可以對那些經常被忽視的雜事進行系統整理，確保他們的質量，並強化團隊最有價值的財富-工作產品。
工具維護人員，保證所有基本服務的可靠性，以及承擔團隊成員所需要特殊工具的構建、維護和升級責任。即使已經擁有非常卓越的、可靠的集中式服務，每個團隊仍然需要自己的工具維護人員。工具維護人員常常需要開發一些實用程式、編制具有目錄的函式庫以及巨集庫。
測試人員。外科醫生需要大量合適的測試用例，用他來對編寫工作片段，以及整個工作進行測試。
語言專家。一兩個樂於掌握複雜程式語言的人。這些專家非常有幫助，很快大家會向他諮詢。外科醫生主要是系統設計者以及考慮系統的整體表現。語言專家則尋找一種簡潔的、有效的使用語言的方法來解決複雜、棘手問題，他們通常需要對技術進行一些研究。通常一個語言專家可以為兩到三個外科醫生服務。
團隊的擴建：決定設計的人員是原來的1/7或更少，外科醫生思路。對於協調的問題，還是需要使用分解的技術。可以認為整個系統必須具備概念上的完整性，要有一個系統結構師從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體系結構設計和實現之間的界限，系統架構師必須一絲不苟地專注於體系結構。
第四章 貴族專制、民主政治和系統設計
作者主張概念完整性應該是系統設計最重要的考慮因素，為反映一系列連貫的設計思路，寧可省略一些不規則的特性和改進，也不提倡獨立和無法整合的系統，哪怕它們其實包含著許多很好的設計。
Q：如何獲得概念的完整性
A：易用性，功能與理解上覆雜程度的比值才是系統設計的最終測試標準。單是功能本身或者簡潔都無法成為一個好的設計評判標準。很多情況下，功能而非簡潔總是被用來衡量設計人員工作中出色程度。但是，一旦使用易用性作為衡量標準，單獨的功能和簡潔都是不均衡的，都只達到了真正目標的一半。對於給定級別的功能，能用最簡潔和最直接的方式來指明事情的系統是最好的。簡潔和直白來自概念的完整性。每個部分必須反映相同的原理需求的一致平衡。在語法上，每個部分應使用相同的技巧；在語義上，應具有同樣的相似性。因此，易用性實際上需要設計的一致性和概念上的完整性。
貴族專制統治和民主政治
概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。進度要求很多人員來開發系統，解決方法包括：仔細地對設計方法和具體實現進行分工，或使用主治醫生的組建程式設計開發團隊。
系統的體系結構指的是完整和詳細的使用者介面說明。對於計算機，它是程式設計手冊；對於編譯器，它是語言手冊；對於控制程式，它是語言和函式呼叫手冊；對於整個系統，它是使用者要完成自己全部工作所需要參考的手冊集合。系統的結構師是使用者的代言人。結構師的工作，是運用專業技術知識來支援使用者的真正利益，而不是維護銷售人員、製作者所鼓吹的利益。體系結構同實現必須仔細地區分開來。系統的概念完整性決定了其使用的容易程度-不能與系統基本概念進行整合的良好想法和特色，最好放在一邊，不予考慮。如果出現了很多非常重要但不相容的構想，就應該拋棄原來的設計，對不同基本概念進行合併，在合併的系統上重新開始。對於貴族專制統治的問題，必須回答是與否。就只能存在少數的結構師而言，答案是肯定的，他們的工作產物的生命週期比那些實現人員的產物要長，並且結構師一直處在解決使用者問題，實現使用者利益的核心地位。如果得到系統概念的完整性，那麼必須有人控制這些概念，這實際上是一種無需任何歉意的貴族專制統治。
外部技術說明的編制工作並不比具體設計實現更富有創造性，它只是一項性質不同的創造工作而已。在給定體系結構下的設計實現，同樣需要同編制技術說明一樣的創造性、同樣的新思路和卓越的才華。實際上，產品的成本效能比很大程度上依靠實現人員，就如同易用性很大程度上依賴結構師一樣。外部體系結構規定實際上是增強，而不是限制實現小組的創造性。一旦他們將注意力集中在沒有人解決過的問題上，創意就開始奔湧而出；在毫無限制的實現小組中，進行結構的決策時，會出現大量的想法和爭議，對具體實現的關注反而比較少。
在等待時，實現人員應該做什麼。當建議小型體系結構團隊來編寫計算機或程式設計系統的所有外部技術說明時，程式設計人員提出了三個反對意見：該說明中的功能過於繁多，而對實際情況中的成本考慮比較少；結構師獲得了所有創造發明的快樂，剝奪了實現人員的創造力；當體系結構的隊伍緩慢工作時，很多實現人員只能空閒地坐著等待。
整個創造性活動包括三個獨立階段：體系結構、設計實現和物理實現-可以同時開始和併發執行。在外部說明完成前，設計實現人員可以做的事情-定義時間和空間目標，瞭解產品執行的平臺配置；開始設計模組的邊界、表結構、路徑和階段分解、演算法以及所有的工具，還需要花時間和體系結構師溝通。物理實現則在庫的調整、系統管理以及搜尋和排序演算法上，有許多事情處理。垂直劃分
第五章 畫蛇添足
結構師的互動準則和機制：儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。面對估算過高的難題，結構師有兩個選擇：削減設計或者建議用成本更低的實現方法來挑戰估算的結果－後者是固有的主觀感性反應。此時，結構師是在向開發人員的做事方式提出挑戰（一般開發人員會反對體系結構上的修改建議。通常他是對的－當正在實現產品時，某些次要特性的修改會造成意料不到的成本開銷）。想要成功，結構師必須：
牢記開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配
時刻準備著為所指定的說明建議一種實現的方法，同樣準備接受其他任何能達到目標的方法
對上述的建議保持低調和不公開
準備放棄堅持所做的改進建議
自律－開發第二個系統所帶來的後果：開發第一個系統結構師傾向於精煉和簡潔－他知道自己對任務不夠了解，所以他會謹慎仔細地工作。在設計第一個專案時，他會面對不斷產生的裝飾和潤色功能－這些功能都會擱置在一邊，作為下一個專案的內容。第二個系統是設計師們所設計最危險的系統－而當他著手第三個或第四個系統時，先前的經驗會互相驗證，得到對此類系統通用特性的判斷，而且系統之間的差異會幫助他識別出經驗中不夠通用的部分。一種普遍傾向是過分設計第二個系統，向系統中新增很多裝飾功能和想法，它們曾在第一個系統中被小心謹慎地放在次要位置。開發第二個系統所引起的後果的另一個表現與純粹的功能修飾和增強明顯不同，也就說存在對某些技術進行細化、精煉的趨勢。由於基本系統設想發生了變化，這些技術已經顯得落後。
結構師如何避免開發第二個系統所引起的後果，從而避免畫蛇添足？雖然無法跳過二次系統，但可以有意識關注這個系統的特殊危險，運用特別的自我約束準則，來避免那些功能上的過於修飾；根據系統基本理念及目的變更，捨棄一些功能。一個可以開闊的結構師眼界的準則是為每個小功能分配一個值：每次改進，功能x不超過m位元組的記憶體和n微秒－這些值會在一開始作為決策的嚮導，在物理實現期間充當指南和對所有人的警示。
專案經理如何避免開發第二個系統所引起的後果，從而避免畫蛇添足？他必須堅持至少擁有兩個系統以上開發經驗結構師的決定。同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整體現。
第六章 貫徹執行（專案團隊擁有形式規範、富有經驗的結構師和程式設計人員）
文件化的規格說明－手冊，它描述和規定了使用者所見的每一個細節；同樣的，它也是結構師主要的工作產物。對實現人員而言，修改的階段化是很重要的－在進度表上應該有帶日期的版本資訊。
手冊不但要描述包括所有介面在內的使用者可見的一切，它同時還要描述使用者看不見的事物。後者是程式設計實現人員的工作範疇，而這裡他的設計和創造自由是不應該被限制的。體系結構設計人員必須為自己描述任何特性準備一種實現方法，但是他不應該試圖支配實現的過程。
規則說明的風格必須清晰、完整和準確。使用者常常會單獨提到某個定義，所以每條說明都必須重複所有的基本元素，所以所有文字都要相互一致。往往使手冊讀起來枯燥乏味，但是準確比生動更加重要。思路是大約十個人的想法，但如果想保持文字和產品之間的一致性，則必須由一個或兩個人來完成將其結論轉換成書面規格說明的工作。而且，將定義書寫成文字，必須對很多原先並不是非常重要的問題進行判斷，並得出結論。在整個設計中，保證這些看似瑣碎的問題處理原則上的一致性，絕不是一件無關緊要的事情。定義了相容性，描述將達到的目標，列舉外觀部分，必須在仔細定義規定什麼的同時，定義未規定什麼。
形式化定義：手冊的作者必須注意到自己的思路和語言，達到所需要的準確程度。一種頗具吸引力的做法是使用形式化標記方法以達到精確度。形式化定義是精確的，傾向完整，缺點是不易理解-增強信心。記述性文字可以表達結構性原則，描述階段上或層次上的結構，並提供例項-容易表達異常和強調對比的關係，而且可以解釋原因-內容易於領會和講授。如果同時使用形式化和記述性定義，則必須以一種作為標準，另一種作為輔助描述，並照此明確進行劃分。在規定系統外部功能的同時，幾乎所有的形式化定義均會用來描述和體現硬體系統或軟體系統的某個設計實現。語法和規則的表達可以不需要具體的設計實現，但是特定的語義和意義通常會通過一段實現該功能的程式來定義-形式化定義僅僅用於外部功能，說明它們是什麼。形式化設計是一種形式化定義的方法。
所有定義的問題都可以通過測試解決-使用實現來作為一種定義的方式有一些優點。首先，所有問題都可以通過試驗清晰地得到答案，從來不需要爭辯和商討，回答是快捷迅速的。通過定義得出答案，從來不需要爭辯和商討，回答是快捷迅速的。通過定義得出的答案，總是同所要求的一樣精確和正確。缺點包括實現可能更加過度地規定了外部功能-無效的語法通常會產生某些結果。作為一種定義，實現體現了過多的內容：它不但描述了系統必須做什麼，同時還聲明瞭自己到底做了些什麼。使用實現作為形式化定義特別容易混淆。當實現作為標準時，還必須防止對實現的任何修改。
建立模組間介面語法，傳遞引數或共享儲存器宣告。數百人在場的大型磋商會議往往需要大規模和非常正式地召集：周例會和年度大會。周例會是每週半天的會議，由所有的結構師，加上軟硬體實現人員代表和市場計劃人員參與，由首席系統架構師主持。會議中，任何人可以提出問題和修改意見，但是建議書通常以書面形式在會議前分發，重點是創新，而不僅僅是結論。該小組試圖發現解決問題的各種方法，然後少數解決方案會被傳遞給一個或多個結構師，詳細記錄到書面變更建議說明書中。接著會對詳細的變更建議做出決策 -經歷幾個反覆過程，實現人員和使用者會仔細地進行考慮，正面和負面的意見都會被很好的描述。如果達成了共識非常好、如果沒有則由首席架構師來決定。這需要花費時間，最終所釋出的結論是正式和果斷的。周例會的決策會給出迅捷的結論，使工作繼續開展下去。如果任何人對結果過於不滿，可以付諸於專案經理，這種會議的卓有成效是由於：
數月內，相同小組-結構師、使用者和實現人員-每週交流一次。因此，大家對專案相關的內容比較瞭解，不需要安排額外時間對人員進行培訓。
小組十分睿智和敏銳，深刻理解所面對的問題，並且與產品密切相關。沒有人是“顧問”的角色，每個人都要承擔義務。
當問題出現時，在界線的內外部同時尋求解決方案。
正式的書面建議集中了注意力，強制了決策的制定，避免了會議草稿紀要方式的不一致。
明確地授予首席結構師的權力，避免了妥協和拖延。
一些決定可能沒有很好地貫徹，一些小事情並沒有被參與者真正地接受，其他決定造成了未曾遇到的問題。這些問題，有時周例會並不贊同重新考慮，慢慢積少成多-為解決這些堆積起來的問題，舉行年度或半年度大會，典型的年度大會會持續兩週。出席人員包括體系結構小組和程式設計人員、實現人員的結構代表，同時包括程式設計經理、市場實現人員，由專案經理主持。典型的議程包括大約200個條目，大多數條目規模很小，它們列舉在會議室周圍的圖表上，每個不同的聲音都有機會得到表達，然後制定出決策。每天早晨，會議參與人員會在座位上發現更新了的手冊說明，記錄了前一天的各項決定。這些“收穫的節日”不僅可以解決決策上的問題，而且使決策更容易被接受。每個人都在傾聽，每個人都在參與，每個人對複雜約束和決策之間的互相關係有了更加透徹的理解。
無論規格說明已經多麼精確，還是會出現無數結構理解和理解方面的問題。對於存在疑問的實現人員，應鼓勵他們打電話詢問相應的結構師，而不是一邊自行猜測一邊工作，這是一項很基本的措施 的（他們需要認識的是，上述問題的答案必須是可以告知每個人的權威性結論）。一種有用的機制是由結構師儲存電話日誌，日誌中記錄每個問題和相應的回答。每週對若干結構師的日誌進行合併，重新整理，並分發給使用者和實現人員-權威性結論。
產品測試小組是顧客的代言人，專門尋找缺陷。該小組根據規格說明檢查機器和程式，充當麻煩的代言人，查明每個可能的缺陷和互相矛盾的地方。細心的產品測試人員總會發現一些沒有貫徹執行、設計決策沒有正確理解或準確實現的地方。因此，設立測試小組使設計決策得以貫徹執行的必要手段，同樣也需要儘早著手，與設計同時實施。
第七章 為什麼巴比倫塔會失敗
巴比倫塔專案到底有多好的先決條件？他們是否有：清晰的目標？人力？材料？足夠的時間？足夠的技術？這些都有，為什麼還會失敗呢？他們還缺乏些什麼？兩個方面-交流，以及交流的結果-組織。他們無法互相交談，從而無法合作。合作無法進行時，工作陷入了停頓。
團隊如何進行互相之間的交流溝通呢？通過所有可能的途徑：非正式途徑（清晰定義小組內部的互相關係和充分利用電話，能鼓勵大量的電話溝通，從而達到對所書寫文件的共同理解）、會議（常規專案會議，團隊一個接一個地進行簡要的技術陳述-澄清成百上千的細小錯誤）、工作手冊（不是一篇文件，它是對專案必須產出的一系列文件進行組織的一種結構）。
專案所有的文件都必須是該結構的一部分。這包括目的、外部規格說明、介面說明、技術標準、內部說明和管理備忘錄。需要正確的文件結構：事先將專案手冊設計好，能保證文件本身是規範的，而不是雜亂無章的。有了文件結構，後來書寫的文字就可以放置在合適的章節裡；使用專案手冊第二個原因是控制資訊釋出，並不是為限制資訊，而是確保資訊能到達所有需要它的人的手中。
專案手冊的第一步是對所有的備忘錄編號，從而每個工作人員可以通過標題列表來檢索是否有他所需要的資訊-也可以使用樹狀的索引結構。而且如果需要的話，可以使用樹結構中的子樹來維護髮佈列表。
工作手冊每個辦公室都有，實時更新，合頁夾的方式-微縮膠片，作為文字工作手冊的補充。
當程式設計人員僅瞭解自己負責的部分，而不是整個系統開發細節時，工作效率最高，此方法的先決條件是精確和完整地定義所有介面。一個好的資訊系統不但能暴露介面錯誤，還能有助於改正錯誤。
大型程式設計專案的組織架構：團隊組織的目的是減少所需的交流和合作的數量，因此良好的團隊組織是解決上述問題的關鍵措施。減少交流的方法是人力劃分和限定職責範圍。程式設計隊伍必須具備的基本要素：任務、產品負責人、技術主管或結構師、進度、人力劃分、各部分之間介面定義。團隊的搭配必須根據參與的人員來組織，而不是將人員純粹地按照理論進行安排。
產品負責人組建團隊，劃分工作及制定進度表。爭取並一直保證必要的資源。這意味著他主要的工作是與團隊外部進行向上的溝通和水平的溝通。他建立團隊內部的溝通和報告方式，他確保進度目標的實現，根據環境變化調整資源和團隊架構。
技術主管對設計進行構思，識別系統的子部分，指明從外部看上去的樣子，勾畫它的內部結構。他提供整個設計的一致性和概念完整性；他控制系統的複雜程度。當某個技術問題出現時，他提供解決問題的解決方案，或者根據需要調整系統設計-攻堅小組中的獨行俠。他的溝通交流在團隊中是首要的，他的工作幾乎完全是技術性的，溝通能力強。
產品負責人和技術主管是同一個人的實踐，一般3-6個開發人員。大型團隊不容易，同時具有管理技能和技術技能的人很難找到-思考者很少，實幹家更少；大型團隊每個角色都必須全職工作，甚至還要抽出時間進行技術工作。
產品負責人作為總指揮，技術主管充當其左右手-技術主管不參與任何管理工作不可能，建立在其技術權威。產品負責人必須預先宣告技術主管的技術權威，他們必須在主要的技術問題出現之前，私下先討論這些問題：產品責任人必須對技術主管的技術才能表現出尊重。一些技巧，微妙狀態特徵暗示體現主管微信。
技術主管作為總指揮，產品負責人充當其左右手。作者更傾向於產品負責人作為管理者更合適的安排。交流和交流的結果-組織，是成功的關鍵。交流和組織的技能需要管理者仔細考慮，相關經驗的積累和能力的提高同軟體技術本身一樣重要。
第八章 胸有成竹
編碼大約只佔問題的1/6左右，編碼估計或者比率的錯誤可能會導致不合理的荒謬結果。計劃、編制文件、測試、系統整合和培訓的時間必須被考慮在內。構建獨立小型程式的資料並不適合於程式設計系統產品。工作量＝常數*指令的數量1.5（工作量是規模的冪函式），儲存所使用時間的日誌-僅用50%的工作周來進行實際的程式設計和除錯，其餘的時間包括機器的宕機時間、高優先順序無關瑣碎工作、會議、文字工作、公司業務、疾病、事假等。專案估算對每個人年的技術工作時間數量做出了不現實的假設。
彙編：控制程式的生產率大約600-800（經過除錯的指令）/人年、語言翻譯小組生產率大約2000-3000/人年，包括小組計劃、程式碼構件測試、系統測試和一些支援性活動。生產率會根據任務本身複雜度和困難程度表現出顯著差異：編譯器複雜度是批處理程式的3倍，作業系統的複雜度是編譯器的3倍。系統中每個語句對應的手寫程式碼的3-5個指令！這意味著兩個重要的結論：對常用程式設計語句而言，生產率似乎是固定的。這個固定的生產率包括程式設計中需要註釋，並可能存在錯誤的情況；使用適當的高階語言，程式設計的生產率可以提高5倍。
第九章 削足適履
作為成本的程式空間，應該從整體上進行評價，沒有人可以自始至終提倡更緊密的軟硬體設計整合的同時，又僅僅就規模本身對軟體系統提出批評。規模是軟體系統產品使用者成本中的一個組成部分，開發人員必須設定規模的目標，控制規模，考慮減少規模的方法，不必要的規模是不可取的。
對專案經理而言，規模控制既是技術工作的一部分，也是管理工作的一部分。他必須研究使用者和使用者需求，以設定待開發系統的規模。由於規模-速度權衡方案的結果在很大範圍內變化，規模目標的設定是一件頗具技巧的事情，需要對每個可用方案有深刻的瞭解。聰明的專案經理還會給自己預留一些空間，在工作推行時分配。即使所有工作都完成得相當仔細，我們依然從中得到一些痛苦的教訓。
第一個教訓，僅對核心程式設定規模目標是不夠的，必須把所有方面規模都編入預算-記憶體或磁碟使用。在為每個單元設立核心規模的同時，我們沒有同時設定訪問的預算-單元核心未達到要求，會分解成覆蓋模組，增加了程式的整體規模，並降低了執行速度。
第二個教訓，每個模組分配功能前，已編制預算。導致任何在規模上碰到問題的程式設計師，會檢查已經的程式碼可否推給其他人。在指名模組有多大的同時，確切定義模組的功能。
第三個教訓，區域性優化導向和缺乏溝通是最大的危險。在整個實現過程中，系統結構師必須保持持續的警覺，確保連貫的系統完整性。除了監督機制外，是實現人員自身的態度問題-培養開發人員從系統整體出發、面向使用者的態度是軟體程式設計管理人員最重要的職能。
空間的預算和控制並不能使程式規模減少，為實現這一目標，需要一些創造性和技能。其中一個技巧是用功能交換尺寸：速度不變，更多功能需要更多空間，設計人員必須決定使用者可選專案的粗細程度。記憶體受限的後果是即使最精密的功能模組，它的適用範圍也難以得到推廣。第二個技能是考慮空間-時間的折衷：對於給定功能，空間越多，速度越快。
專案經理可以做兩件事來幫助他的團隊取得良好的空間-時間折衷。一是確保他們在程式設計技能上得到培訓，而不僅僅是依賴他們自己的才能和先前的經驗-特別是使用新語言或者新機器時，熟練使用往往需要快速學習和經驗的廣泛共享，也許它應該伴隨新技術特別的獎勵或者表揚。二是認識到程式設計需要技術積累，需要開發很多公共單元構件-每個專案要從能用於佇列、搜尋、雜湊和排序的例程或者巨集庫。對於每項功能，庫至少應該有兩個程式實現：執行速度較快和短小精煉的。上述的公共庫開發是一件重要的實現工作，它可以與系統設計工作並行進行。
資料的表現形式是程式設計的根本-精湛的技藝出自創造，精煉、充分和快速的程式都是如此。技藝改進的結果往往是戰略上的突破，不僅僅是技巧上的提高，比如新的演算法。戰略上突破通常來自資料或表的重新表達。由於缺乏空間而絞盡腦汁的程式設計人員，常常能通過從自己的程式碼中掙脫出來，回顧、分析實際情況，仔細思考程式的資料，最終獲得非常好的結果。實際上，資料的表現形式是程式設計的根本。
第十章 提綱挈領
每份文件的準備工作是集中考慮，並使各種討論意見明朗化的主要時刻。如果不是這樣，專案往往會處於無休止的混亂狀態，文件的跟蹤維護是專案監督和預警的機制。文件本身可以作為檢查列表、狀態控制，也可以作為彙報基礎。
如果要製造一臺機器，哪些是關鍵的文件？
目標：定義待滿足的目標和需要，定義迫切需要的資源、約束和優先順序；
技術說明：計算機手冊加效能規格說明，它是在計劃新產品時第一個產生，並且最後完成的文件。
進度
預算：不僅僅是約束，預算的存在會迫使技術決策的制定。否則技術決策很容易被忽略
組織結構圖
工作空間的分配
報價、預測、價格：這三個因素互相牽制，決定了專案的成敗。為了進行市場預測，首先需要制定產品效能說明和確定假設的價格。價格vs預測值，提高效能和支援更高的市場預測-成本必須降低以獲得更低的報價，這個迴圈的壓力常常是激勵市場人員和工程師工作的最佳動力。
大學科系的文件：目標、課程描述、學位要求、研究報告（申請基金需要計劃）、課程表和課程安排、預算、教室分配、教師和研究生助手的分配，任何管理任務關注焦點都是時間、地點、人員、專案內容和資金。
不論專案的規模大小，專案經理聰明的做法都是：首先立刻正式生成若干正式的小文件，以作為自己的資料基礎，然後再要求和其他經理類似的文件。標杆
內容：目標。定義待完成的目標、迫切需要的資源、約束和優先順序
內容：產品技術說明。以建議書開始，以使用者手冊和內部文件結束。速度和空間說明是關鍵的部分
時間：進度
資金：預算
地點：工作空間分配
人員：組織圖
為什麼要有正式的文件？第一，書面記錄決策是必要的-只有記錄下來，分歧才會明朗，矛盾才會突出-上百次細小決定答疑解惑。第二，溝通渠道，許多經理普遍認可的策略，完全不為團隊成員認知，專案經理的基本職責是使每個人都向著相同的方向前進，主要職責是溝通而不是決定。最後，文件可以作為基礎資料和檢查列表，通過週期性回顧，他能清楚專案所處的狀態，以及哪些重點需要進行更改和調整。
作者不太同意完全資訊管理系統，計算機輸入查詢就會有結果。一個原因是隻有一小部分管理人員的時間-可能只有20%，用來從自己頭腦外部獲取資訊。其他工作是溝通：傾聽、報告、講授、規勸、討論和鼓勵。不過，對於基於資料的部分，少數關鍵文件是至關重要的，可以滿足絕大多數需要。專案經理的任務是制定計劃，並實現計劃。但只有書面計劃是精確和可以溝通的。計劃中包括了時間、地點、人員、專案內容和資金。 通過一開始就遵循文件開展工作，專案經理更清晰和快速地設定自己的方向-將文件作為工具友好地利用起來。