人月神話
目錄
第1章 焦油坑
1.1 編程系統產品（Programming Systems Product）開發的工作量是供個人使用的、獨立開發的構件程序的九倍。我估計軟件構件產品化引起了3倍工作量，將軟件構件整合成完整系統所需要的設計、集成和測試又強加了3倍的工作量，這些高成本的構件在根本上是相互獨立的。
1.2 編程行業“滿足我們內心深處的創造渴望和愉悅所有人的共有情感”，提供了五種樂趣： 創建事物的快樂
l
l 開發對其他人有用的東西的樂趣
l 將可以活動、相互齧合的零部件組裝成類似迷宮的東西，這個過程所體現出令人神魂顛倒的魅力
l 面對不重複的任務，不間斷學習的樂趣
l 工作在如此易於駕馭的介質上的樂趣——純粹的思維活動，其存在、移動和運轉方式完全不同於實際物體
1.3 同樣，這個行業具有一些內在固有的苦惱：
l 將做事方式調整到追求完美，是學習編程的最困難部分
l 由其他人來設定目標，並且必須依靠自己無法控制的事物（特別是程序）；權威不等同於責任
l 實際情況看起來要比這一點好一些：真正的權威來自於每次任務的完成
l 任何創造性活動都伴隨着枯燥艱苦的勞動，編程也不例外
l 人們通常期望項目在接近結束時，（bug、工作時間）能收斂得快一些，然而軟件項目的情況卻是越接近完成，收斂得越慢
l 產品在即將完成時總面臨着陳舊過時的威脅
第2章 人月神話
2.1 缺乏合理的時間進度是造成項目滯後的最主要原因，它比其他所有因素加起來影響還大。
2.2 良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快
速度。
2.3 所有的編程人員都是樂觀主義者：“一切都將運作良好”。
2.4 由於編程人員通過純粹的思維活動來開發，所以我們期待在實現過程中不會碰到困難。
2.5 但是，我們的構思是有缺陷的，因此總會有bug。
2.6 我們圍繞成本覈算的估計技術，混淆了工作量和項目進展。人月是危險和帶有欺騙性的神話，因爲它暗示人員數量和時間是可以相互替換的。
2.7 在若干人員中分解任務會引發額外的溝通工作量——培訓和相互溝通。
2.8 關於進度安排，我的經驗是爲1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。
2.9 作爲一個學科，我們缺乏數據估計。
2.10 因爲我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。
2.11 Brook法則：向進度落後的項目中增加人手，只會使進度更加落後。
2.12 向軟件項目中增派人手從三個方面增加了項目必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。
第3章 外科手術隊伍
3.1 同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程序員的工作效率是較差程序員的十倍。（Sackman、Erikson和Grand）
3.2 Sackman、Erikson和Grand的數據顯示經驗和實際表現之間沒有相互聯繫。我懷疑這種現象是否普遍成立。
3.3 小型、精幹隊伍是最好的——儘可能的少。
3.4 兩個人的團隊，其中一個項目經理，常常是最佳的人員使用方法。[留意一下上帝對婚姻的設計。]
3.5 對於真正意義上的大型系統，小型精幹的隊伍太慢了。
3.6 實際上，絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的集成。
3.7 一位首席程序員、類似於外科手術隊伍的團隊架構提供了一種方法——既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。
第4章 貴族專制、民主政治和系統設計
4.1 “概念完整性是系統設計中最重要的考慮因素”。
4.2 “功能與理解上的複雜程度的比值纔是系統設計的最終測試標準”，而不僅僅是豐富的功能。[該比值是對易用性的一種測量，由簡單和複雜應用共同驗證。]
4.3 爲了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊來完成。
4.4 “對於非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。”[同樣適用於小型項目。]
4.5 “如果要得到系統概念上的完整性，那麼必須控制這些概念。這實際上是一種無需任何歉意的貴族專制統治。”
4.6 紀律、規則對行業是有益的。外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。
4.7 概念上統一的系統能更快地開發和測試。
4.8 體系結構（architecture）、設計實現（implementation）、物理實現（realization）的許多工作可以併發進行。[軟件和硬件設計同樣可以並行。]
第5章 畫蛇添足
5.1 儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。
5.2 結構師如何成功地影響實現：
l 牢記是開發人員承擔創造性的實現責任；結構師只能提出建議。
l 時刻準備着爲所指定的說明建議一種實現的方法，準備接受任何其他可行的方法。
l 對上述的建議保持低調和平靜。
l 準備對所建議的改進放棄堅持。
l 聽取開發人員在體系結構上改進的建議。
5.3 第二個系統是人們所設計的最危險的系統，通常的傾向是過分地進行設計。
5.4 OS/360是典型的畫蛇添足（second-system effect）的例子。[Windows NT似乎是90年代的例子。]
5.5 爲功能分配一個字節和微秒的優先權值是一個很有價值的規範化方法。
第6章 貫徹執行
6.1 即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
6.2 必須明確定義體系結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。
6.3 出於精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。
6.4 必須採用形式化定義和記敘性定義中的一種作爲標準，另一種作爲輔助措施；它們都可以作爲表達的標準。
6.5 設計實現，包括模擬仿真，可以充當一種形式化定義的方法；這種方法有一些嚴重的缺點。
6.6 直接整合是一種強制推行軟件的結構性標準的方法。[硬件上也是如此——考慮內建在ROM中的Mac WIMP接口。]
6.7 “如果起初至少有兩種以上的實現，那麼（體系結構）定義會更加整潔，會更加規範。”
6.8 允許體系結構師對實現人員的詢問做出電話應答解釋是非常重要的，並且必須進行日誌記錄和整理髮布。[電子郵件是一種可選的介質。]
6.9 “項目經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。”
第7章 爲什麼巴比倫塔會失敗？
7.1 巴比倫塔項目的失敗是因爲缺乏交流，以及交流的結果——組織。
交流
7.2 “因爲左手不知道右手在做什麼，從而進度災難、功能的不合理和系統缺陷紛紛出現。”由於對其他人的各種假設，團隊成員之間的理解開始出現偏差。
7.3 團隊應該以儘可能多的方式進行相互之間的交流：非正式、常規項目會議，會上進行簡要的技術陳述、共享的正式項目工作手冊。[以及電子郵件。]
項目工作手冊
7.4 項目工作手冊“不是獨立的一篇文檔，它是對項目必須產生的一系列文檔進行組織的一種結構。”
7.5 “項目所有的文檔都必須是該（工作手冊）結構的一部分。”
7.6 需要儘早和仔細地設計工作手冊結構。
7.7 事先制訂了良好結構的工作手冊“可以將後來書寫的文字放置在合適的章節中”，並且可以提高產品手冊的質量。
7.8 “每一個團隊成員應該瞭解所有的材料（工作手冊）。”[我想說的是，每個團隊成員應該能夠看到所有材料，網頁即可滿足要求。]
7.9 實時更新是至關重要的。
7.10 工作手冊的使用者應該將注意力集中在上次閱讀後的變更，以及關於這些變更重要性的評述。
7.11 OS/360項目工作手冊開始採用的是紙介質，後來換成了微縮膠片。
7.12 今天[即使在1975年]，共享的電子手冊是能更好達到所有這些目標、更加低廉、更加簡單的機制。
7.13 仍然需要用變更條和修訂日期[或具備同等功能的方法]來標記文字；仍然需要後進先出（LIFO）的電子化變更小結。
7.14 Parnas強烈地認爲使每個人看到每件事的目標是完全錯誤的；各個部分應該被封裝，從而沒有人需要或者允許看到其他部分的內部結構，只需要瞭解接口。
7.15 Parnas的建議的確是災難的處方。[Parnas讓我認可了該觀點，使我徹底地改變了想法。]
組織架構
7.16 團隊組織的目標是爲了減少必要的交流和協作量。
7.17 爲了減少交流，組織結構包括了人力劃分（division of labor）和限定職責範圍（specialization of function）。
7.18 傳統的樹狀組織結構反映了權力的結構原理——不允許雙重領導。
7.19 組織中的交流是網狀，而不是樹狀結構，因而所有的特殊組織機制（往往體現成組織結構圖中的虛線部分）都是爲了進行調整，以克服樹狀組織結構中交流缺乏的困難。
7.20 每個子項目具有兩個領導角色——產品負責人、技術主管或結構師。這兩個角色的職能有着很大的區別，需要不同的技能。
7.21 兩種角色中的任意組合可以是非常有效的：
l 產品負責人和技術主管是同一個人。
l 產品負責人作爲總指揮，技術主管充當其左右手。
l 技術主管作爲總指揮，產品負責人充當其左右手。
第8章 胸有成竹
8.1 僅僅通過對編碼部分的估計，然後乘以任務其他部分的相對係數，是無法得出對整項工作的精確估計的。
8.2 構建獨立小型程序的數據不適用於編程系統項目。
8.3 程序開發呈程序規模的指數增長。
8.4 一些發表的研究報告顯示指數約爲1.5。[Boehm的數據並不完全一致，在1.05和1.2之間變化。1]
8.5 Portman的ICL數據顯示相對於其他活動開銷，全職程序員僅將50％的時間用於編程和調試。
8.6 IBM的Aron數據顯示，生產率是系統各個部分交互的函數，在1.5K千代碼行/人年至10K千代碼行/人年的範圍內變化。
8.7 Harr的Bell實驗室數據顯示對於已完成的產品，操作系統類的生產率大約是0.6KLOC/人年，編譯類工作的生產率大約爲2.2KLOC/人年。
8.8 Brooks的OS/360S數據與Harr的數據一致：操作系統0.6～0.8KLOC/人年，編譯器2～3 KLOC/人年。
8.9 Corbato的MIT項目MULTICS數據顯示，在操作系統和編譯器混合類型上的生產率是1.2KLOC/人年，但這些是PL/I的代碼行，而其他所有的數據是彙編代碼行。
8.10 在基本語句級別，生產率看上去是個常數。
8.11 當使用適當的高級語言時，程序編制的生產率可以提高5倍。
第9章 削足適履
9.1 除了運行時間以外，所佔據的內存空間也是主要開銷。特別是對於操作系統，它的很多程序是永久駐留在內存中。
9.2 即便如此，花費在駐留程序所佔據內存上的金錢仍是物有所值的，比其他任何在配置上投資的效果要好。規模本身不是壞事，但不必要的規模是不可取的。
9.3 軟件開發人員必須設立規模目標，控制規模，發明一些減少規模的方法——就如同硬件開發人員爲減少元器件所做的一樣。
9.4 規模預算不僅僅在佔據內存方面是明確的，同時還應該指明程序對磁盤的訪問次數。
9.5 規模預算必須與分配的功能相關聯；在指明模塊大小的同時，確切定義模塊的功能。
9.6 在大型的團隊中，各個小組傾向於不斷地局部優化，以滿足自己的目標，而較少考慮隊用戶的整體影響。這種方向性的問題是大型項目的主要危險。
9.7 在整個實現的過程期間，系統結構師必須保持持續的警覺，確保連貫的系統完整性。
9.8 培養開發人員從系統整體出發、面向用戶的態度是軟件編程管理人員最重要的職能。
9.9 在早期應該制訂策略，以決定用戶可選項目的粗細程度，因爲將它們作爲整體大包能夠節省內存空間。[常常還可以節約市場成本。]
9.10 臨時空間的尺寸，以及每次磁盤訪問的程序數量是很關鍵的決策，因爲性能是規模的非線性函數。[這個整體決策已顯得過時——起初是由於虛擬內存，後來則是成本低廉的內存。現在的用戶通常會購買能容納主要應用程序所有代碼的內存。]
9.11 爲了取得良好的空間－時間折衷，開發隊伍需要得到特定與某種語言或者機型的編程技能培訓，特別是在使用新語言或者新機器時。
9.12 編程需要技術積累，每個項目需要自己的標準組件庫。
9.13 庫中的每個組件需要有兩個版本，運行速度較快和短小精煉的。[現在看來有些過時。]
9.14 精煉、充分和快速的程序。往往是戰略性突破的結果，而不僅僅技巧上的提高。
9.15 這種突破常常是一種新型算法。
9.16 更普遍的是，戰略上突破常來自於數據或表的重新表達。數據的表現形式是編程的根本。
第10章 提綱挈領
10.1 “前提：在一片文件的汪洋中，少數文檔形成了關鍵的樞紐，每個項目管理的工作都圍繞着它們運轉。它們是經理們的主要個人工具。”
10.2 對於計算機硬件開發項目，關鍵文檔是目標、手冊、進度、預算、組織機構圖、空間分配、以及機器本身的報價、預測和價格。
10.3 對於大學科系，關鍵文檔類似：目標、課程描述、學位要求、研究報告、課程表和課程的安排、預算、教室分配、教師和研究生助手的分配。
10.4 對於軟件項目，要求是相同的：目標、用戶手冊、內部文檔、進度、預算、組織機構圖和工作空間分配。
10.5 因此，即使是小型項目，項目經理也應該在項目早期規範化上述的一系列文檔。
10.6 以上集合中每一個文檔的準備工作都將注意力集中在對討論的思索和提煉，而書寫這項活動需要上百次的細小決定，正是由於它們的存在，人們才能從令人迷惑的現象中得到清晰、確定的策略。
10.7 對每個關鍵文檔的維護提供了狀態監督和預警機制。
10.8 每個文檔本身就可以作爲檢查列表或者數據庫。
10.9 項目經理的基本職責是使每個人都向着相同的方向前進。
10.10 項目經理的主要日常工作是溝通，而不是做出決定；文檔使各項計劃和決策在整個團隊範圍內得到交流。
10.11 只有一小部分管理人員的時間——可能只有20%——用來從自己頭腦外部獲取信息。
10.12 出於這個原因，廣受吹捧的市場概念——支持管理人員的“完備信息管理系統”並不基於反映管理人員行爲的有效模型。
第11章 未雨綢繆
11.1 化學工程師已經認識到無法一步將實驗室工作臺上的反應過程移到工廠中，需要一個實驗性工廠（pilot planet）來爲提高產量和在缺乏保護的環境下運作提供寶貴經驗。
11.2 對於編程產品而言，這樣的中間步驟是同樣必要的，但是軟件工程師在着手發佈產品之前，卻並不會常規地進行試驗性系統的現場測試。[現在，這已經成爲了一項普遍的實踐，beta版本。它不同於有限功能的原型，alpha版本，後者同樣是我所倡導的實踐。]
11.3 對於大多數項目，第一個開發的系統並不合用。它可能太慢、太大，而且難以使用，或者三者兼而有之。
11.4 系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。這是個必須完成的步驟。
11.5 將開發的第一個系統——丟棄原型——發佈給用戶，可以獲得時間，但是它的代價高昂——對於用戶，使用極度痛苦；對於重新開發的人員，分散了精力；對於產品，影響了聲譽，即使最好的再設計也難以挽回名聲。
11.6 因此，爲捨棄而計劃，無論如何，你一定要這樣做。
11.7 “開發人員交付的是用戶滿意程度，而不僅僅是實際的產品。”（Cosgrove）
11.8 用戶的實際需要和用戶感覺會隨着程序的構建、測試和使用而變化。
11.9 軟件產品易於掌握的特性和不可見性，導致了它的構建人員（特別容易）面臨着永恆的需求變更。
11.10 目標上（和開發策略上）的一些正常變化無可避免，事先爲它們做準備總比假設它們不會出現要好得多。
11.11 爲變更計劃軟件產品的技術，特別是細緻的模塊接口文檔——非常地廣爲人知，但並沒有相同規模的實踐。儘可能地使用表驅動技術同樣是有所幫助的。[現在內存的成本和規模使這項技術越來越出衆。]
11.12 高級語言的使用、編譯時操作、通過引用的聲明整合和自文檔技術能減少變更引起的錯誤。
11.13 採用定義良好的數字化版本將變更量子（階段）化。[當今的標準實踐。]
爲變更計劃組織架構
11.14 程序員不願意爲設計書寫文檔的原因，不僅僅是由於惰性。更多的是源於設計人員的躊躇——要爲自己嘗試性的設計決策進行辯解。（Cosgrove）
11.15 爲變更組建團隊比爲變更進行設計更加困難。
11.16 只要管理人員和技術人才的天賦允許，老闆必須對他們的能力培養給予極大的關注，使管理人員和技術人才具有互換性；特別是希望能在技術和管理角色之間自由地分配人手的時候。
11.17 具有兩條晉升線的高效組織機構，存在着一些社會性的障礙，人們必須警惕和積極地同它做持續的鬥爭。
11.18 很容易爲不同的晉升線建立相互一致的薪水級別，但要同等威信的建立需要一些強烈的心理措施：相同的辦公室、一樣的支持和技術調動的優先補償。
11.19 組建外科手術隊伍式的軟件開發團隊是對上述問題所有方面的徹底衝擊。對於靈活組織架構問題，這的確是一個長期行之有效的解決方案。
前進兩步，後退一步——程序維護
11.20 程序維護基本上不同於硬件的維護；它主要由各種變更組成，如修復設計缺陷、新增功能、或者是使用環境或者配置變換引起的調整。
11.21 對於一個廣泛使用的程序，其維護總成本通常是開發成本的40％或更多。
11.22 維護成本受用戶數目的嚴重影響。用戶越多，所發現的錯誤也越多。
11.23 Campbell指出了一個顯示產品生命期中每月bug數的有趣曲線，它先是下降，然後攀升。
11.24 缺陷修復總會以（20－50）%的機率引入新的bug。
11.25 在每次修復之後，必須重新運行先前所有的測試用例，從而確保系統不會以更隱蔽的方式被破壞。
11.26 能消除、至少是能指明副作用的程序設計方法，對維護成本有很大的影響。
11.27 同樣，設計實現的人員越少、接口越少，產生的錯誤也就越少。
前進一步，後退一步——系統熵隨時間增加
11.28 Lehman和Belady發現模塊數量隨大型操作系統（OS/360）版本號的增加呈線性增長，但是受到影響的模塊以版本號指數的級別增長。
11.29 所有修改都傾向於破壞系統的架構，增加了系統的混亂程度。即使是最熟練的軟件維護工作，也只是放緩了系統退化到不可修復混亂的進程，從中必須要重新進行設計。[許多程序升級的真正需要，如性能等，尤其會衝擊它的內部結構邊界。原有邊界引發的不足常常在日後纔會出現。]
第12章 干將莫邪
12.1 項目經理應該制訂一套策略，以及爲通用工具的開發分配資源，與此同時，他還必須意識到專業工具的需求。
12.2 開發操作系統的隊伍需要自己的目標機器，進行調試開發工作。相對於最快的速度而言，它更需要最大限度的內存，還需要安排一名系統程序員，以保證機器上的標準軟件是即時更新和實時可用的。
12.3 同時還需要配備調試機器或者軟件，以便在調試過程中，所有類型的程序參數可以被自動計數和測量。
12.4 目標機器的使用需求量是一種特殊曲線：剛開始使用率非常低，突然出現爆發性的增長，接着趨於平緩。
12.5 同天文工作者一樣，系統調試總是大部分在夜間完成。
12.6 拋開理論不談，一次分配給某個小組連續的目標時間塊被證明是最好的安排方法，比不同小組的穿插使用更爲有效。
12.7 儘管技術不斷變化，這種採用時間塊來安排匱乏計算機資源的方式仍得以延續20年[在1975年]，是因爲它的生產率最高。[在1995年依然如此]
12.8 如果目標機器是新產品，則需要一個目標機器的邏輯仿真裝置。這樣，可以更快地得到輔助調試平臺。即使在真正機器出現之後，仿真裝置仍可提供可靠的調試平臺。
12.9 主程序庫應該被劃分成（1）一系列獨立的私有開發庫；（2）正處在系統測試下的系統集成子庫；（3）發佈版本。正式的分離和進度提供了控制。
12.10 在編制程序的項目中，節省最大工作量的工具可能是文本編輯系統。
12.11 系統文檔中的巨大容量帶來了新的不理解問題[例如，看看Unix]，但是它比大多數未能詳細描述編程系統特性的短小文章更加可取。
12.12 自頂向下、徹底地開發一個性能仿真裝置。儘可能早地開始這項工作，仔細地聽取 “它們表達的意見”。
高級語言
12.13 只有懶散和惰性會妨礙高級語言和交互式編程的廣泛應用。[如今它們已經在全世界使用。]
12.14 高級語言不僅僅提升了生產率，而且還改進了調試：bug更少，以及更容易尋找。
12.15 傳統的反對意見——功能、目標代碼的尺寸、目標代碼的速度，隨着語言和編譯器技術的進步已不再成爲問題。
12.16 現在可供合理選擇的語言是PL/I。[不再正確。]
交互式編程
12.17 某些應用上，批處理系統決不會被交互式系統所替代。[依然成立。]
12.18 調試是系統編程中很慢和較困難的部分，而漫長的調試周轉時間是調試的禍根。
12.19 有限的數據表明了系統軟件開發中，交互式編程的生產率至少是原來的兩倍。
第13章 整體部分
13.1 第4、5、6章所意味的煞費苦心、詳盡體系結構工作不但使產品更加易於使用，而且使開發更容易進行以及bug更不容易產生。
13.2 V.A.Vyssotsky提出，“許許多多的失敗完全源於那些產品未精確定義的地方。”
13.3 在編寫任何代碼之前，規格說明必須提交給測試小組，以詳細地檢查說明的完整性和明確性。開發人員自己不會完成這項工作。（Vyssotsky）
13.4 “十年內[1965～1975]，Wirth的自頂向下進行設計[逐步細化]將會是最重要的新型形式化軟件開發方法。”
13.5 Wirth主張在每個步驟中，儘可能使用級別較高的表達方法。
13.6 好的自頂向下設計從四個方面避免了bug。
13.7 有時必須回退，推翻頂層設計，重新開始。
13.8 結構化編程中，程序的控制結構僅由支配代碼塊（相對於任意的跳轉）的給定集合所組成。這種方法出色地避免了bug，是一種正確的思考方式。
13.9 Gold結果顯示了，在交互式調試過程中，第一次交互取得的工作進展是後續交互的三倍。這實際上獲益於在調試開始之前仔細地調試計劃。[我認爲在1995年依然如此。]
13.10 我發現對良好終端系統的正確使用，往往要求每兩小時的終端會話對應於兩小時的桌面工作：1小時會話後的清理和文檔工作；1小時爲下一次計劃變更和測試。
13.11 系統調試（相對於單元測試）花費的時間會比預料的更長。
13.12 系統調試的困難程度證明了需要一種完備系統化和可計劃的方法。
13.13 系統調試僅僅應該在所有部件能夠運作之後開始。（這既不同於爲了查出接口bug所採取 “合在一起嘗試” 的方法；也不同於在所有構件單元的bug已知，但未修復的情況下，即開始系統調試的做法。）[對於多個團隊尤其如此。]
13.14 開發大量的輔助調試平臺（scaffolding 腳手架）和測試代碼是很值得的，代 碼量甚至可能會有測試對象的一半。
13.15 必須有人對變更進行控制和文檔化，團隊成員應使用開發庫的各種受控拷貝來工作。
13.16 系統測試期間，一次只添加一個構件。
13.17 Lehman和Belady出示了證據，變更的階段（量子）要麼很大，間隔很寬；要麼小和頻繁。後者很容易變得不穩定。[Microsoft的一個團隊使用了非常小的階段（量子）。結果是每天晚上需要重新編譯生成增長中的系統。]
第14章 禍起蕭牆
14.1 “項目是怎樣延遲了整整一年的時間？⋯一次一天。”
14.2 一天一天的進度落後比起重大災難，更難以識別、更不容易防範和更加難以彌補。
14.3 根據一個嚴格的進度表來控制項目的第一個步驟是制訂進度表，進度表由里程碑和日期組成。
14.4 里程碑必須是具體的、特定的、可度量的事件，能進行清晰能定義。
14.5 如果里程碑定義得非常明確，以致於無法自欺欺人時，程序員很少會就里程碑的進展弄虛作假。
14.6 對於大型開發項目中的估計行爲，政府的承包商所做的研究顯示：每兩週進行仔細修訂的活動時間估計，隨着開始時間的臨近不會有太大的變化；期間內對時間長短的過高估計，會隨着活動的進行持續下降；過低估計直到計劃的結束日期之前大約三週左右，纔有所變化。
14.7 慢性進度偏離是士氣殺手。[Microsoft的Jim McCarthy說：“如果你錯過了一個最終期限（deadline），確保制訂下一條deadline。2”]
14.8 進取對於傑出的軟件開發團隊，同優秀的棒球隊伍一樣，是不可缺少的必要品德。
14.9 不存在關鍵路徑進度的替代品，使人們能夠辨別計劃偏移的情況。
14.10 PERT的準備工作是PERT圖使用中最有價值的部分。它包括了整個網狀結構的展開、任務之間依賴關係的識別、各個任務鏈的估計。這些都要求在項目早期進行非常專業的計劃。
14.11 第一份PERT圖總是很恐怖的，不過人們總是不斷進行努力，運用才智制訂下一份PERT圖。
14.12 PERT圖爲前面那個泄氣的藉口，“其他的部分反正會落後”，提供了答案。
14.13 每個老闆同時需要採取行動的異常信息以及用來進行分析和早期預警的狀態數據。
14.14 狀態的獲取是困難的，因爲下屬經理有充分的理由不提供信息共享。
14.15 老闆的不良反應肯定會對信息的完全公開造成壓制；相反，仔細區分狀態報告、毫無驚慌地接收報告、決不越俎代庖，將能鼓勵誠實的彙報。
14.16 必須有評審的機制，從而所有成員可以通過它瞭解真正的狀態。出於這個目的，里程碑的計劃和完成文檔是關鍵。
14.17 Vyssotsky：我發現在里程碑報告中很容易記錄“計劃（老闆的日期）”和“估計（最基層經理的日期）”的日期。項目經理必須停止對這些日期的懷疑。”
14.18 對於大型項目，一個對里程碑報告進行維護的計劃和控制（Plan and Control）小組是非常可貴的。
第15章 另外一面
15.1 對於軟件編程產品來說，程序向用戶所呈現的面貌與提供給機器識別的內容同樣重要。
15.2 即使對於完全開發給自己使用的程序，描述性文字也是必須的，因爲它們會被用戶－作者所遺忘。
15.3 培訓和管理人員基本上沒有能向編程人員成功地灌輸對待文檔的積極態度——文檔能在整個生命週期對克服懶惰和進度的壓力起促進激勵作用。
15.4 這樣的失敗並不都是因爲缺乏熱情或者說服力，而是沒能正確地展示如何有效和經濟地編制文檔。
15.5 大多數文檔只提供了很少的總結性內容。必須放慢腳步，穩妥地進行。
15.6 由於關鍵的用戶文檔包含了跟軟件相關的基本決策，所以它的絕大部分需要在程序編制之前書寫，它包括了9項內容。
1) 目的。主要的功能是什麼？開發程序的原因是什麼？
2) 環境。程序運行在什麼樣的機器、硬件配置和操作系統上？
3) 範圍。輸入的有效範圍是什麼？允許顯示的合法範圍是什麼？
4) 實現功能和使用的算法。精確地闡述它做了什麼。
5) 輸入－輸出格式。必須是確切和完整的。
6) 操作指令。包括控制檯及輸出內容中正常和異常結束的行爲。
7) 選項。用戶的功能選項有哪些？如何在選項之間進行挑選？
8) 運行時間。在指定的配置下，解決特定規模問題所需要的時間？
15.7 每一份發佈的程序拷貝應該包括一些測試用例，其中一部分用於校驗輸入數據，一部分用於邊界輸入數據，另一部分用於無效的輸入數據。
15.8 對於必須修改程序的人而言，他們所需要程序內部結構文檔，同樣要求一份清晰明瞭的概述，它包括了5項內容。
1) 流程圖或子系統的結構圖，對此以下有更詳細的論述。
2) 對所用算法的完整描述，或者是對文檔中類似描述的引用。
3) 對所有文件規劃的解釋。
4) 數據流的概要描述——從磁盤或者磁帶中，獲取數據或程序處理的序列——以及在每個處理過程完成的操作。
5) 初始設計中，對已預見修改的討論；特性、功能回調的位置以及出口；原作者對可能會擴充的地方以及可能處理方案的一些意見。另外，對隱藏缺陷的觀察也同樣很有價值。
15.9 流程圖是被吹捧得最過分的一種程序文檔。詳細逐一記錄的流程圖是一件令人生厭的事情，而且高級語言的出現使它顯得陳舊過時。（流程圖是圖形化的高級語言。）
15.10 如果這樣，很少有程序需要一頁紙以上的流程圖。[在這一點上，MILSPEC軍用標準實在錯得很厲害。]
15.11 即使的確需要一張程序結構圖，也並不需要遵照ANSI的流程圖標準。
15.12 爲了使文檔易於維護，將它們合併至源程序是至關重要的，而不是作爲獨立文檔進行保存。
15.13 最小化文檔負擔的3個關鍵思路：
l 藉助那些必須存在的語句，如名稱和聲明等，來附加儘可能多的“文檔”信息。
l 使用空格和格式來表現從屬和嵌套關係，提高程序的可讀性。
l 以段落註釋，特別是模塊標題的形式，向程序中插入必要的記敘性文字。
15.14 程序修改人員所使用的文檔中，除了描述事情如何以外，還應闡述它爲什麼那樣。對於加深理解，目的是非常關鍵的，但即使是高級語言的語法，也不能表達目的。
15.15 在線系統的高級語言（應該使用的工具）中，自文檔化技術發現了它的絕佳應用和強大功能。
原著結束語
E.1 軟件系統可能是人類創造中最錯綜複雜的事物（從不同類型組成部分數量的角度出發）。
E.2 軟件工程的焦油坑在將來很長一段時間內會繼續地使人們舉步維艱，無法自拔。