新方法學

領測軟件測試網 新方法學

英文原文版權由Martin Fowler擁有 
Original text is copyrighted by Martin Fowler

Martin Fowler
Chief Scientist, ThoughtWorks 

過去幾年中興起的敏捷型（agile）軟件開發方法，以矯正官僚繁瑣過程，或者許可對過程進行自主調整為特征，在軟件業引起了極大的興趣。在這篇文章里，我將探索敏捷型方法的合理性，著重點并不是放在其“輕重”上，而是于它們的適配性（adaptive）性質和以人優先的理念。我在本文也簡要介紹了一些敏捷型方法并給出了進一步的參考材料。另外，我還給出了一些你在決定是否要走這條剛踏出來的敏捷之路時需考慮的因素。 

最近一次主要修改: 2001年11月 

在SD East 上我作了一次演講 “讓軟件恒軟〔Keeping Software Soft）” 其材料就是基于這篇文章（你若有充足的時間可浪費的化，不妨一觀）。此文的節略版發表于 Software Development Magazine（軟件開發雜志） 的2000年12月期。 

從無，到繁重, 再到敏捷 
預設性與適配性 
將設計與建造分離開來 
需求的不可預設性 
預設性是不可能的嗎？ 
不可預設過程的控制 
適配性的客戶 
讓人優先 
可兼容性程序插件 
程序員是負責任的專業人員 
面向人的過程的管理 
應用域專家的引領作用 
自適配過程 
敏捷型方法 
XP（Extreme Programming －－ 極端編程） 
Cockburn的水晶系列方法 
開放式源碼 
Highsmith的適配性軟件開發方法〔ASD） 
SCRUM 
Coad的功用驅動開發方法〔FDD） 
動態系統開發方法〔DSDM） 
敏捷軟件開發宣言 
RUP是一種敏捷型方法嗎？ 
其他參考材料 
你是否應走向敏捷？ 
該用哪個適配性過程？ 
鳴謝 
修改記錄 
從無，到繁重, 再到敏捷 
多數軟件開發仍然是一個顯得混亂的活動，即典型的“邊寫邊改” （code and fix）。設計過程充斥著短期的，即時的決定，而無完整的規劃。這種模式對小系統開發其實很管用，但是當系統變得越大越復雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難于排除。一個典型的標志就是當系統功能完成后有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產生嚴重的影響。 

我們使用這種開發模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是“正規方法”（methodology）。這些方法對開發過程有著嚴格而詳盡的規定，以期使軟件開發更有可預設性并提高效率，這種思路是借鑒了其他工程領域的實踐。 

這些正規方法已存在了很長時間了，但是并沒有取得令人矚目的成功，甚至就沒怎么引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發進程。所以它們通常被認為是“繁瑣滯重型”方法，或 Jim Highsmith 所稱的“巨型”（monumental)方法。 

作為對這些方法的反叛，在過去幾年中出現了一類新方法。盡管它們還沒有正式的名稱，但是一般被稱為“敏捷型”方法。對許多人來說，這類方法的吸引之處在于對繁文縟節的官僚過程的反叛。它們在無過程和過于繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。 

敏捷型與滯重型方法有一些顯著的區別。其中一個顯而易見的不同反映在文檔上。敏捷型不是很面向文檔，對于一項任務，它們通常只要求盡可能少的文檔。從許多方面來看，它們更象是“面向源碼”（code-oriented）。事實上，它們認為最根本的文檔應該是源碼。 

但是，我并不以為文檔方面的特點是敏捷型方法的根本之點。文檔減少僅僅是個表象，它其實反映的是更深層的特點： 

敏捷型方法是“適配性”而非“預設性”。 重型方法試圖對一個軟件開發項目在很長的時間跨度內作出詳細的計劃，然后依計劃進行開發。這類方法在計劃制定完成后拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。 
敏捷型方法是“面向人”的(people-oriented) 而非“面向過程”的 (process-oriented)。 它們試圖使軟件開發工作順應人的天性而非逆之。它們強調軟件開發應當是一項愉快的活動。 
在以下各節中，我將詳細地探討這些差別，這樣你可以了解適配性和以人為中心的過程是什么，它們的好處與不足，以及你作為軟件開發人員或用戶時是否應該使用它們。 

預設性與適配性 
將設計與建造分離開來 
傳統的軟件開發正規方法的基本思路一般是從其他工程領域借鑒而來如土木工程模式對軟件工程的影響較大。這類工程實踐中，在實際建造之前，通常非常強調設計規劃。工程師首先給出一系列的圖紙，這些圖紙準確地說明了要建造什么以及如何建造（包括部分和整體）。許多工程問題，如怎樣處理一座橋梁的負荷，圖紙上都有說明。然后，這些圖紙分發給另外一組人員，通常是另外一個公司，去建造。這種方式其實已假定了建造過程將按圖紙而來。當然，施工中也會碰到一些問題，但這些都是次要的。 

圖紙其實就是一個詳細的建造計劃，它說明了一個項目中必須完成的各項任務，以及這些任務之間的依賴關系。這樣，管理層能較為合理地制訂出生產進度表和項目預算。這種模式實際上也規定了建造者如何做（施工），這也隱含著建造者不須是高智能型的，盡管他們可能都有非常高超的手上功夫。 

在此，我們看到的是兩類非常不同的活動。設計是難于預設的，并且需要昂貴的有創造你的人員，建造則要易于預設。我們有了設計之后，便可對建造進行計劃了。而有了建造計劃后，我們進行建造則可以是非�？深A設性的了。在土木工程中，建造不論在經費上還是在時間上的花銷都要比設計和計劃大得多。 

所以，多數正規方法的途徑是象這樣的：我們想要可預定的生產進度計劃，以便能使用技能較低的人員。要達到這一點，我們必須得把設計與建造分離開來。因此，在軟件開發中，我們得想法作出這樣的設計，使得計劃一經完成，建造將會是直接而明確的。 

那么，計劃應該采用什么形式呢？對許多人來說，這是設計“標識符號” （notation），如象UML，需承擔的角色了。如果我們能用UML作出所有主要的技術決定，那么就可以用UML來做建造計劃，然后把計劃交給程序員去編碼，即是建造活動。 

但這里存在幾個問題。你是否能作出這樣的設計使得它能夠讓編碼成為一項建造活動？如果能，那么建造是否能在資金和時間上的花銷都充分地大于設計而使得這種途徑值得一用？ 

第一個問題是到底有多困難能使一個用類似UML作出的設計達到交給程序員就能直接編碼的狀態。用象UML那樣的語言作出的設計在紙上看起來非常漂亮，而實際編程時可能會發現嚴重的缺陷。土木工程師使用的模型是基于多年的工程實踐，并結晶在工程典章中。更進一步來說，一些設計上的關鍵部分，如應力作用，都是建立于堅實的數學分析之上。而在軟件設計中，我們對UML圖紙所能做的只是請專家審閱。這當然是很有幫助的，但是往往一些設計錯誤只能在編碼和測試時才能發現。甚至于熟練的設計者，我自認為我屬此列，就常常對在把設計變成軟件的過程中出現的錯誤感到意外。 

另一個問題是費用比較。建一座橋梁時，設計費用一般占整個工程的10％，左右，余下的90％左右為施工建造費用。而在軟件開發中，編碼所占的時間一般要少得多（McConnell 指出在大型項目中，編碼和單元測試只占15％，這幾乎和橋梁工程中的比例倒過來了。即使把所有測試工作都算作是建造的一部分，設計仍要占到50％）。這就提出了一個重要問題，那就是和其他過程領域的設計相比，軟件設計到底是什么性質。 

更有甚者，Jack Reeves 認為源碼也應是設計文檔，而建造應該是編譯和鏈接，因為任何屬于建造的工作都應當是自動化的。 

這些討論導致了下面一些結論： 

在軟件開發中，具體建造費用非常低，幾可忽略不計。 
軟件開發的絕大部分工作是設計，因此需要富有創造性的才智之士。 
創造性的過程是不太容易計劃的，因此，可預設性不可能成為一個要達到的目標。 
我們應該對用傳統工程模式來進行軟件開發的做法保持足夠的警覺，因為它們是不同類型的活動，因此需要不同的過程。 
需求的不可預設性 
在每個我參加的項目都有這樣一種情況，開發人員跑來抱怨說， “這個項目的問題是需求老是在變”。而讓我意外的是每個人都對此感到意外。其實在建造商用軟件系統中，需求變更是常態，問題是我們如何來處理它。 

一種方法是把需求變更看成是因需求工程（requirements engineering）沒作好而導致的結果。一般來說，需求工程（或曰進行需求分析）是要在著手建造軟件之前，獲取一幅已完全理解了的待建系統的畫面，然后取得客戶認可簽發，并且還要建立一套規章來限制需求變更。 

該方法的一個問題是要準確獲取所有需求是困難的，特別是當開發商不能提供某些需求的費用信息時。例如，你買車時想在你的車上裝一個天窗，而推銷員卻不能告訴你要在車價上只再加10元錢呢，還是10000元。如果不知道這點，你如何能決定你是否愿意在車上加個天窗呢。 

作軟件開發的費用估算是不容易的，這有多種原因。部分原因是因為軟件開發是一種設計活動，因此難于精確計劃。部分原因是系統的“基本材料”變化非常之快。部分原因是開發活動極大地依賴于項目參與人員，而個體是難于預測和量化的。 


軟件的“不可觸摸”性也是一個原因。在系統建成之前，有時很難判斷一項功能的具體價值。也就是說，只有當你在實實在在地使用系統時，你才能知道哪些功能是有用的，哪些沒什么用。 

這樣的結果頗具諷刺意味，即人們期待需求應該是可變的。畢竟，軟件應該是 “軟”的。所以，需求不僅是可變的，簡直就是應該變的。要讓客戶把需求固定下來要花很大的力氣，特別是當他們“參與”了軟件開發并且“知道”軟件是多么易于修改。 

但是，即使你能把所有的需求都固定下來，并不意味著你的開發就是陽光燦爛了，你可能仍然會在昏暗之中。在當今的經濟形勢下，決定并推動軟件系統功能特性的商業因素飛快地變化著�，F在一組很好的功能六個月以后可能就不那么好了。 

商業世界并不會因你的系統的需求固定下來了而停止不動，商業世界的許多變化是完全不可預測的。如果有人不承認這一點，要么他在撒謊，要么他已炒股成了百萬富翁了。 

軟件開發的一切都取決于系統需求，如果需求不固定，你就不能制訂出一個可預設性的計劃。 

預設性是不可能的嗎？ 
一般來說，不可能。當然，有一些軟件開發項目中，預設性是可能的。象 NASA的航天飛機的軟件開發項目，應是這樣一個例子。它需要大量的會議，充足的時間，龐大的團隊，以及穩定的需求。畢竟，這些是航天飛機的項目。但我并不認為一般的商用軟件開發屬于這類系統，所以你需要不同的開發過程。 

如果你不能遵循一個可預性方法，而你強裝能夠，那么這是非常危險的。通常，一個正規方法的創造者不是很善于（或樂于）給出其方法的邊界條件，換句話說，當這些邊界條件不滿足時，則該方法就不適用。許多方法學者希望他們的方法能夠放之四海而皆準，所以他們既不去了解，也不公布他們方法的邊界條件。這導致了人們在錯誤的情形下來使用一種方法，例如，在不可預設性的環境中使用一種預設性的方法。 

使用預設性方法具有強烈的誘惑力，因為預設性畢竟是一個非常需要的特性�？墒�，當你不能達到預設性時而你相信你能夠，這將會導致這樣一種局面：你可以很早就制訂出計劃，但不能適當地處理計劃崩潰的情形。你看見現實與計劃慢慢的偏離，而你可以在很長的時間里，裝著認為計劃仍是有效可行的。但是當偏離積累到足夠的時候，你的計劃就崩潰了，這通常是很痛苦的。 

所以說，在不可預設性的環境中是不能使用預設性方法的。認識到這點是一個很大的沖擊。它意味著我們用的許多控制項目的模式，許多處理客戶關系的模式，都不會再是正確的了。預設性的確有非常多的好處，我們很難就放棄預設性而失去這些益處。象很多問題一樣，最困難的一點是認識到這些問題的存在。 

可是，放棄預見性并不意味著回到不可控制的一片混亂之中。你所需要的是另一類過程，它們可以讓你對不可預設性進行控制，這就是“適配性” 的作用了。 

不可預設過程的控制 
那么，我們如何對付一個不可預測的世界呢？最重要，也是最困難的是要隨時知道我們在開發中的情形處境，這需要一個誠實的反饋機制來不斷準確地告訴我們。 

這種機制的關鍵之點是“迭代式”（iterative）開發方法。這并不是一個新思路，迭代式開發方法已存在很久了，只是名稱不同，如“遞增式”（Incremental），“漸進式”（Evolutionary)，“階段式”（Staged），“螺旋式”（Spiral）等等。迭代式開發的要點是經常不斷地出最終系統的工作版本，這些版本逐部地實現系統所需的功能。它們雖然功能不全，但已實現的功能必須忠實于最終系統的要求，它們必須是經過全面整合和測試的產品。 

這樣做的理由是：沒有什么比一個整合了的、測試過的系統更能作為一個項目扎扎實實的成果。文檔可以隱藏所有的缺陷，未經測試的程序可能隱藏許多缺陷。但當用戶實實在在地坐在系統前來使用它時，所有的問題都會暴露出來。這些問題可能是源碼缺陷錯誤（bug），也有可能是對需求理解有誤。 

雖然迭代式開發也可用于可預性環境，但它基本上還是用作“適配性” （adaptive）過程,因為適配性過程能及時地對付需求變更。需求變更使得長期計劃是不穩定的，一個穩定的計劃只能是短期的，這通常是一個“迭代周期”（iteration）。迭代式開發能讓每個迭代周期為下面的開發計劃提供一個堅實的基礎。 

迭代式開發的一個重要問題是一個迭代階段需要多長。不同的人有不同的答案， XP（極端編程）建議一到兩周，SCRUM建議一個月，Crystal（水晶系列）更長一些。不過，一般的趨勢是讓每一個周期盡可能地短。這樣你就能得到頻繁的反饋，能不斷地知道你所處的狀況。 

適配性的客戶 
這類適配性過程需要與客戶建立一種新型的關系，特別是當開發是由一家簽約公司來進行的時候。因為當雇傭一家簽約公司來進行開發時，多數客戶愿意訂一個固定價格的合同。他們告訴開發方他們所需要的功能，招標，簽約，然后剩下的便是開發方去建造系統了。 

固定價格合同需要穩定的需求，即一個可預設性過程。適配性過程和不穩定的需求意味著你不能做這種固定價格的合同。把一個固定價格模式弄到適配性過程將導致一個痛苦的結局。最糟糕的是客戶將與軟件開發者受到同樣的傷害，畢竟客戶不會想要一個不需要軟件。即使他們未付開發方一分錢，他們仍然失去許多。 

因此，在可預設性過程不能用的情況下，簽訂固定價格合同對雙方來說都有危險。這意味著客戶須換一種工作方式。 

在適配性過程中，客戶實際上能夠對軟件開發過程進行很深入細微的控制。在每一個迭代階段中，他們都能檢查開發進度，也能變更軟件開發方向。這導致了與軟件開發者更密切的關系，或曰真正的伙伴關系。但并不是每一個客戶，也并不是每一個開發商都準備接受這種程度的介入，不過如要讓適配性過程能很好工作，這種合作程度是基本的要求。 

適配性過程對客戶最關鍵的益處是軟件開發中的“回應性”很好。一個可用的，盡管是很小的系統能夠盡早投入使用。根據實際使用情況，以及變更了的需求，客戶可及時改變一些系統功能。 

讓人優先 
實施一個適配性過程并不容易，特別是它要求一組高效的開發人員。高效既體現在高素質的個體，也體現在有能讓團隊協調一致的工作方式。這里有一個有趣的和諧：并非只是適配性過程需要很強的團隊，多數優秀的開發人員也愿意采用適配性過程。 

可兼容性程序插件 
傳統正規方法的目標之一是發展出這樣一種過程，使得一個項目的參與人員成為可替代的部件。這樣的一種過程將人看成是一種資源，他們具有不同的角色，如分析員，程序員，測試員及管理人員。個體是不重要的，只有角色才是重要的。這樣一來，在你計劃一個項目時，你并不在乎你能得到哪個分析員，哪些測試員，你只需關心你可得到多少，知道資源數量會如何影響你的計劃。但這有一個關鍵問題：參與軟件開發的人員是可替代的部件嗎？輕靈型方法的一個重要特征就是拒絕這種觀點。 

也許最明確地反對這種觀點的當數Alistair Cockburn. 在他的論文 “人是非線性，一階的部件”中，他指出可預設性軟件開發過程要求 “部件”的行為也是可預性的。 

但是，人并非可預性的部件。更進一步，他對軟件項目的研究導致了如下結論：人是軟件開發中最重要的因素。 


在本文的標題里，我將人稱為“部件”。其實（傳統）過程/方法就是這樣看待人的。這種觀點的錯誤在于“人”是非�？勺兊暮头蔷�性的，不同的個體具備特有的成功或失敗模式。那些因素是一階的，不可忽略的。一種過程或方法的設計者如不能充分考慮到這些因素，那麼其后果就是項目的無計劃軌跡。就象我們經�？吹降哪菢�。
-- Alistair Cockburn 

Cockburn是最鮮明地主張在軟件開發中應以人為中心，其實這種概念在許多軟件行業的有識人士中已是共識。問題在于所使用的方法是與這種理念背道而馳的，這造成了一個很強的正反饋機制。如果你期望你的開發人員是可互替的編程插件，則你不會去試著把他們看成是不同的個體。這會降低士氣（和生產率），并使優秀的人才跳到一個能發揮其個性特長的地方，最后你倒是得到你所需要的：可互替的編程插件。 

決定使人優先是件大事，它需要很大的決心來推行。把人作為資源的思想在工商界是根深蒂固的，其根源可追溯到 泰勒的“科學管理”方法。當管理一個工廠時，這種泰勒主義途徑是有效的。但是對有著高度創造性和專業性的工作，我相信軟件開發當屬此類，泰勒主義并不適用（事實上現代制造業也在脫離泰勒主義模式）。 

程序員是負責任的專業人員 
泰勒主義的一個關鍵的理念是認為干活的人并非是那些知道怎樣才能把這件活干的好的人。在工廠中可能是這樣，原因是許多工廠里的普通工人并非是最具聰明才智和最富創造力的人員。另一個原因也許是由于管理層和工人的的工資懸殊太大而導致的關系緊張。 

歷史證明這種情形在軟件開發中是不存在的。不斷有優秀人才被吸引到軟件行業中，吸引他們的既有耀眼的光芒也有豐厚的回報（正是這兩樣誘使我離開電子工程）。其他一些福利如對公司的股份持有使得程序員的利益與公司緊聯在一起。 

〔可能還有一個“產生”（generational)效應。一些所見所聞讓我想到是否在過去十來年中有很多的優秀人才轉入軟件行業。如果是這樣，這可能是當今年輕人崇尚IT業的原因，就象其他時尚一樣，其后總有一些實在的理由。） 

如果你想聘到并留住優秀人才，你得認識到他們是有能力的專業人員。因此，他們最有資格決定如何干好他們的技術工作。泰勒主義里讓計劃部門來決定如何干好一件工作的作法只有當計劃者比實際操作者更能知道怎樣作時才有效。如果你擁有優秀的、自覺自勵的員工，那么這點并不成立。 

面向人的過程的管理 
敏捷型過程中“以人為本”的理念可以有不同的表現，這會導致不同的效果，而并非所有結果都是完全一致的。 

實施敏捷型過程的一個關鍵之處是讓大家接受一個過程而非強加一個過程。通常軟件開發的的過程是由管理人員決定的，因此這樣的過程經常受到抵制，特別是如果管理人員已脫離實際的開發活動很長時間了。而接受一個過程需要一種“自愿致力”，這樣大家就能以積極的態度參與進來。 

這樣導致了一個有趣的結果，即只有開發人員他們自己才能選擇并遵循一個適配性過程。這一點在XP中特別明顯，因為這需要很強的自律性來運行這個過程。作為一個互補，Crystal（水晶系列）過程則只要求最少的自律。 

另一點是開發人員必須有權作技術方面的所有決定。XP非常強調這一點。在前期計劃中，它就說明只有開發人員才能估算干一件工作所需的時間。 

對許多管理人員來說，這樣形式的技術領導是一個極大的轉變。這種途徑要求分擔責任，即開發人員和管理人員在一個軟件項目的領導方面有同等的地位。注意我說的同等。管理人員仍然扮演著他們的角色，但需認識并尊重開發人員的專業知識。 

之所以強調開發人員的作用，一個重要的原因是IT行業的技術變化速度非常之快。今天的新技術可能幾年后就過時了。這種情況完全不同于其他行業。即使管理層里的以前干技術的人都要認識到進入管理層意味著他們的技術技能會很快消失。因此必須信任和依靠當前的開發人員。 

應用域專家的引領作用（The Role of Business Leadership） 
技術人員并不能包打天下，他們需要應用系統的需求分析，即他們需要與應用領域專家非常緊密的聯系，這是適配性過程一個重要的方面。這種聯系的緊密度遠遠超過了一般項目中應用領域分析人員的介入程度。如果開發人員和應用領域專家只有偶爾的溝通，那么敏捷型過程是不可能存在的。此外，這種溝通不是由管理層來處理的，而是每個開發人員需要做的事。因為開發人員在他們的行業里是有能力的專業人員，因此他們能夠與其他行業的專業人員同等地在一起工作。 

這是由適配性過程的特點來決定的。因為在整個開發過程中，事情變化很快，你需要經常不斷的聯系溝通以使每個人都能及時知道這些變化。 

對開發人員來說，沒有什么比看見自己的辛勤工作白白浪費更讓人痛苦的了。因此，開發人員能隨時獲取準確的高質量的應用系統的（需求）知識就顯得很重要了。 

自適配過程 
到目前為止，我談到的適配性是指在一個開發項目中如何頻繁地修改軟件以適應不斷的需求變更。但是，還有另一種適配性，即是過程本身隨著時間推移變化。一個項目在開始時用一個適配性過程，不會到一年之后還在用這個過程。隨著時間的推移，開發組會發現他們的工作有些什么變化，然后改變過程以適應之。 

自適配的第一步是經常對過程進行總結檢討。一般來說，在每一次迭代結束后，你可以問自己如下問題〔Norm Kerth）： 

有哪些做的好的部分 
有哪些教訓 
有哪些可以改進的部分 
有哪些沒搞清楚的部分 

這些問題會幫助你考慮在下一次迭代中如何對過程進行修正。在樣，如果開始時使用的過程有問題的話，隨著項目的進行，該過程會得以逐步的完善，以使其能更好地適合開發組。 

如果一個項目采用了自適配方法，則可以進一步在一個組織內引入這種方法。如果要深化自適配過程，我建議開發人員專門用一段時間做一次更為正式的回顧總結，象Norm Kerth所建議的那樣，這些活動包括離開工作地點，到另外一個地方開2－3天的總結會。這不僅是給開發組提供一次學習機會，同時也給整個組織一次學習機會。 

自適配性導致的結果是你絕不能期待著只用一個過程。相反，每個項目組不僅能選擇他們自己的過程，并且還能隨著項目的進行而調整所用的過程。公開發表的過程和其他項目的經驗都可以拿來作為參考和樣本。但是開發人員需根據手中項目的具體情況而對其加以調整，這也是開發人員的專業職責。 

這種自適配性在ASD和Crystal（水晶系列）中都鮮明地提及。XP的嚴格規則似乎不允許這樣，但這只是表面現象，因為XP是鼓勵調整過程的。這一點上XP和其他方法的主要區別之處在于，XP的倡導者建議在采用XP時，先根據書本循規蹈矩不走樣地做幾個迭代之后，再考慮調整。另外，回顧總結這點在XP中沒有被強調，也不是這個過程的組成部分，盡管XP建議經常性的回顧應作為XP的實踐準則之一。 

敏捷型方法 
好幾個方法都可以歸入敏捷型旗下，它們有許多的共同特征，但也有一些重要的不同之處。在此簡短的綜述中，我不可能列出這些過程所有的特點，但至少我可以告訴你可以到什么地方去查找更詳細的材料。對大多數這些方法我都沒有深入的實際經驗。我有很多工作是基于XP的，也對RUP有些經驗。但是對其他方法來說，我的知識主要是來自書本（當然這是很不夠的）。 

XP（Extreme Programming －－ 極端編程） 
在所有的敏捷型方法中，XP是最為引人矚目的。部分原因是因為XP的領軍人物們的卓越能力，特別是Kent Beck，他能夠把人們吸引到這種方法來，并一直處于領先地位。但是XP熱也帶來了一個問題，就是它把其他一些方法和它們非常有價值的思想給擠了出去。 

XP根源于Smalltalk圈子，特別是Kent Beck和Ward Cunningham在80年代末的密切合作。90年代初，他們在一系列項目上的實踐深化擴展了他們關于軟件開發應是適配性的、應以人為中心思想。 

從非正式的、探索性的實踐到形成系統化的正規方法的關鍵一步是在1996年春。Kent被邀對Chrysler的一個工資管理項目（C3）的開發進度進行審核。該項目由一個簽約公司用Smalltalk開發，正處于困境之中。由于源碼質量低劣，Kent建議推倒重來。該項目然后在他的領導下從頭開始并成了早期 XP的旗艦和培訓基地。 

C3的第一期系統在1997年初投入運行。項目繼續進行了一段時間后，遇到了麻煩，導致了在1999年開發計劃被撤銷。在我寫此文時，該系統還在用來給萬余員工發工資呢。 

XP的四條基本價值原則是：溝通，反饋，簡單和勇氣。在此基礎上建立了十多條XP項目應遵循的實踐準則。其實，許多準則是以前就存在的并經過實踐檢驗的，而常常被忽略了的。XP重新建立了這些準則，并把它們編織成了一個和諧的整體，使得每一項準則都能在其他準則里得以強化。 

XP有一個最具沖擊力的，也是最初吸引我的特點，是它對測試的極端重視。誠然，所有的過程都提到測試，但一般都不怎么強調�？墒荴P將測試作為開發的基礎，要求每個程序員寫一段源碼時都得寫相應的測試碼。這些測試片段不斷地積累并被整合到系統中。這樣的過程會產生一個高度可靠的建造平臺，為進一步開發提供了良好的基礎。 

在此基礎上XP建立了一個漸進型的開發過程，它依賴于每次迭代時對源碼的重組（refactoring）。所有的設計都是圍繞著當前這次迭代，而不管將來的需求。這種設計過程的結果是“紀律性”與“適配性”的高度統一，使得XP在適配性方法中成為發展的最好的一種方法。 

XP產生了一批領軍人物，許多是從C3項目中出來的。關于XP有許多文獻可讀。最好的一篇總結文章是Jim Highsmith的Cutter論文（有趣的是Jim Highsmith并不是XP道中人，他的方法我將稍后介紹）。Kent Beck寫的 Extreme Programming Explained，是一篇XP的宣言，它闡述了隱藏在 XP后面的道理。此書對有心于XP并致力于將其發揚光大者提供了充足的說明和解釋。過去兩年里也出版了一批“多姿多彩”的XP書籍，但多數都很相似，主要是從一些XP早期的實踐者們的角度上描述了 XP的整個過程。 

除了書之外，還有不少網上資源。如果你想找到更有結構性的材料，你最好訪問兩位C3成員的網站：Ron Jefferies的 xProgramming.com 和Don Wells的 extremeProgramming.org。 Bill Wake的 xPlorations 里也有一些很有用的文章。許多XP早期的倡導和發展可在Ward Cunningham的 wiki web （合作寫作）中找到。wiki是個令人著迷的地方，盡管它的漫游性質常令人身不由己的陷入其中。 Robert Martin是一位知名的C++和OO設計的專家，他也加入了XP鼓吹者行列。他的公司 ObjectMentor 網站上有不少文章論及XP，其中一篇提出可把XP看成是一個最小RUP實現，他稱之為 dX。另外，他們也資助 XP討論組〔xp discussion egroup）。還有一篇很有意思的文章從“外面”來審視XP，這就是Mark Paulk所寫的 從CMM的角度看XP。Mark Paulk是CMM的領軍人物之一。 

Cockburn的水晶系列方法 
Alistair Cockburn 在90年代初受IBM之約進行正規方法的研究。從那時起他就活躍于這個領域。他的研究途徑和其他方法學者有所不同。一般的方法學者是將他們個人的經驗升華成理論。而Cockburn除了歸納整理他自己的實踐經驗以外，他還積極地造訪其他項目，和項目組成員進行廣泛的討論，考察這些項目是怎樣運作的。難能可貴的是，他從不固守自己的觀點，他會根據新的發現而隨時修正自己的理論。他的這些特點使得他成為我最喜歡的方法學者。 

他的著作 “Surviving Object-Oriented Projects” 匯集了很多如何順利運行軟件開發項目的建議，此書也是我推薦的運行迭代式項目的首選書。最近，Alistair寫了一本關于 敏捷型軟件開發 的綜述性著作，探討了這些方法的基本原則。 

Alistair還更進一步地探索了敏捷型方法，并提出了 水晶（Crystal）方法系列。之所以是個系列，是因為他相信不同類型的項目需要不同的方法。他認為決定一個方法與兩個因素有關：項目參與人數和出錯后果。如果用兩個坐標軸來分別表示這兩個變量的話，那么在這張圖上，每一種方法都有其相應的位置。例如，有兩個項目，一個是有40人參加，如果失敗造成的資金損失可以接受；另一個項目只有6人，其成敗生存悠關。那么這兩個項目所用的方法在坐標圖上就有不同的位置。 

水晶系列與XP一樣，都有以人為中心的理念，但在實踐上有所不同。Alistair 考慮到人們一般很難嚴格遵循一個紀律約束很強的過程，因此，與XP的高度紀律性不同，Alistair探索了用最少紀律約束而仍能成功的方法，從而在產出效率與易于運作上達到一種平衡。也就是說，雖然水晶系列不如XP那樣的產出效率，但會有更多的人能夠接受并遵循它。 

Alistair也費了不少筆墨強調每次迭代后的總結回顧，因而鼓勵過程本身的自我完善。他的理由是迭代式開發是用來盡早發現問題并解決之。這樣就更加強調了開發人員要隨時觀察他們所用的過程，并隨著項目的進行而調整。 

2001年2月，Alistair宣布他和Jim Highsmith將合并他們的方法。這個方法有何影響，如何命名，都還是有待回答的問題。 

開放式源碼 
看到這個標題你可能會有些意外。畢竟，開放式源碼（Open Source）是軟件的一類風格，而非一種過程。這里我是指開放源碼界所用的一種運作方式，這種方式適用于開放源碼項目，其實它的許多做法也可為封閉式源碼項目所用。開放式源碼項目有一個特別之處，就是程序開發人員在地域上分布很廣。注意到這點相當重要，因為一般適配性過程都強調項目組成員在同一地點工作。 

多數開放源碼項目有一個或多個源碼維護者（maintainer）。只有維護者才能將新的或修改過的源碼段并入源碼庫。其他眾人可以修改源碼，但需將他們所做的改動送交給維護者，由維護者對這些改動進行審核并決定是否并入源碼庫。通常來說，這些改動是以“補丁”（patch）文件的形式，這樣處理起來容易一些。維護者負責協調這些改動并保持設計的一致性。 

維護者的角色在不同的項目中有不同的產生和處理方式。有些項目只有一個維護者，有些項目把整個系統分成若干個模塊，每個模塊有一個維護者。有些是輪流做維護者，有些是同一個源碼部分有多個維護者，有些則是這些方式的組合。許多開放源碼項目的參與者只是部分時間（或業余時間）干，如果項目要求是全日制的，那么這有一個問題，就是怎樣才能把這些開發人員有效地協調組織起來。 

開放源碼的一個突出特點就是查錯排故（debug）的高度并行性，因為許多人都能同時參與查錯排故。如果他們發現了錯誤，他們可將改正源碼的 “補丁”文件發給維護者。這種查錯排故角色對非維護者來說合適，對那些設計能力不是很強的人來說，也是一項挺好的工作。 

關于開放源碼的方法過程還沒有很系統的文獻。目前最著名的一篇文章是 Eric Raymond寫的 The Cathedral and the Bazaar（教堂與集市），文章雖短，但很精彩。另外，Karl Fogel所著的 關于CVS的書中也有幾章描述了開放源碼的方法。即使你不想使用CVS，這幾章還是值得一看。 

Highsmith的適配性軟件開發方法（ASD－－Adaptive Software Development) 
Jim Highsmith 多年來一直從事可預性方法的研究，建立和教學，而最后得出的結論是這些方法都有著根本性的缺陷，特別是在用來作現代應用系統的開發時。 

他最近的 一本書 集中論述了新方法的適配特性，重點討論了把一些起源于復雜適配性系統（通常稱之為混沌理論－－chaos theory）的思想在軟件開發中加以應用。此書沒有象XP那樣提供詳盡的實踐準則，但它從根本上說明了為什么適配性開發方法是重要的，并進一步說明了其對組織結構和管理層的影響。 

ASD的核心是三個非線性的、重迭的開發階段：猜測，合作與學習。 

在一個適配性環境中，因為結果是不可預的，Highsmith把計劃看成是一個 “反論”〔paradox）。在傳統的計劃中，偏離計劃是錯誤，應予糾正。而在一個適配性環境里，偏離計劃則是在引導我們向正確的目標邁進。 

在不可預的環境里，你需要大家能以多種多樣的方式合作來對付不確定性。在管理上，其重點不在于告訴大家做什么，而是鼓勵大家交流溝通，從而使他們能自己提出創造性的解決方案。 

在可預性環境里，通常是不大鼓勵學習的。設計師已經都設計好了，你跟著走就行了。 

在適配性環境中，學習對所有各方，包括開發人員和客戶， 都是一個挑戰。他們需要學習以檢驗他們作的假設，需要學 習以便能用每次開發周期的結果去適配下一個周期。
-- Highsmith 

這樣的學習是連續不斷的，這已成為這種方法的一個重要特點，因此我們必須得認識到計劃和設計都得隨開發的推進而改變。 

適配性開發周期的最大而不可見的好處是其對我們自以為是的心理 模式的挑戰，它迫使我們更實際地估計自己的能力。
-- Highsmith 
有了這樣的出發點，Highsmith把他的工作集中放在適配性開發的難點上，特別是如何在一個項目中增強合作和學習�；�本上說，他的這本書是側重于“軟”方法，這樣對那些從開發實踐中提煉出來的方法如XP，FDD 和水晶系列來說，這本書將是一個很有益的互補。因此Highsmith在2001年 2月宣布他將把他的方法于Cockburn的水晶系列合并，就是順理成章并且很有意義的了。 

SCRUM 
SCRUM在OO界里已很有些時日了，不過我得承認我對其歷史發展并不是太知其詳。象前面所論及的方法一樣，該方法強調這樣一個事實，即明確定義了的可重復的（defined and repeatable）方法過程只限于在明確定義了的可重復的環境中，為明確定義了的可重復的人員所用，去解決明確定義了的可重復的問題。 

SCRUM把一個項目分成若干個為期30天的迭代階段，稱之為一“沖” （sprint）。開“沖”之前，你得明確這一“沖”要實現的功能，然后交給開發組去完成。但是，在“沖”期間，需求必須是固定的。 

管理人員并非在“沖”的時候就撒手不管了。每天，他需召集一個短會（15分鐘左右），稱之為一個scrum，會上大家討論決定第二天干什么。特別是大家會對管理層提出那些阻礙項目進行的因素，并希望管理層能予以解決。當然，他們也需要報告目前完成了什么，這樣管理層每天都能了然項目的進展情況。 

SCRUM文獻多集中論述迭代階段計劃與進度跟蹤。它與其他敏捷型方法在許多方面都很相似，特別是它可以與XP的編程準則很好地結合起來。 

相當長的一段時間沒有關于SCRUM的專門書籍，直到最近 Ken Schwaber和Mike Beedle寫了 第一本SCRUM的專著。Ken Schwaber還主持了一個網站 ControlChaos.com，可能是對SCRUM的最好的綜述。Jeff Suthurland有個總是很活躍的網站討論OO技術，其中有 一部分是專門討論SCRUM的。另外，在 PLoPD 4書中也有一篇關于SCRUM的很好的綜述。 

Coad的功用驅動開發方法（FDD－－Feature Driven Development） 
FDD是由Jeff De Luca和OO大師Peter Coad提出來的。象其他方法一樣，它致力于短時的迭代階段和可見可用的功能。在FDD中，一個迭代周期一般是兩周。 

FDD有以下五項任務： 

建立總體模型 
提出功用清單 
針對功用逐項制訂計劃 
針對功用逐項進行設計 
針對功用逐項開發實現 

頭三項在項目開始時完成，后兩項在每一次迭代周期時都要做。每一項任務又可進一步分解并制訂出相應的檢驗準則。 

在FDD中，編程開發人員分成兩類：首席程序員和“類”程序員（class owner）。首席程序員是最富有經驗的開發人員，他們負責開發實現系統的各項功能。對每一項功能，首席程序員要定出需要哪些類（class）來實現這項功能，并召集“類”程序員們組成一個針對這項功能的開發組。首席程序員作為協調者，設計者和指導者，而“類”程序員則主要作源碼編寫。 

FDD的主要論述見于Peter Coad等所著的 UML in Color 。他的公司 TogetherSoft 也從事FDD的咨詢和培訓工作。 

動態系統開發方法〔DSDM－－Dynamic System Development Methods） 
DSDM在1994年始于英國。 英國一些想用RAD和迭代方式進行系統開發的公司組成了一個社團〔Consortium）。剛開始有17個組建成員，到現在成員已超過1000個，遍布英國內外。DSDM由于是由一個社團所發展，它與其他一些敏捷型方法有些不同。它有專門的組織支持，有手冊，培訓課程，認證程序等。因為它上面的價格標簽而限制了我對此方法的進一步調查。不過Jenifer Stapleton已寫了 一本書來介紹這種方法。 

如果你要用這種方法，你得先作可行性和應用域分析�？尚行苑治鲆�考慮 DSDM是否適合手上這個項目。而應用域分析則是開一系列的討論會，以期能充分了解應用域，同時也要提出大致的系統結構與項目計劃。 

余下的工作由三個互相交織的周期組成：功能模型周期產生文檔和原型（實驗系統），設計建造周期生成可操作使用的系統，實現周期處理系統安裝部署（deployment）問題。 

DSDM有一些基本的原則包括與用戶積極的溝通，頻繁的出活（delivery）。有充分職權的項目組，完全的系統測試。象其他敏捷型方法一樣， DSDM的一個周期在2－6周之間。它強調高質量的系統以及需求變更的高度適配性。 

我還沒有在英國之外的地方看到有項目使用DSDM。DSDM的基本結構有許多成熟的傳統方法的東西，同時又遵循了敏捷型途徑。但這里的確有一點值得注意，即是這種方法是否有鼓勵一種面向過程與繁瑣的傾向。 

敏捷軟件開發宣言 
可以看出，前面所提到的這些方法有很多的相似之處，那么自然大家就會有興趣進行某種形式的合作。 2001年2月，這些方法的代表人物們被邀至猶它州Snowbird 舉行了一個為期兩天的討論會。我也在其列，但開始并未抱太大希望。畢竟，當你把一堆方法學者塞進一間房子時，他們能以禮相待就是上上大吉了。 

結果卻出乎我的意料之外。每個與會者都認識到這些方法有許多的共同點，這種共識遠遠大于他們之間的分歧。這次討論會使這些一流的方法學者們增進了聯系，大家還有意發表一份聯合聲明－－呼吁推動發展敏捷型開發過程（我們也同意用“敏捷”（agile）這個詞來表達我們共有的理念）。 

成果便是一份 敏捷軟件開發宣言〔Manifesto for Agile Software Development），它表述了敏捷型過程所共同具備的價值和原則。與會者也有意在將來進一步合作，并鼓勵方法學者與商界人士使用敏捷型方法進行軟件開發。 Software Development Magazine〔軟件開發雜志）有一篇關于 宣言的評注與解釋的文章，它的片斷可見于 敏捷宣言的將來。 

RUP是一種敏捷型方法嗎？ 
當我們開始討論OO領域的方法時，不可避免地會碰到 RUP（Rational Unified Process）。該過程由Philippe Kruchten， Ivar Jacobson以及Rational Rose 的其他一些人士開發，主要是作為一個與UML相配合和補充的過程。RUP其實是個過程的框架，它可以包容許多不同類型的過程，這一點正是我對RUP的主要批評。因為它可以是任何東西，那么就跟什么都不是一樣了。我愿意選擇的過程是它能明確告訴你干什么，而不是給你無窮無盡的選擇。 

由于RUP是一種框架，你可以以不同的方式來使用它，如象非常傳統的“瀑布” 式開發方式，或敏捷式。你可以把用得輕捷靈便，也可把它弄成繁文縟節。這取決于你如何在你的環境中對它裁剪運用。 

Craig Larman極力主張以敏捷型方式來使用RUP。在他的關于OO開發的 引論著作 中，他提出了一個過程，就是基于這種“輕型”RUP的思想。他的觀點是：目前如此眾多的努力以推進敏捷型方法，只不過是在接受能被視為RUP 的主流OO開發方法而已。在做一個項目時，Craig要干的事情之一便是在為期一月的迭代周期的頭兩三天和整個開發組呆在一起，用UML勾勒出這個迭代階段的設計。這個設計并非是一個不可更改的，它只是一個使大家能知道這個階段如何干的草圖。 

另一種對待RUP的策略是Robert Martin的 dX過程。dX過程是一個完全符合RUP 的過程，而又碰巧與XP完全等同（把dX轉180度可見，一句戲言）。dX是特別適合于那些不得不用RUP而又想用XP的伙計們。由于dX既是XP又同時是 RUP，它可作為以敏捷方式運用RUP的一個極好的例子。 

對我而言，在運用RUP時的一個關鍵之處在于業界RUP的領頭者們需強調他們的軟件開發途徑。曾經不止一次，我聽到使用RUP的人是在使用“瀑布”式開發過程。根據我在業界的聯系，我知道Philippe Kruchten和他的小組是堅定的迭代式開發信奉者。澄清這些原則并鼓勵敏捷式使用RUP，如象Craig Robert的工作，將對軟件開發有著重要的影響和作用。 

其他參考材料 
關于敏捷型方法有不少文章和討論組，它們可能不會提供完整的方法，但可以給你一個窗口以觀察這個正興起的領域在如何發展。 

程序設計的模式語言（Patterns Language of Programming） 大會經常會有一些材料討論這個題目，這也許是因為許多對模式（Pattern）感興趣者也對適配型和“人道”方法過程感興趣的緣故吧。這方面有一篇早期的一流論文， Jim Coplein所著，收集在 PLoP1 中。Ward Cunningham的Episodes模式語言收集 PLoP2 中。Jim Coplein現主持一個網站， OrgPatterns，以wiki方式收集了不少組織結構模式。 Dirk Riehle在XP2000大會上提交了一篇論文，該文比較了XP和適配性軟件開發（Adaptive Software Development, ASD）的 價值系統。Coad Letter的 七月期比較了XP和FDD。IEEE Software的七月期有幾篇文章論述 “過程多樣性”（process diversity），也提及這些方法。 

Mary Poppendieck寫了一篇很精彩的文章 比較敏捷型方法與精悍（lean）型制造業。 

你是否應走向敏捷？ 
并非人人都能使用敏捷型方法。當你決定走這條路時，你得記住許多準則。但是，我確切相信，這些新方法可被廣泛的應用。只是考慮使用它們遠遠不夠，應該有更多的人來實踐中運用它們。 

在目前的軟件開發中，多數方法仍是邊寫邊改（code and fix），那么，引入一些紀律約束肯定會比一片混亂要好。敏捷型途徑的主要優點在于它比重型方法的步驟要少得多。如果你已習慣于無過程，那么遵循簡單過程應該比遵循繁瑣過程更容易一些。 

這些新方法的主要局限是如何對付較大的項目組。水晶類方法可在最多到50人的項目組內使用。如果超過了這個規模，則還沒有證據或經驗來說明如何運用這些適配性方法，甚至這些方法是否工作都很難說。 

這篇文章至少傳遞了這樣一個信息，就是適配性方法對需求不確定或常常變更的情形是有效的。如果你沒有穩定的需求，那么你就不可能進行穩定的設計并遵循一個計劃好了的過程。這種情況下，適配性過程可能感覺上不太舒服，但實踐上會更有效一些。通常來說，使用適配性方法最大的障礙來自客戶。我認為，重要的一點是讓客戶理解在一個需求不斷變更的環境中，遵循可預性過程對他們是有風險的，同樣對開發方也是有風險的。 

你可能已注意到我說過50人以上的項目組應使用傳統的可預性過程，需求不斷變更的話，則應使用適配性過程。那么，如果你的項目很大而需求又在不斷地變更，又當如何呢？對這個問題我并無一個滿意的答案，我建議你去尋求其他意見。但我可以告訴你，這種情形下事情將會非常困難，不過我想你肯定已知道這一點了。 

如果你要采用適配性方法，你需要信任你的開發人員，并讓他們參與（技術）決策。適配性過程的成功依賴于你對你的開發人員的信任。如果你認為你的開發人員素質不夠，那么你應采用可預性途徑。 

總結一下，如下的因素建議你采用適配性過程： 

不確定或常變更的需求 
負責任的，自覺自勵的開發人員 
理解并愿意參與其中的客戶 

而如下這些因素則建議你使用可預性過程： 

50人以上的項目組 
固定價格，或更確切的說，固定任務范圍的合同 

該用哪個適配性過程？ 
本文論及的這些適配性過程都還很新，我只能提供一些第一手經驗以供參考。我對過程的選擇通常視項目組人數，以及他們愿意遵循多少紀律規章而定。 

如果開發人員有十二個或以下，那么我肯定推薦XP。開發組有可能不會嚴格地把所有XP的過程都走一遍（特別是剛開始時），但這種部分XP過程仍能讓你獲益不少。我認為，用好XP的一個關鍵的部分是要將單元測試（unit test）自動化。如果開發組愿意這樣做，系統就有了一個堅實的技術基礎。如果他們不想這樣干，我不懷疑他們自己就得來做這些測試。 

如果沒有紀律規章，或項目組太大，那么我傾向于水晶系列。水晶系列肯定是敏捷型方法中最輕的，Cockburn特別主張吸取開發中的經驗教訓（而對過程進行調整）。不過，在這種情況下，我仍會用XP來作過程計劃。 

我雖然這樣說了，可是我現在的項目組有40人，我們成功地試驗了許多XP準則，實際上也很接近完全的XP了。所以說，如果有一個有決心有熱忱的團隊，你在選擇過程的時候，完全可以突破一些我提到的邊界條件。 

還有一點非常關鍵，那就是不管你開始時用的是什么過程，該過程都不會是完全如你想象的那樣得心應手，你得不停地對它進行監查與修改以適配你的環境。最后一點，它必須得是你自己的過程，其他標簽都是次要的。 

鳴謝 
本文得益于許多朋友的意見，恕難一一列出。但是，我要特別感謝Marc Balcer， Kent Beck，Alistair Cockburn，Ward Cunningham，Bill Kimmel 和Frank Westphal。 

請記住這是一篇不斷改進的網絡文章。我將附上主要修改記錄，而小改動將不作記錄。 

修改記錄 
2001年11月：更新一些最近的參考材料。 
2001年3月： 加上關于“敏捷聯盟”的內容。 
2000年12月：本文縮寫發表于Software Development雜志。 
2000年11月：更新ASD部分并加上DSDM和RUP的章節。 
2000年7月： 初稿發于martinfowler.com。 

--------------------------------------------------------------------------------

譯后注： 
我去年（2000年）曾參加過一個ECommerce系統的軟件開發工作。這個項目采用了一種類似XP（極端編程）的開發方式，一個迭代周期約為三周，實現一項use case〔use case driven）。開發中特別強調單元測試（unit testing，使用JUnit）與每天的“冒煙測試”（smoke test）。今年〔2001年）初讀到Martin Fowler的網站（http://www.martinfowler.com/）上的這篇 “The New Methodology”時，我正參加一個投資銀行的證券分析信息系統的開發工作，該項目也采用了迭代式開發過程。但由于環境不同，這個項目的迭代周期較長一些，約六到八周。這個項目的另一個特點是開發人員和系統分析員〔business analysts）以及測試人員〔testers）的溝通特別頻繁。讀了這篇文章后，我覺得它能夠讓人從一個比較廣闊而系統的角度來考察一個迭代式項目的運作。 

誠如作者所言，這是一篇不斷改進的網絡文章。我將盡力隨原文的更新而及時更新譯文。此譯文中如有所譯不當之處，望諸位同行不吝賜教。 

原文： http://www.martinfowler.com/articles/newMethodology.html 
譯文： http://members.tripod.com/jian_hu/fowler/newMethodology.html 
2001年12月：譯自原文2001年11月版。 
胡健
Email: jian4_hu2@hotmail.com
Web: http://members.tripod.com/jian_hu

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/