中國科學技術大學 李根 原創作品版權所有轉載請注明出處
正如計算機算法書籍中有《算法導論》這樣的聖經讀本一樣，軟體書籍中同樣具有深遠影響力和經久不衰的著作《人月神話》，此書堪稱軟體領域的聖經。《人月神話》由IBM System/360系統之父Frederick Brooks所著。這本書并不側重向從事軟體行業的人員展示高超的程式設計技術，也不涉及任何軟體設計模式和程式設計語言，而是通過作者豐富的項目經驗，分析軟體特性及開發過程中的人員安排，進度管理等方面的内容。值得一說的是，與我以往閱讀過的有關軟體開發和項目管理的書籍不同，這本書完全不走“軟體工程政治書”這一老路，避開軟體工程上的規範束縛，不至于使讀者昏昏欲睡，進而給讀者耳目一新的感覺。縱觀全書，作者總是先提出問題，然後給出解決方案及适用範圍，接着指出其方法的局限性，産生了怎樣的後果，最後總結教訓。
這本書給我的感覺就是“驚豔”二字，很多兼具系統性和理論性的歸納我還是第一次看到。由于篇幅有限，隻簡要談談我感興趣的幾個論述。本書開篇就将在軟體開發過程中遇到的困難形象地比作“焦油坑”，一旦整個團隊因為預期目标、時間進度、預算等問題陷入焦油坑，開發人員所做的各種補救措施很難突破現有的困境。
★ 從焦油坑說起
何謂焦油坑？
軟體項目開發過程中，表面上看起來沒有任何一個單獨的問題會導緻困難，每個問題好像都能被解決，但是當它們互相糾纏和積累在一起的時候，團隊的行動就會變得越來越慢。是以，互相糾纏和積累的困難就是焦油坑。作者的目的就是盡可能地幫助大型系統開發人員走出焦油坑。那麼，在大型系統開發過程中，到底有哪些焦油坑呢？
★ 焦油坑之一：進度滞後
在衆多軟體項目中，缺乏合理的時間進度是造成項目滞後的最主要原因，它比其他所有因素加起來的影響還大。就拿微軟當年的作業系統Windows 2000來說，負責這個項目的團隊計劃用三年的時間就可以開發出這個系統，可事實上前前後後一共用了五年的時間才開發完成。微軟作為全球軟體行業的“金融寡頭”尚且不能保證它的項目均按計劃好的時間進度完成，何況小型的軟體開發公司。可見，項目的估計和進度的安排是一門值得深究的學問。導緻項目進度滞後有以下原因：
● 樂觀主義的盛行
所有的程式設計人員都是樂觀主義者。為什麼這麼說呢？在程式員看來，計算機程式設計就是一份簡單的活兒，因為它基于非常容易掌握的媒體，通過非常純粹的思維活動就能控制整個開發過程。某種程度上，正由于媒體的易于駕馭，造成了樂觀主義的彌漫。天真的程式員每次找出一個bug之後，潛意識裡總是抱有這樣的想法：“這次它肯定會運作”或者“我剛剛找出了最後一個錯誤”。但是他們忽略了一個重要事實：Bug無處不在。
● 人月神話
在這裡，我們把“人月神話”作為導緻進度滞後的原因之一，而作者卻把其作為本書的書名，豈不是辱沒了這本經典著作？到底人月代表什麼？神話真的是關于人和月的傳奇故事嗎？聽我慢慢道來：
何謂人月？
人，指的是參與軟體開發的人員數量；月，指的是開發軟體所花費的時間，可以引申為進度。
何謂神話？
“神話”，本是莫須有的，這是Brooks為突出“人員數量和時間是可以互相替換的”這一具有誤導性的觀點而引入的。Brooks認為用人月來衡量一項工作的規模是一個危險和帶有欺騙性的神話，它暗示着人手和進度是可以互相替換的。
※ 為什麼不能簡單地認為人月是可以互相轉換的呢？
▲ 任務可以分解，并且子任務之間不需要互相交流，隻有這種情況下人月才可以互相轉換（實際開發中幾乎不可能）：
▲ 任務可以分解，并且子任務之間需要互相交流，但交流時間小于任務分解節省下來的時間：
▲ 任務可以分解，并且子任務之間需要互相交流，但交流時間完全抵消任務分解節省下來的時間，甚至交流時間随着人手的增加以(n-1)*n/2的規模遞增：
綜上，人月是一個非常具有迷惑性的概念，從事軟體開發的人員對此要有深刻的認識。事實上，作者把“人月神話”作為書名，意在告誡各位下面這個法則：
Brooks法則：向進度落後的項目中增加人手，隻會使進度更加落後。
● 各項任務的測試時間安排不當
由于程式設計者的樂觀主義，實際出現的缺陷數量比預想的要多得多。是以，系統測試的安排常常是程式設計中最不合理的部分。我們真正開發項目時，很少有允許為測試配置設定一半時間的，但是大多數項目的測試實際上是花費了進度中一半的時間。在項目快完成的時候發生延遲，帶來的二次成本遠遠高于其他開銷。是以，在前期進度策劃時，允許充分的系統測試時間是很有必要的。
● 迫于使用者壓力制定了空泛的進度計劃
為了滿足顧客期望的日期而制定不合理的進度安排，但緊迫的計劃進度無法控制實際的完成情況。就像是至少要花費兩分鐘才能煎好一個雞蛋，但顧客要求在兩分鐘之内吃到雞蛋，那麼要麼生吃煎蛋，要麼開大火煎燒，結果導緻一面已經燒焦，而另一面卻是生的。
■ 進度滞後項目的解決方案
⊙ 在新的進度安排中配置設定充裕的時間，確定工作能保質按量地完成。
⊙ 當項目延期造成後續成本很高時，往往削減系統的功能是唯一的解決方法。
★ 焦油坑之二：缺乏溝通
● 巴比倫塔為什麼會失敗？
巴比倫塔有着良好的先決條件：清晰的目标，充足的人力，豐富的泥土、瀝青等材料，充裕的時間，超高的建築技術；但是，最終還是難逃失敗的厄運。究其原因，建造它的部落缺乏有效的交流溝通，遇到困難他們選擇了争辯、猜忌、互相推卸責任，最後部落隻能分裂，不了了之。
● 大型程式設計項目中的交流
随着工作的展開，某些小組也許會逐漸修改自己程式的功能、規模，例如更改了一些輸入輸出用法上的約定，那麼整個團隊如何進行交流溝通呢？可以通過以下途徑：
·成員之間經常開展非正式性的讨論
·定期召開項目會議
·準備正式的項目工作手冊
● 樹狀組織架構
假設開發團隊中有n個人，則有（n*n- n）/ 2個互相交流的接口，是以必須減少不必要的交流及合作。樹狀組織架構使用人力劃分和職責限定可以有效減少溝通成本。其基本原理是利用管理角色的非重複性，同時每棵子樹需要定義如下基本要素：
·每棵子樹需要完成的任務
·子樹的産品負責人（對外溝通）
·子樹的技術主管（對内技術指導）
·進度
·人員的劃分
·子樹對外接口的定義
■ 由巴比倫塔想到的？
巴比倫塔也許是第一個工程上的徹底失敗，但它絕不是最後一個。它的失敗具有深刻的教育意義：項目管理人員要清醒認識到交流群組織的技能的重要性，相關經驗的積累和能力的提高同軟體技術本身同樣重要。
★ 銀彈之争：是否存在終極利器？
● 人狼、銀彈與軟體項目
何謂人狼？
人狼，指滿月時會由人形變成狼形的怪獸，它可以出乎意料地從熟悉的面孔變成可怕的怪物。
何謂銀彈？
銀彈，指惟一可以殺死人狼的武器。為了對付人狼，我們必須尋找能夠消滅它們的銀彈。
重新定位熟知的軟體項目？
軟體項目：具有一些人狼的特性，常常看似簡單明了的東西，卻有可能變成一個落後進度、超出預算、存在大量缺陷的怪物。
● 沒有銀彈
Brooks于1986年發表了《沒有銀彈》一文，Brooks斷定，沒有任何技術或管理上的進展，能夠獨立地許諾十年内使生産率、可靠性或簡潔性獲得數量級上的進步。時至今日，早過了Brooks設定的十年期限，到目前為止依然沒有找到能夠殺死軟體的銀彈。然而，《沒有銀彈》引發了衆多的辯論，甚至至今還在延續。
Brooks的高明之處就是将發現銀彈的困難分成根本的和次要的，而根本困難是決定是否有銀彈的關鍵。
·根本困難在于軟體系統存在無法規避的内在特性：複雜度、一緻性、可變性和不可見性。
·次要部分少于整個開發工作的9/10，那麼即使不占用任何時間，也不會給生産率帶來數量級的提高。是以，必須着手解決開發的根本問題。
● 存在銀彈
計算機學、社會學大師，Objective-C的開發者Cox認為,在資訊化社會裡，市場對資訊的巨大需求将成為經濟誘因，促使銀彈的出現。（個人認為，市場需求引發的經濟誘因再強大，還是不能從根本上解決軟體本身的内在特性。）
■ 未來銀彈能否找到？
大家都知道，資本主義社會内部存在不可調和的沖突，哪怕資本主義經濟水準再高，市場需求引發的經濟誘因再強大，都不可能令這種沖突消亡；這種沖突是資本主義社會本身固有的産物，隻有資本主義社會不存在了，這種不可調和的沖突才會消亡。正如同資本主義社會一樣，軟體本身也存在這種“沖突”——根本困難，是以，我覺得找到銀彈的願望是美好的，過程是艱難的，結果是不可能的。當然，這隻是我的愚見。
☆ 結束之語
這本書通讀下來，絲毫不覺枯燥乏味，書中一個個醍醐灌頂的論斷和描述，使得我對軟體特性、項目管理、團隊合作與溝通交流有了一定的了解，但由于大型項目經驗不足，對不少觀點的了解不免膚淺，今後參加過大的項目再讀此書，一定會了解得更加透徹。