《人月神話》

一次豆豆式的書評嘗試

 

2002/10 劉天北 (liutb@ultract.com)
北京奧捷特通信技術有限公司技術總監


《人月神話 (The Mythical Man-Month)》是軟件行業中的一部里程碑式的名著。作者Brooks曾任IBM System/360項目經理,被稱為"S/360之父"。在書中,他詳細討論了包括工期規劃、團隊組成、文檔、排錯等軟件項目進行全程中的方方面面。本文考察了該書成功的原因,對書中涉及的若干重點問題做出了進一步分析,並展望了該書可能為中國軟件業帶來的啟示。


從尺寸說起

豆豆先生(Mr. Bean)讚許惠斯勒的《畫家母親的肖像》,首先談的一點就是:"這幅畫比較大(quite big),所以了不起(excellent)"。這種批評套路,中國古已有之:品茶時讚美 "熱得好" 就是。今天我們談談Brooks的《The Mythical Man-Month》(中譯為"人月神話",下簡稱MMM),也效法英國來的專家,從尺寸說起:這本書的一個突出優點,在於它比較小。

小有兩點,一是開本,一是頁數。尼采說,我的野心是用一句話說完別人十本書才能說清的事(他還加了一句--甚或是,十本書都說不清的事)。可是對於出版工業,這樣的野心家不要也罷。多數書長,還是因為所涉及的領域本身頭緒眾多,不過總可以用得上法國人的俏皮話:他沒有時間往短裡寫。把書寫短不是人人都可以辦到的,這需要良好的分寸感和結構感--都是很難在匆忙的IT從業者中找到的素質。是以一般技術書籍,多為人高馬大,卷帙繁浩(當然還有國內影印版的慣常做法,把原來的大開本縮印成小兄弟,但考慮到增加的閱讀難度,結果並沒有想象的那麼經濟)。"大",對於書--尤其是技術書--來說,不見得就"了不起"。以我個人的閱讀習慣,多於五百頁、開本又超過"大32開"的技術專著,那就只能當字典查,又好比皇宮裡的大齡宮女,偶一調情也可,若要三千寵愛集一身,不啻為非分之想。本來一卷在手,有如軟玉生香在抱,總以"輕"、"薄"為妙,若是龐然巨物,體態狼伉,未免讓人產生心理障礙(借此一角向通讀了《C++ Primer》的各位致意:你們都可以去做《大內密探零零發》裡艷福齊天的皇上)。眼下說的這本MMM,正是技術書中的趙飛燕,可作字面意義上的掌上舞:大32的開本,算上注釋、索引共332頁,要緊的是,每章前的大量篇幅留給題圖和題記, 19章下來,實在要讀的內容不到200頁。

如果決定讀這本書,你也許可以參照我個人的經驗做出時間預算:並非出於固定的讀書計劃,而是為了謀殺早晨巴士上的無聊時間,我選中了這本相貌可人、插圖眾多的MMM(它的前任似乎是袖珍本的斯各特船長傳)。在前一周的周日下午我興味盎然地覆蓋了書末的三章:後記("The MMM after 20 years")、作者著名的單篇論文《沒有銀彈(No Silver Bullet)》和《再論沒有銀彈(No Silver Bullet Refired)》;這之後,第1章以下的若干章大約以每次1章半到2章的速度平均分布在5次車中顛簸的早高峰時間(每次約35至40分鐘,並有一次坐過站);最後,一個睡眼惺忪的周六上午讓我完成了其餘部分--我沒法相信,這種"休閑"的閱讀形式适用於任何一本其他的技術"名著"(可能的例外是《Peopleware》,我們一會兒還會談到它)--或許你明早會帶上本《Planning XP》試試。

美味的分析

那麼,除了小,這書還有什麼好處?對,再就是:它比較好讀。我看書也純粹是"以貌取人",外表即是一切(法國人說:皮膚是人最深刻的部分)。就像飯菜, "好吃"就好,營養等等在我輩老饕看來,還是第二義,而出於"精神食糧"這話的本意,"好讀"也該是對書的最高讚許

好讀有兩層意思,讀起來容易,和讀起來可口。小書不都易讀(听說過《邏輯哲學論》?),易讀的書也不都可口(有些易讀則易讀矣,但就好像小兒止咳糖漿,來多了就是對你智力的侮辱--還用提余秋雨老師嗎?)但對於一本技術書而言,把自己的主題講清楚了,而且還易讀,也是了不起的成就。好些人寫書,一味在"內在美"上下功夫,殊不知,"可接近性"才是首要的一環:我們不也說"可口"、"可人兒"嗎?"可"(也是accessibility裡的ability)最要緊。

回到正題,談談全書的結构:我手上這本MMM的二十年紀念版(Anniversary Edition),共19章(另有簡短的前言--初版和再版各一篇--和尾聲)。其中,第1到15章是初版內容,最長的一章17頁,最短的第五章刨去題圖和題記,不過薄薄兩張半紙而已。作者稱這些章節為"隨筆(essays)",每章各自處理相對獨立的主題("人月"問題、軟件項目的人員構成、開發中的交流、文檔、排錯等等),因而你基本可以不顧及章節間的聯系,單獨從你感興趣的任何段落入手。書末的四章裡,第18章"Proposition of MMM:True or False?"是對之前各章所有觀點的一個列表--一個非常便於翻檢和溫習的設置;其他的三章(對於"銀彈"的兩篇討論和後記)篇幅在二十到四十頁,值得專門對待。對於一本初版於多年前的技術書籍,作者並沒有逐條修訂原有的內容,而選擇了重印這些章節,同時在後記中根據二十年來的技術上和認識上的變化檢討得失。

現在,你大概能模糊地看到這本書的樣子:很薄,隨手翻上去每章很短,並包含大量整頁的插圖(從側面看,書頁的顏色黑白參差)。換言之,可讀性首先來自於外表,你拿起它,馬上就感到美味當前。

然後你會注意到書的風格。關於原版技術書的語言風格,我曾經在別處做過一個區分:可讀的/可翻譯的(對另一對為人熟知的法國概念的蹩腳模仿)。"可讀的"風格主要出現在用母語寫作的作家筆下。他們能夠自如地使用語言中的元素,幾乎總能找到對特定概念最合适的表達。這些表達,往往植根於該語言自身,因此很難轉換為另一種語言。比如本書作者給討論"系統空間限制"的一章的標題是"ten pounds in five-pound sack"。對任何具備高考英語水平的讀者,這裡的意思都非常直觀,但是誰能輕易地給出它的中文等價物?"削足適履" ?(我碰巧知道中譯本就是這麼翻譯的。) "五磅的麻袋裝十磅"?另一方面,"可翻譯的"文本則多為移民作家的產物。對於一個概念,他們缺乏"自然的"表達方式。他們在用別人的語言,一串串的詞像臨時借用的家具一樣擺放那裡。你可以簡單地逐字翻譯這樣的文本,甚至可以采用机器翻譯而不會犯大錯誤(從Jacobson et al的OOSE摘引隨便一句:"When strong semantics are provided at the behavioral description level for all of these fundamental issues, they radically affect the selection of an appropriate resource structure."),但是無論譯或不譯,都很難馬上明白他說的是什麼。當然,這只能是對實際情況的最簡化的0階模擬(一些喜歡在行文中加入俚語的本土作家幾乎不能歸入任何一邊)。但是,當我說出"可讀的"時,我首先想到的就是Brooks和另一位大師Martin Fowler。二者的風格具有不少共同之處:親切、不賣弄,能用最普通的英語說明(有時是令我們的漢語絕望的)複雜問題。

本書的作者Brooks(也許應該說"小"布魯克斯才對,因為他的全名是"Fredrick P. Brooks, Jr."),曾擔任IBM的大型机System/360及其操作系統OS/360的開發項目經理,被稱為"S/360之父",之後轉入大學,執教多年,因而難能一見地在實際項目管理和教學上都具備世界級水平。在離開IBM近十年之後(1975年),他根據大量切身實踐和教學經驗寫出了本書,在風格上,也兼具教師的醇厚耐心和工程師的技術素質。我個人最受益於書中隨處可見的精彩的比喻。僅僅舉幾個例子:"焦油坑"、"大教堂"、"外科手術隊伍"、"銀彈",就我記憶而言,幾乎每一個都是對所指對象最貼切的形容。而這些隱喻的光彩,又通過眾多題圖、題記(有時不失幽默)的反射,獲得了熠熠生輝的效果。

在很多情況下,過分追求"幽默感"也會產生止咳糖漿式的效果。典型的例子是Peopleware。與MMM相比,那本書總是給我一種推銷員教材的印象。二書作者技術背景(我不認為DeMarco們曾參加過嚴肅的軟件項目)、宗教背景的不同(Brooks是位虔誠的基督徒)也許可以解釋賣弄和樸實、空洞和厚重之間的差距。

來自法式餐館、手術台和狼人的啟示

讓我們回顧豆豆本人的批評實踐。在我看來,它具備難以錯認的形式主義特征:主要考慮"外在"的、形式的(比如畫的大小)要素,而忽略作品實際再現的內容--我們記得豆豆本人唯一一次提及畫中的那位老太太時的措辭:停在仙人掌上的、丑惡的老蝙蝠("a hideous old bat who looks like she's got a cactus lodged up her backside")。我也要採用這樣的策略嗎?讀者們(我設想,看到這篇書評的各位多數是技術專家)恐怕會譏之為買櫝還珠,另外,MMM的內容也遠比"老蝙蝠"更有可談之處。但即便如此,逐一考察書中的觀點也是不現實的:首先,沒有人比作者已經做過的更好,如果你確實需要,不如去看原書第18章;其次,全書並沒有一個一以貫之的中心思想可以提取,對於比如說溝通、文檔、排錯、工具等領域,每一個都值得專文仔細討論。經過考慮,我決定談談那些無需我重讀原書就可以回想起來的內容--這也就是經過我的巴士閱讀實踐(基本上是一個高通濾波過程)幸存下來的精華成分。

人月

首先是"人月(man-month)"。熟悉軟件項目管理的各位肯定清楚,人們常常根據人月來估計工作量(並相應收費),比如一個項目五人兩月完成,那麼總工作量就是10人月。本書以此命名,套用唱片工業的術語,可以說"人月神話"是本"專輯"中主打篇目,而除了以之為標題的第二章之外,並沒有太多內容與此有關。

稱之為"神話",作者的用意也並非完全否定作為計量方法的人月,而是要理清這個概念中隱含的種種錯覺。根據我勤勉而不可靠的記憶,這裡的主要論斷包括:1. 人/月之間不能換算,換言之,兩人做五個月完成,不等於說五人做兩個月就能完成;2.(也是最有爭議的一點)在項目後期增加人手,只能使工期進一步推遲;3.項目越大,單位工作需要的人月越多。或者說,歸根結蒂,作者要粉碎的是"人月"概念可以線性把握的神話:無論是開發人員的人數上,還是工作量本身上的變化,都可能導致最終完成時間的非線性變化。作者的戲劇性表述是:Adding manpower to a late software project makes it even later. 這個觀點事實上並非像它看上去那麼有挑舋性,而作者在初版以及後記中,都表示這包含了合理的誇張,後記裡甚至援引進一步的研究表示,增加人手不一定會使工期進一步推遲,不過肯定會使工程效率進一步降低--而如果一定要增加人手,越早越好。

得出這樣的結論,主要的考慮是增加人手帶來的隱性花費(人員培訓、多人工作時的通信成本等等)以及項目進程中存在的無法逾越的關鍵路徑(crucial path)。對於項目管理人員來說,這應該已經是一個不言而喻的真理。但由於最終決策者的壓力,實際項目中卻往往會發生與此違背的情況。作者把一份法式餐廳菜單塞進了書中作為題圖,我也建議大家學會菜單上的那個句子:Faire de la bonne cuisine demande un certain temps. Si on vous fait attendre, c'est pour mieux vous servir, et vous plaire(做好菜需要一定的時間。如果人家讓您多等會兒,那是為了讓您最後吃得高興。) 對於說法語的客戶/老板,這會是一個好的搪塞。

概念完整性

如果一定要找到貫穿全書的概念的話,"概念完整性(conceptual integrity)"可能算是一個。宁可少添加一些七七八八的功能(anomalous features),也應該保證,整個系統體現的是完整的一套設計理念 :這是引入概念完整性的含義。概念完整性的受益者包括最終用戶、系統開發者、培訓員和服務人員。概念完整性保持得好的系統更易用,需要較短的培訓時間和學習時間,同時也更易於開發。但是在軟件生產的實踐中,各級決策者都很容易產生強調 "功能"而忽視概念完整性的傾向。因此我們看到了太多包含大量"功能",而就整體而言不知所云的系統,也出現過太多次由於一兩個附加功能的實現難度而導致整個系統開發推遲、甚至難產的事例。

所以作者提出,概念完整性是系統設計中最重要的考慮。在保證概念完整性的各方面中,我認為作者提出的兩點最為有趣。第一,要克服系統的"第二版效應(the second system effect)"。一個系統設計師在設計第一版系統時,往往出於較弱的自信心以及量力而行的考慮,會盡量剪裁要實現的功能數量。而當第一版系統成功發布,開始第二版的設計時,隨ぴ自信心的增強,大量以前被壓制的提議都會重現,設計師在塞入新的功能時也會不再那麼保守。這很可能導致一個臃腫而缺乏概念完整性的第二版系統(作者的1995年舉的例子是Windows 31之後的Windows NT)。第二,整個項目團隊的有效組織有助於保證概念完整性。首先,要區分產品人員和開發人員,architect和implementer。這裡所說的architect相當於一般而言的產品經理。只有他以及少數的幾個人能確定整個的產品需求,而不應把即使是最細微的需求留給開發人員確定。在需求確定的過程中,多次反复,包括來自開發人員的反饋都是必要的,但為確保概念完整性,做出決定的必須是少數,甚至一個人。另外,在開發中可以考慮"外科手術式的"開發團隊,即,由唯一的"手術師"(技術大拿)以及多個助手、測試員、聯絡人員、文檔/工具/配置管理員、秘書等組成的隊伍。顯然無論是產品/開發人員的區分,還是外科手術式隊伍的引入,核心原則都是1)職能細分;2)將高要求的工作集中在少數人手中。事實上,作者在其他的章節裡說過,提高軟件項目的質量的最好辦法之一,就是找到合适的人。"偉大"的設計師和普通設計師之間的差別,比采用任何先進工具/方法論/管理模式前後的差別都要大。

銀彈和其他

另外,增補部分中的"銀彈"是作者獨創的又一個概念。在古代的狼人傳說中,只有用銀質子彈才能制服這些舉止無常的怪獸。因此作者也用"銀彈"一詞,命名人們渴望找到的制服軟件項目這頭難纏的怪獸的法寶。"沒有銀彈"意味著,沒有任何一種方法(無論技術上的或是管理上的),單單采取它就能將現有的軟件開發生產率(可靠度/簡洁度)提高一個數量級。

作者的論證是簡洁而(在我看來)有效的:軟件開發的困難來自兩個方面:本質的和偶然的(類似於經院哲學中的本質/偶性的對立)。本質的困難是軟件開發本身所固有的,無法用任何方式取消的,而偶然的困難是其中的非本質因素,可以通過引入新工具、方法論或管理模式來消除。關鍵在於,只要本質的困難在軟件開發中消耗百分之十以上的工作量,則即使全部消除偶然困難也不可能使生產率提高10倍。

就像作者其他很多論證一樣,讀完關於銀彈的部分我們或者會說"本來就是這樣,這還用說",或者會說"這麼簡單的事,我以前怎麼沒有想到"。正是這種介乎漠視和震惊之間的搖擺體現了這些論斷的價值:它們也許在理論上已經是被過分強調、被超越、被唾棄的了,但即便如此,在實踐中我們往往連這些基本的原則都會完全不顧。對我們而言,MMM或許首先是一本關於態度的書。它指認的問題首先是,對待軟件開發工作時應采取怎樣的態度。正是因為某種態度,我們才會熱衷於尋找解決一切問題的銀彈(RUP也好,CMM也好,XP/Agile也好)而從未誠心誠意地貫徹其中任何一個原則;我們才會急於在系統中塞入一個又一個的功能,無視用戶使用時的實際效果;我們才會無法相信自己能夠組成"外科手術式"的團隊,無法找到不做產品設計的開發人員;我們才會一次次接受形形色色的人月調整,最後把一個個項目帶進了"焦油坑"。

據我看來,軟件工程首先是一種緩慢的藝術。在這中間,籌劃、交流、冥想以及迭代占有很大比重,同樣(如果不是更重要的),錯位、反複甚至離題也應據有一席之地。即便強調工程的可控性,也難以排除這些必要的環節(記得法式餐館的例子?)。我們所能做的,是給它們足夠的時間和容忍(你知道我不是指縱容延期)。

Brooks在書中提出的兩組時間比例也許值得留意:一個"能轉(ready to run)"的程序(program)要變成程序產品(programming product)需要3倍於編程的時間;同樣,能轉的程序變成程序系統(programming system)也需要3倍的時間。准此,則要獲得程序系統產品(programming systems product--有點拗口,但仔細想想,還可以?),需要9倍於編寫"能轉"的程序的時間。另外,他在提到工期規劃時說,整個工期的三分之一給計劃(planning),六分之一編碼(coding),四分之一組件測試和早期系統測試(component test and early system test),最後四分之一系統測試。

類似的劃分,遠比我們常見的各種方法論中的"里程碑"粗糙得多,但是,有多少人在實踐中相信編碼應只占整個工期的六分之一甚至九分之一?是否仍是"態度"的原因使我們失去了緩慢工作的能力?我們能把這種態度命名為"浮躁"嗎?當所有競爭者都許諾只用那六分之一就能完成整個項目的時候,你能堅持那個"一"嗎?我們能像提高氣功境界那樣,從一種態度躍遷到另一種嗎?軟件開發是一種氣功嗎?外科手術、銀彈和法國菜都是氣功嗎?狼人能用氣功治好嗎?氣功也能用人月估計嗎?豆豆和老蝙蝠,誰更像狼人?狼人也會浮躁嗎?浮躁的狼人究竟更需要氣功還是銀彈?還是書評?一篇豆豆式的書評?

尾聲

寫到這裡,我愿意介紹我手頭這本MMM的由來。打開書皮,我能看到封底處"Low Price Edition (LPE) authorized for sales only in India, Bangladesh, Pakistan, Nepal, Sri Lanka and Maldives"的字樣。原有的書店標簽(我印象中是"Graham,250rs")不知什麼時候脫落了。但即使缺乏這個標簽,僅僅"LPE"還是能讓我回想起在班加羅爾Graham書店度過的那個匆忙的黃昏:第三或四層是技術專區--我開始只找到了Jacobson們的OOSE(有點困惑於複雜的書店佈局)--看到另外一人手中的Software Project Survival Guide--我求助於一個店員,他立刻拿給我那本書,和一本MMM--另一個店員看到它們,又遞來一本Peopleware...

本文的完成,主要與我一次偶然的閱讀有關,與一些論壇中朋友們對MMM的熱衷和猜想有關,而與該書中文版本的推出可能只有間接的關系。我無意以此給這個譯本作任何廣告(我在別處談過我對中文翻譯的態度),當然更無意作反廣告。不過,如果現在手頭沒有這本書的話(一個不幸的假設),我會到書店翻翻那個譯本,看看插圖複製的質量(尤其是那些銅版畫--LPE能讓我數清狼人腳爪上的毛),再看看書後還有沒有注釋和索引。仍然是那些外在的、膚淺的因素會決定我是否購買,就像在任何一個豆豆式書評的作者那裡一樣。

參考資料

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, 1995 Addison-Wesley, 322 pp

Peopleware : Productive Projects and Teams, 2nd Ed., by Tom Demarco, Timothy R. Lister, 1999 Dorset House, 264 pp

Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson et al, 1992 Addison-Wesley, 524 pp

Bean: The Movie, by Mel Smith (Director), 1997, 90mins

關於作者

劉天北,北京奧捷特通信技術有限公司技術總監,您可以通過liutb@ultract.com與他聯系。

-- the end