人月神話
《人月神話：軟件項目管理之道》（英語：The Mythical Man-Month: Essays on Software Engineering）是由IBM System/360系統之父佛瑞德·布魯克斯所著經典文集，全書講解軟件工程、項目管理相關課題，被譽為軟件領域的聖經，內容源於作者布魯克斯在IBM公司System/360家族和OS/360中的項目管理經驗。其中的《沒有銀彈》在軟件行業引發了巨大反響。
本文基於清華大學出版社出版的40周年紀念版，譯者為UML China翻譯組的汪穎，出版日期為2015年4月，ISBN 978-7-302-39264-4。
第1章 焦油坑（The Tar Pit）
編輯- 史前史中，沒有別的場景比巨獸們中焦油坑中垂死掙扎的場面更令人震撼。上帝見證者恐龍、猛獁象、劍齒虎在焦油坑中掙扎。它們掙扎得越猛烈，焦油糾纏得就越緊，沒有哪種猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛，它們最後都沉到了坑底。
- 過去幾十年的大型系統開發就猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈掙扎。他們中大多數開發出了可運行的系統——不過只有極少數的項目滿足了目標、進度和預算的要求。各種團隊，大型的或小型的，龐雜的或精幹的，一個接一個地埋沒在了焦油坑中。表面上看起來好像沒有任何一個單獨的問題會導致困難，每個問題都能獲得解決，但是當它們相互糾纏和累積在一起的時候，團隊的行動就會變得越來越慢。
第2章 人月神話（The Mythical Man-Month）
編輯- 系統編程的進度安排背後的第一個錯誤的假設是：一切都將運作良好，每一項任務僅花費它所「應該」花費的時間。
- 用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示着人員數量和時間是可以相互替換的。
- 對於軟件任務的進度安排，以下是我使用了很多年的經驗法則：
- 1/3 計劃
- 1/6 編碼
- 1/4 構建測試和早起系統測試
- 1/4 系統測試，所有的構件已完成
- 向進度落後的項目中增加人手，只會使進度更加落後。
- Adding manpower to a late software project makes it later.
第3章 外科手術隊伍（The Surgical Team）
編輯- 需要協作的溝通人員數量影響着開發成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良後果（系統調試）。
- 絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本的、速度緩慢的、低效的，開發出的是無法在概念上進行集成的產品。
- 對於真正意義上的大型系統，小型精幹的隊伍太慢了。
- Mills建議大型項目的每一個部分由一個團隊解決，但是該隊伍以類似外科手術的方式組建，而不是一擁而上。也就是說，同每個成員截取問題某個部分的做法相反，由一個人來完成問題的分解，其他人給予他所需要的支持，以提高效率和生產力。
第4章 貴族專制、民主政治和系統設計（Aristocracy, Democracy, and System Design）
編輯- 在系統設計中，概念完整性應該是最重要的考慮因素。
- 由於目標是易用性（simplicity），功能與概念的複雜程度的比值才是系統設計的最終測試標準。單是功能本身或者簡潔都無法成為一個好的設計評判標準。
- 概念的完整性要求設計必須由一個人，或者非常少數互有默契的人員來實現。
- 對於非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法。
- 若要得到系統概念上的完整性，必須有人控制這些概念，這實際上是一種無需任何歉意的貴族專制統治。
- 有很多行業和領域中的案例讓人相信紀律和規則對行業是有益對。
- 外部的體系結構規定實際上是增強，而不是限制實現小組的創造性。
- 整個創造性活動包括了三個獨立的階段：體系結構（architecture）、設計實現（implementation）和物理實現（realization）。在實際情況中，它們往往可以同時開始和並發地進行。
第5章 畫蛇添足（The Second-System Effect）
編輯- 儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工。
- 想要成功，結構師必須：
- 牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配；
- 時刻準備着為所指定的說明建議一種實現的方法，同樣準備接受其他任何能達到目標的方法；
- 對上述的建議保持低調和不公開；
- 準備放棄堅持所作的改進建議。
- 第二個系統是設計師們所設計的最危險的系統。而當他着手第三個或第四個系統時，先前的經驗會相互驗證，得到對此類系統通用特性的判斷，而且系統之間的差異會幫助他識別出經驗中不夠通用的地方。
第6章 貫徹執行（Passing the Word）
編輯- 對實現人員而言，修改的階段化是很重要的——在進度表上應該有帶日期的版本信息。
- 規格說明的風格必須清晰、完整和準確。用戶常常會單獨提到某個定義，所以每條說明必須重複所有的基本要素，所有文字都要互相一致。
- 如果想保持文字和產品之間的一致性，則必須由一個或兩個人來完成將其結論轉換成書面規格說明的工作。
- 一句古老的格言警告說：「不要攜帶兩個時鐘出海，帶一個或三個。」同樣的原則也適用於形式化和記敘性定義。如果同時具有兩種方式，則必須以一種作為標準，另一種作為輔助描述，並照此明確地進行劃分。它們都可以作為表達的標準。
- 使用實現作為形式化定義特別容易引起混淆，特別是在程序化的仿真中。另外，當實現充當標準時，還必須防止對實現的任何修改。
- 直接整合[1]是一種強制推行軟件的結構性標準的方法。
- 如果起初至少有兩種以上的實現，那麼（體系結構）定義會更加整潔和規範。
- 對於存有疑問的實現人員，應鼓勵他們打電話[2]詢問相應的結構師，而不是一邊自行猜測一邊工作，這是一項很基本的措施。
- 上述問題的答案必須是可以告知每個人的權威性結論。
- 一種有用的機制是由結構師保存電話日誌。日誌中，他記錄了每一個問題和相應的回答。每周，對若干結構師的的日誌進行合併，重新整理，並分發給用戶和實現人員。
- 項目經理最好的朋友就是他每天要面對的對手——獨立的產品測試機構/小組。
- 設立測試小組是使設計決策得以貫徹執行的必要手段，同樣也是需要儘早着手，與設計同時實施的重要環節。
第7章 為什麼巴比倫塔會失敗（Why Did the Tower of Babel fail?）
編輯- 既然他們具備了所有的這些條件[3]，為什麼項目（巴比倫塔）還會失敗呢？他們還缺乏什麼？其缺乏兩個方面，其一是交流，其二是交流的結果——組織。
交流
編輯- 因為左手不知道右手在做什麼，所以進度緩慢、功能不合理和系統缺陷等問題紛紛出現。
- 團隊應該以儘可能多的方式進行相互之間的交流。
項目工作手冊
編輯- 項目工作手冊不是一篇獨立的文檔，它是對項目必須產出的一系列文檔進行組織的一種結構。
- 項目所有的文檔都必須是該結構的一部分。這包括目的、外部規格說明、接口說明、技術標準、內部說明和管理備忘錄。
- 正確的文檔結構非常重要。事先將項目工作手冊設計好，能保證文檔的結構本身是規範的，而不是雜亂無章的。另外，有了文檔結構，後來書寫的文字就可以放置在合適的章節中。
- 控制信息發佈並不是為了限制信息，而是確保信息能達到所有需要它的人的手中。
- 工作手冊的實時更新是非常關鍵的。工作手冊必須是最新的。
- 工作手冊的使用者應該將注意力集中在上次閱讀後的變更以及關於這些變更重要性的論述上。
- （David Lorge Parnas認為）當編程人員僅了解自己負責的部分，而不是整個系統的開發細節時，工作效率最高。
- 這種方法的先決條件是精確、完整地定義所有接口。如果能處理得好，的確是能解決很多「災難」。一個好的信息系統不但能暴露接口錯誤，還能有助於改正錯誤。
團隊組織
編輯- 團隊組織的目的是減少所需的交流和合作的數量。
- 樹狀結構幾乎不能用來描述交流溝通，因為交流是通過網狀結構進行的。
- 存在三種可能的關係，它們都在實踐中得到了成功的應用：
- 產品負責人和技術主管是同一個人。
- 產品負責人作為總指揮，技術主管充當其左右手。
- 技術主管作為總指揮，產品負責人充當其左右手。
第8章 胸有成竹（Calling the Shot）
編輯第9章 削足適履（Ten Pounds in a Five-Pound Sack）
編輯第10章 提綱挈領（The Documentary Hypothesis）
編輯第11章 未雨綢繆（Plan to Throw One Away）
編輯第12章 干將莫邪（Sharp Tools）
編輯第13章 整體部分（The Whole and the Parts）
編輯第14章 禍起蕭牆（Hatching a Catastrophe）
編輯第15章 另外一面（The Other Face）
編輯第16章 沒有銀彈——軟件工程中的根本和次要問題（No Silver Bullet - Essence and Accident in Software Engineering）
編輯- 在所有恐怖民間傳說的妖怪中，最可怕的是人狼，因為它們可以完全出乎意料地從熟悉的面孔變成可怕的怪物。為了對付人狼，我們在尋找可以消滅它們的銀彈。
- 沒有任何技術上或管理上的進展，能夠獨立地許諾在生產率、可靠性或簡潔性上取得數量級的提高。
第17章 再論「沒有銀彈」（"No Silver Bullet" Refired）
編輯註釋
編輯外部連結
編輯
