2005年6月，來自信息產業部、北京市科委、中國軟件行業協會的領導，北大、北郵軟件學院的院長們齊聚一堂，和世界五大軟件開發教父之一的matin(馬丁-福勒)先生一起，就目前西方軟件開發領域的新趨勢，以及其在中國的應用展開了熱烈的討論。

　　以下為本次會議文字實錄全文：
 
　　主持人：

　　首先感謝大家來參加這次由賽迪集團協助，ThoughtWorks公司主辦的軟件開發模式研討會，我是ThoughtWorks公司在中國的副總經理，我是郭曉。今天我們研討的主題是成熟應用、敏捷開發。我們都知道中國市場是現在世界上變化最快、增長最快的市場。在這種情況下軟件市場也有對適應迅速變化的要求。這面臨著挑戰，開發成本太高，需求變化又頻繁，如何在這種情況下提高軟件的質量，做不到這點會影響軟件業本身的發展，如果大家找到一個很好的辦法解決這個問題，無論對用戶還是軟件企業都是很好的事。今天我們容幸地請到了世界上最有名的五大軟件開發專家之一馬丁.福勒先生，給我們分享一下西方軟件發展趨勢。同時邀請到了中國軟件協會陳沖理事長、科技部火炬中心軟件處李冰副處長、北大軟件學院的陳鐘院長，北郵軟件學院的宋茂強院長、北航軟件學院的原倉周博士、中國計算機報的高級副總編郭曉女士，CCID的曹方博士和顧建萍處長。

　　下面首先請Martin Fowler和Sidney G.Pinney簡單介紹一下我們公司。

　　Sidney G.Pinney：

　　首先非常感謝大家，今天非常容幸有機會和大家見面。我的名字是Sidney G.Pinney，我是思特沃克中國公司的總經理。主要是兩件事，首先我想簡單介紹一下ThoughtWorks公司，接下來會介紹一下馬丁.福勒過去所做的事情，便于大家的了解。

　　ThoughtWorks公司成立于1993，公司唯一的目標就是創建具有創新性的、實用的定制軟件，同時我們也希望能夠成為世界上所有對軟件有興趣的人才最向往的公司之一。我們主要是做三件工作，第一是咨詢類，客戶主要是全球一千家大公司，給他們做一些架構分析、方法研究等等方面的工作。另外一些主要的工作是幫助其他公司在內部實現敏捷開發的方式，斯坦福大學最近想進行敏捷開發就找到我們公司幫助他們做這件事。最后是我們公司最主要的業務，就是軟件開發本身，我們通過敏捷開發的辦法可以在最少的時間里，用最小的努力，把最高質量的軟件交付給客戶。我們今天有幸請到了馬丁.福勒先生就我們最主要的題目跟大家探討一下敏捷開發方面的問題。

　　雖然我們公司很小，但在世界范圍內知名很高，一些世界知名咨詢公司經常把我們一些大公司進行比較，我們過去的增長在50%以上，過去兩年我們公司增長了兩倍。我們公司的總部原來在芝加哥，陸續在澳大利亞、加拿大、英國、印度、中國開設了分公司。我們公司有很多軟件開發人員，馬丁.福勒先生是我們最優秀的開發人員之一，稍候他也會做主題發言。

　　大家經常會問我兩個問題，我提前回答一下。一是為什么選擇進入中國？二是為什么選擇現在這個時機。我們認為中國現在正處于軟件開發歷史上非常有意思的十字路口上。我們公司定位于以全球為基礎的高端軟件交付公司。我們這種敏捷式的開發方法，對中國現在來說可以非常有效解決現在面臨的很多問題，可以以很小的代價快速開發出高質量的軟件，這也是我們現在選擇中國作為投資方向的原因。中國人非常聰明，目標高遠，有開放性的思想，這個時候把我們公司的產品帶進來，會有非常好的成果。非常有機會來到這里跟大家交流，希望馬丁.福勒先生把敏捷開發這個觀點給大家解釋一下，看看對中國軟件開發有什么好處。

　　我知道你們今天不是來看我的，而是聽馬丁.福勒演講。很容幸我跟馬丁.福勒先生有六年的合作時間，很多人都有這個問題，馬丁.福勒先生在公司具體做什么工作。可以說馬丁.福勒先生給我們公司產生的影響是所有人中最大的，他把很多非常聰明的軟件人才吸引到公司，建立了一個合作又充滿競爭的環境。

　　下面我簡單介紹一下馬丁.福勒先生最近的成果。首先馬丁.福勒先生在面向對象技術領域是世界上知名的科學家之一，他是世界上面向對象技術、軟件模式、UML架構構件語言、重構以及敏捷式軟件開發這幾方面大家公認的領導者之一，同時馬丁是很多知名IT業雜志的編委。馬丁是模式領域的主要科學家，主要研究方向是企業應用及架構方面。在敏捷式開發、極限編程等方面是最具影響力的專家之一，敏捷式開發有一個敏捷開發宣言，他是當時提出這個宣言的幾位科學家之一，是敏捷聯盟組織的創始者和主持者之一。在很多場合做過各種演講，各種會議都希望可以請他來做主題演講。今年晚些時候他會在“面向技術”的大會上做一個主題演講。

　　簡單介紹一下馬丁.福勒出過的書和文章

　　《分析模式》、與人合著的《計劃極限編程》

　　另外《分析和比較分析面向對象》對面向技術設計理念進行綜合總結。

　　《UML提煉》，是第一本描述UML語言的一本書。

　　寫過《重構》這個技術是馬丁.福勒先生提出的，對于軟件業尤其是軟件開發方面產生了很大的影響。最近寫了一本書叫做企業級應用架構模式》。去年被Serve .COM網站把馬丁.福勒先生評為“方片尖”，他同時也為微軟做了一些工作，是微軟架構委員會的成員之一。此類介紹再說幾個小時也沒有問題，馬丁先生在過去幾年為我們公司的發展做出了巨大的貢獻，今天很容幸請到馬丁.福勒先生跟大家交流，包括西方軟件開發方面的經驗。我們非常容幸可以請到各位、專家領導來到會場，希望可以共同分享我們所想到的西方的經驗能對中國帶來的好處和影響。

　　謝謝大家！

　　Martin Fowler：

　　可能Sidney先生把我說得太好了，我有點不敢當了。如果大家感到失望的話，請原諒我。我今天想把主要的精力放在探討敏捷式開發方面。

　　軟件開發行業目前同時存在兩種情況，它既是一個非常成功的又是具有很多問題的行業。一方面軟件已變成我們在日常生活中不可缺少的部分。有些可能不是非常明顯，直至有問題出現的時候才發現。一個非常有名的例子就是幾年前有家航空公司的計算機系統有一天不能正常工作，結果造成了很大的混亂和巨大的經濟損失。我并不是要仔細分析問題的所在，只是想指出軟件在各個行業中扮演的角色越來越重要，互聯網的使用已極大地改變了人們的生活、工作方式。在西方，普通客戶購買東西的過程中，經常把決策的過程使用在互聯網上。所有這些軟件所帶來的影響，對于三、四十年前的人來說幾乎是不可想象的。

　　盡管有成功的方面，但軟件開發過程中還是經常會遇到一些問題，很多企業在軟件方面花了大量的金錢和經歷，但并不是很清楚軟件到底能給他們帶來什么。一些調查發現世界上很多軟件項目其實都失敗了，也許這是因為在軟件開發過程中，很難定義成功與失敗這兩個不同的概念。我們在軟件界就是注重怎么預見軟件開發的不可預知性，我們想象出了各種各樣的技術、工具以及流程使得軟件開發的過程變得越來越可以控制、預測。這種方法有一個很大的問題就是無法有效評估軟件開發過程的有效性。在很多其他的產業界，可以用簡單的辦法評價過程的進程及有效性，但是對于軟件開發過程，很難用一種標準來衡量它的進度和有效性。一個結果就是很難有效判斷兩種有效的方法哪種更好，使得軟件技術、工具以及流程方面的很多討論都被這種現象所左右。軟件開發的過程中有各種問題，并不是新提出的概念。在六十年代末期的時候北約一個軟件開發室提出了軟件危機的概念，因此他們提出了非常有紀律性的方法即軟件工程學，試圖從電子工程學、技術工程學提煉出一些東西來用于軟件工程學，他們想從中提煉出一種方法，使得軟件開發的流程更有預測性。過去三、四年間這種工程學的方法一直為大家普遍使用。但軟件業的人在做軟件的過程中發現這些方法并沒有減少軟件開發過程中遇到的問題，對于這種現象有很多解釋。近年來有人發現軟件工程學里一些基本的假設是不正確的，并使用了一些新的開發方法，我們將其統稱為敏捷式開發。

　　敏捷式開發有很多特色，今天我主要集中介紹兩方面的特色，我會重點介紹一下它就軟件開發文化有什么樣的影響。前不久我在我的網頁上發表了一篇文章“新方法”解釋我對敏捷式開發的看法。下面我介紹一下敏捷式開發與傳統開發相比最具特色的兩點。

　　敏捷式開發采用適應性方法，而傳統的軟件工程學采用的是預測性方法。敏捷式開發是以人為主的，而傳統的工程學是以過程為主的。我下面詳細地介紹這兩方面：

　　適應性和預測性的區別存在于軟件工程學對軟件開發過程的描述中。在傳統的工程學里，核心的概念就是把設計和構建這兩個過程分開進行。最開始一個階段叫設計階段，在這個階段所有跟軟件設計相關的重要決定就已做出了，而且以完整的形式描述出來。這項工作通常是由一小部分非常專業的人來做的，而且他們所花的時間和精力在整個項目中占著很小的一部分。這項工作完成以后，這些設計的結果，從建筑學的角度就被“建筑公司”拿去，按照設計的結果一步步構建。在描述清晰的設計圖紙的基礎上，你就可以據此對構建過程進行詳細的規劃，并進行成本的預測。但是現在大家對這種過程是否非常適合軟件開發行業存在著爭議。這里經常會問到一個問題，就是這個過程要花多長時間，對于這個問題有各種不同的回答。在傳統的工程學中設計過程在整個項目開發過程中只占10%左右的時間，但是很多軟件開發權威機構都認為軟件設計過程在整個開發過程中占百分之四、五十的時間，它明顯告訴我們這里有些東西是不對的。在軟件開發的過程中，我們很難想象，如何真正把設計和編程完全區分過來。軟件工程學領域，所有在這里從事工作的人員，都把設計的過程想象成用圖表、圖象的方式來描述結果的過程。很多人都有這樣的經驗，沒有經過編程而是直接想象出的設計，在進入編程階段有很多地方是錯誤的，需要改正。而且從我的觀點來看，幾乎沒辦法進行有效的設計。還有一個更重要的問題就是說，軟件本身的需求是在變化的。一個項目在開發過程中需求會出現變化，需求的變化從根本上推翻了工程學方法所建立的一個基礎。當工程學的人盡量減少或者控制系統將來發生變化的可能，他越這樣做問題就越容易出現。既然我們沒辦法避免變化的發生，那么我們就想找到一種新的方法能夠更有效地適應這種變化現象。這也就是敏捷式開發方法所要達到的效果。

　　最開始的時候，軟件開發的過程，我們應該想到軟件開發和其他的工程學是完全不同的學科。首先我們想象一種疊蓋式、循序漸進的軟件開發方法。軟件的構建過程中是以小量的疊蓋過程增加，而在這個過程中軟件一直處于可使用狀態。我們ThoughtWorks在軟件開發的過程中每兩周都會得到一個可以工作的軟件。這種非常短的循環，使終端客戶可以及時、快速地看到他們花錢構建的軟件是一個什么樣的結果。使得客戶可以更有效地參與到軟件開發的過程中來。這同時也解決了軟件開發中非常重要的問題，就是開發人員和終端客戶交流的問題。這也使得軟件開發本身可以更有效地適應業務本身需求的變化。對于一個發展變化非常快的國家，比如中國這種方法的好處是顯而易見的。這個方法從理論上講并非更簡單，需要在實踐的過程中學習如何使用疊蓋式的開發。這種東西就是當你真正學會如何使用疊蓋式開發的時候，才能發現它真正能帶來的好處。如果真正在軟件開發過程中實現疊蓋式的開發，同時需要軟件行業本身，以及業務部門本身共同的努力。如果可以實現軟件開發部門和業務部門的緊密合作，本身就可以避免西方軟件業發展過去所犯下的一些錯誤。另外一方面敏捷式開發是以人為核心的方法，而不是像過去工程學是以過程為核心的方法。這種現象是過去一些人專門研究軟件開發的過程專門有一些實踐。經常發現一個現象，軟件項目開發的成功最核心的因素是這個軟件團隊里有非常優秀的人才的協作。這既意味著團隊中有非常優秀的個人，又意味著團隊中的人能有效地進行協作。這種協作方式通常情況下是跟這些人如何處理他們之間的關系有關而不是采用什么樣的過程。工程學當中他們所采用的過程是盡量減少人在這個過程中所扮演的角色。在敏捷式開發中，提出的觀點就是人在整個軟件開發當中是最重要的因素，至于在這個開發過程中使用什么樣的方法是次要的因素。這對于軟件開發文化來說意味著什么呢？首先它意味著在提高軟件開發效能中最重要的一點就是如何提高個人的能力，其中教育扮演著非常重要的角色。這也同時意味著軟件開發團隊在這個過程中是被如何對待的。很重要的一件事是如何為軟件開發人員提供一個有效的環境，讓他們為軟件開發行業做出最大的、有效的貢獻。而且還要提供這種環境使軟件開發人員與終端客戶進行有效的交流、合作。

　　我在ThoughtWorks工作發現這種方式可以造就一種特別的企業文化，在西方擅長軟件開發的人員往往都是一些怪才，這些人是真正喜歡軟件、喜歡編程的。他與其他的人往往有不同的想法和對生活的追求，很多程序開發人員和客戶進行交流過程中，遇到的困難真正的核心所在就是文化上的差異。我不知道這種文化上的差異在中國是否也出現，在印度已出現了這種情況。非常重要的一點就是認識到軟件開發人員和終端客戶之間交流問題的所在。就像剛剛提到的，沒有一個真正可以衡量到底不同的軟件開發方法哪種好、哪種不好。這就是因為我們不能非常有效的，以一個非常公正的標準來衡量軟件開發哪個更有效。包括我在內，從事敏捷開發的人員，會發現在軟件開發過程中敏捷開發是非常有效的方法。西方軟件業敏捷開發還是非常少數的團隊，但其增長速度非常快。

　　我們希望在新的軟件開發環境里，這種新的方法可能有更快的增長。如果能在軟件開發過程中有效地避免開發客戶和開發團隊交流的問題，那么你就可以避免很多在西方軟件開發中遇到的各種問題，當然同時也會發現一些其他新的問題。

　　我就簡單介紹到這里，下面跟各位領導、專家進行討論。

　　(討論階段)

　　陳鐘：

　　馬丁做了一個精采的報告。在中國軟件發展階段，引起了全球各行各業的矚目，包括全球軟件業的一些方法，以及軟件公司的發明人、創始人、傳播人都紛至沓來。在最近不到一年的時間里，包括馬丁在內，一些世界級的大師我都有機會見到。今年國際軟件工程大會已開了29屆，從95年我們就開始參加這個會議，十年間我們討論的問題，短短的一年內很多大師紛紛來到中國，中國企業級人士也逐步關注、參與進來。大家經常提到高長難問題，軟件開發難度高、研制周期長，周期性難保證。現在講軟件工程的時候，大家也面對這個問題，剛剛馬丁也提到這樣的問題，我們現在有大量成功的案例，也有大量失敗的案例，不斷出于新需求的發展、出于技術的進步，出于改善陷在改進我們原有的系統。現在軟件工程要由手工作坊式變成工業化的方式生產。

　　馬丁剛剛講敏捷式開發更注重人，這對傳統工程學是一種叛逆，從個人角度我是贊同的，但這里又有一些困惑，成功、偉大的軟件總是有一個偉大的設計師。可以舉出很多的例子，包括應用軟件、定制軟件開發，很難相信一個沒有經驗的人可以一下做成。一個成功的軟件跟一個優秀的軟件設計者是聯系在一起的。但軟件工程學確實有很多原理要告訴大家，做軟件不是很隨意的。前面設計上的一點點缺陷，就可能帶來今后非常大的損失，有很多被驗證過的軟件工程的原理。那么到底軟件的構造是藝術還是工程？馬丁也講到了人非常重要，教育體系也是非常重要的，那么這個過程中是教大家把它作為藝術看待，還是把它作為工程來看待。希望馬丁就這個問題再深入闡述一下他的觀點。

　　馬丁.福勒：

　　首先我同意在軟件開發過程中軟件設計過程是非常核心的部分，敏捷開發社區當中的所有人都同意這個觀點。《敏捷宣言》中有十二個基本點，這個觀點是其中之一。有一個最核心的問題，就是到底設計要和編程同時進行。這也是我的觀點，也是很多其他人的觀點，就是兩者是結合在一起的。對設計活動本身有一些不同的觀點，比如說敏捷開發人員他們認為設計是不斷進行的一項活動，這就使得我本身受到了很多影響。我把注意力放在重構概念上，是因為我認為軟件設計是在編程進行到一定程度后然后再進行設計活動，這也是從事敏捷開發人員所關注的一點，想開發出這種技術，讓設計概念能夠不斷演變。在不同的技術中最核心的一點就是測試概念，這是從極限編程中提煉出來的概念。很多從事極限編程人員，發現在實際的操作中概念測試系統開發使得系統的設計可以不斷演變，在這個過程中扮演了很重要的角色，這也是我們ThoughtWorks內部開發軟件過程中所發現的一點。如果說從哲學的角度上講，到底軟件設計是藝術還是一項工程呢？我很難清晰地說都是或者都不是。我已經參與過很多類似的爭論，到底用什么樣的比喻來形容軟件開發。也許我們要用一種比喻的方式形容軟件開發，而把軟件開發本身當做一個獨立的東西來對待。

　　陳鐘：

　　馬丁在報告中多次提到“變化”，而且他也講到與其說我們不能夠保證他不變，我們應該找到一個方法去適應這個變化。實際上這個變化確實使得我們現在這個世界非常豐富多彩，所以我們希望變化。但是控制變化無論是從工程學還是藝術角度講都是非常重要的。馬丁也提到開發人員跟用戶的溝通有很多方面與變化管理相關。我還想問馬丁一個哲學問題，世界在變，不同的方法學也在變，到底有什么是不變的，讓軟件從業人員活得越老位有價值。而不是五年、十年以后，什么東西一變，他就完全沒有價值了。讓教育系統發揮作用，只要教他一個什么東西，他以后就越來越有價值，薪水也越來越高。

　　馬丁.福勒：

　　我上個星期在西安做演講的時候，有一個西安交大的學生就問到一個類似的問題。當時我做了一個類似的回答，對學生來講，教給他們最重要的東西就是從業生涯中要不斷地學習。教給學生怎么真正地掌握這些變化的核心因素所在，使得學生可以有效地根據變化利用新的技術做這些事。我不知道怎樣解釋，變化是一個絕對的過程，但是這個問題我非常有興趣，因為我做的所有工作中很重要的一點就是在變化中找到一些部變的東西。我做這件事是出于一種非常自私的原因，因為作為作者，我希望自己寫的書可以長時間熱銷。這也就是我為什么集中精力做一些設計模式方面的工作，把設計當中的一些概念以模式的方式提煉出來，這些模式可以運用于不同的編程語言中。這也就是我為什么也在尋找設計的方法，使得它能夠在不同的技術環境下重復使用。比如我個人認為面向對象設計技術在軟件界很長時間內將會處于核心位置，測試開發技術也將在很長時間內存在。對學生來說很重要的是讓學生經歷各種各樣不同的技術。比如在敏捷開發過程中，人是第一位的，過程是第二位的，所以作為一個個人來說，應該可以找到各種不同的過程，找到真正適合自己的過程。因為我們沒有非常客觀的對軟件開發有效性進行衡量的標準，只能是遵循軟件開發人員認為最有效的方法。比如對學生來說很重要的一項技能，就是快速、有效地測試、評估各種不同的方法，從而找到最適合自己的方法。

　　陳鐘：

　　我第三個問題是敏捷開發現在還是“少數民族”，盡管在教學中分配了一定的時間向學生介紹這種方法的存在，但尚未形成系統教育。在大家用得不夠普遍的情況下，馬丁說這個方法非常有效，但對方法度量沒有客觀標準，你希望更多人采用敏捷開發的方法，要采用什么方式來說明其有效性？把這個方法用好，把軟件開發做得很好，與人的關系是很大的。我們知道在傳統的軟件工程領域中，我們也會注意到一個人生產率的高低跟它的一些素質、背景有很大的關系。敏捷開發方法掌握與否是否也跟個人的個性和生產力有很大的關系？在這種情況下，馬丁是什么樣的觀點？一個人是否適合掌握這種方法，是否適合做軟件開發，是否可以通過他的IQ或EQ值告訴他一輩子做軟件或者說你不適合你就別做了。

　　馬丁.福勒：

　　先討論第一個問題，就是如何說服其他人敏捷開發是一種有效的方法，在軟件開發過程中沒辦法絕對地判斷一個方法比另一個方法好，就是因為我們沒辦法有效測量軟件開發本身，只能依賴我這樣的人，從我主管的角度來說這個方法好在哪里。我說的東西跟他們經歷的經驗有類似的地方。有些人可能會對我剛剛說的一些想法有興趣，想去試試，這就是方法傳播的過程。我們看極限編程發展的過程，在最開始的時候是兩個人在描述他們的一些心得和經驗，有些人看了這些東西發現這些想法有道理，就逐漸嘗試他們介紹的東西。當然并非所有嘗試的人都成功了，但成功的那些人就會把自己的心得和體驗介紹給其他人。這種傳播方法乍一聽可能很遺憾，如果有一種客觀的測量方法當然更好。但我們必須意識到軟件開發過程是很獨特的，軟件并不是唯一一個難以用絕對方式測量的行業，商業、教育業都面臨同樣的問題。在其他行業即使沒有一個客觀的衡量標準，人類在這方面也有很大的進步。當然這不及有一個客觀、有效的測量方法好，但并不意味著沒有一個良好的發展方向。怎么衡量作為一個個人是否適合軟件開發，我可以簡單介紹一下ThoughtWorks公司是怎么做這件事的。我們將其作為業務衡量中非常重要的過程，我們從不同的角度和層次來衡量個人軟件開發的能力。首先就是看他們是怎樣編程。我們也通過其他的測試方法測試他們的邏輯能力以及其他方面的能力。還有很重要的一點就是測試、衡量他們與其他同事進行合作的能力。在軟件開發行業中，非常重要的能力就是怎樣在一個團隊中與其他人進行協作。這既意味著與其他技術人員進行合作也意味著與終端客戶進行合作。對于新來到這個環境中的人，很難對他做出一個非常正確、客觀的評價，就像我們做其他事一樣，我們盡最大的努力去做。至少從目前的結果來看，公司里的人大部分是符合軟件開發過程的人。我擔心的是沒有進入到我們公司的其他人其實也可以進行有效的軟件開發的。一個非常有意思的現象，計算機專業背景對于軟件開發人員來說并不是非常重要的環節。我們公司最高層的開發人員都是其他學科的背景，像郭曉過去在北大學的是化學而不是計算機。最終的衡量方法是看一個人在一個項目上的開發過程是如何進行的。

　　陳沖：

　　什么方法對我們的軟件開發更便捷？中國應用敏捷開發的時機是否成熟？下一步軟件開發會往什么方向走？因為現在軟件開發原代碼越來越長，質量也難以控制。以前我們控制過程，使其越來越規范，我們現在基本講的還是軟件開發的過程。軟件工程是控制人員，但軟件開發人員是最難控制的，而且還不能消磨了軟件開發人員的創新性，而這兩者是相矛盾的，如何協調？

　　馬丁.福勒：

　　第一個案例請郭曉講一下。

　　郭曉：

　　我們公司之所以做敏捷開發是五、六年前我們公司有一個非常大的項目，給一個租賃公司做一個邏輯軟件，我們用傳統的方式做了半年的時間，但是客戶有很多新的需求，這個項目正處于失敗的邊緣，如果這個項目做砸了，我們公司也就完了。這個時候我們請到了馬丁.福勒先生，用敏捷開發、極限編程來做。當時我們印象里敏捷開發都是在二、三十人的團隊實施，我們公司可以說是第一個將敏捷開發用于大團隊的開發，我們把文檔全部扔掉，采用敏捷開發方式，只用6個月的時間客戶就看到一個核心軟件。我們公司現在大小有上百個項目，小到二個人的項目，大到幾百個人的項目，都是用敏捷開發的方法做的，成功的案例有很多，我們可以挑出一個來做進一步的探討。

　　馬丁.福勒：

　　我補充一點，大家手里的資料中有一個CD，里面有一篇文章進行相關的介紹。關于第二個問題，我認為中國沒有很大的歷史包袱，在很大程度上對敏捷開發是一個優點。一些大的公司存在很多歷史性的問題，而在沒有很多歷史包袱的情況下，采用疊蓋式開發是非常容易執行的。各個不同的國家和機構軟件開發的歷史對其到底能否使用敏捷開發沒有什么影響。我看過一個研究報告，其中指出測試驅動開發對于一些經驗不多的軟件開發人員更為有效，在新的環境中使用新的方法可能更好。比如印度它在CIF方面做得很成功，如果我們不想出一些新的方法就很難超越他們。通過一些新方法不會總是處于跟隨狀態，而是可能超越過去。關于第三個問題，下一步我們會做哪些工作。首先要認識到如何進行有效的軟件開發，事實上在這方面存在眾多不同的觀點，沒有人真正知道或者回答哪個是最有效的方法。我的這些觀點是從我過去的經驗和個性總結出的一些東西。而且是建立于其他一些從事敏捷開發的人的經驗的基礎上。我們過去得到的最重要的教訓，就是不要把所有的精力都集中于一個方法上。我認為其中最主要的成功因素，就是使各種不同的方法都可以實施，讓他們之間互相競爭來實際找到最好的方法。過去很多人是通過其他人的成功應用來找到最適合自己的方法，從外部來看這可能是一個非常混亂的方法。從人類歷史來看，競爭、合作同時存在的多元體系通常情況下可以得到最好的結果。中國是一個非常大的國家，有能力嘗試各種不同的東西，這對我們來說是一個很好的條件。所以我的建議是在聽我說的同時也聽一些與我不同的意見。

　　宋茂強：

　　去年《軟件工程師》介紹過馬丁先生的方法，我個人非常感興趣。我有十多年的軟件開發經驗，我本人也喜歡使用自己的方法開發軟件，而不愿意受死規矩的約束。我覺得敏捷開發是一種比較好的開發方法，敏捷開發可能適合于定制軟件，因定制軟件客戶對需求不明確或者在開始時不夠明確，因此敏捷開發比較適用。如果我們開發要求明確的系統軟件，敏捷開發可能就不是最優的選擇。所以我們的軟件企業在選擇的時候要根據自己的特點。中國目前定制軟件的需求非常大，尤其在信息化進程下，很多人不知道自己要做成什么樣，但他又需要信息化，敏捷開發是我們可以參考的方法，不要墨守成規。國內很多企業要通過CIM認證，我有一個看法是看企業本身從事什么樣的開發，如果是從事定制軟件的開發，那種方式成本太高，而且也很困難。我想提一個建議，這個方法要想讓更多人使用，能不能把這種方法帶到課堂中，作為課程向學生教授。因為北郵的學生出來之后大量地面臨定制軟件的開發。

　　馬丁.福勒：

　　簡單回答是的，其他一些大學已經在講敏捷開發，我們ThoughtWorks本身也在做類似的工作。我們公司在印度有一個分公司，與印度一些大學合作教授敏捷開發的課程，有一位主要教授課程的富蘭克.喬治先生現在正在上海。富蘭克.喬治也在北卡羅來納大學教授過類似的課程。除我們公司以外，還有其他一些人在做類似的工作，比如約翰先生在大學里教類似的課程。我的建議是請相關人員跟你談談心得。

　　李冰：

　　我有一個問題，現在敏捷開發是一種比較新的方法。它有幾個比較關鍵的地方，如果要做好一件事，各方面都要做好，一個方面的失敗就可能導致全盤失敗，那么使用敏捷開發方法要注意哪些方面？

　　馬丁.福勒：

　　我認為在敏捷開發的過程中不光是包括敏捷開發，在其他所有軟件開發過程中如何有效地與客戶進行交流是非常重要的因素。比如敏捷開發中采用疊蓋式的方法，就是快速地把軟件交給終端客戶，讓他們不斷地看到開發結果。使用這種疊蓋式方法最大的優點可以很早地看到項目開發中的風險所在。因為你能夠不斷地得到可使用的軟件，并交給客戶使用，這個時候就可以判斷軟件使用過程中質量如何，有效性如何，是否是客戶真正需要的。敏捷開發使用更短的循環方式，提高反饋的效果。在ThoughtWorks我們一般是使用一周到二周的疊蓋循環。對于軟件交付成功最重要的一點是交到客戶手中的軟件是否是其所需要的，從而不斷得到客戶的反饋。

　　曹方：

　　我有兩個問題，第一在中國軟件產業市場中最具有生命力的市場是電信、金融、證券服務、網絡游戲。敏捷式開發方法在這些市場占有率非常高的行業中鮮為人知，那么如何解決市場認知、應用？軟件技術有一個很重要的發展趨勢，就是面向構建的開發方法，面向構建的開發方法和敏捷式的開發方法，交匯點和本質的區別是什么？

　　馬丁.福勒：

　　無論是敏捷開發使用還是其他方法的發展過程中，很多時候剛開始只能找到少數人愿意嘗試。通常情況下他們使用這些方法的原因就是在一些人介紹后他們發現其中的一些道理與他們所想的是一致的。他如果通過這些方法真正解決了所面臨的問題，那么他身邊的人才會愿意使用這種方法來解決他們所遇到的問題。西方敏捷開發的傳播基本是以這種方式實現的。對面向構建的設計來說，最主要的是我們到底怎么看待構建是如何出現的。在構建過程或者服務過程現在有兩種最主要的意見。我所見過的第一種方法就是先把基礎搭好，然后在這些構建的基礎上建立新的應用。第二是收獲的方式，就是先把應用搭建起來，從中再提煉出有用的構建。包括我在內很多從事敏捷開發的人都比較傾向于第二種方法。我看到過很多采用構建方式的失敗案例，很多構建搭建起來后發現它不能被有效使用，當發生這種事的時候，之前所做的一切都沒有意義了。而收獲的方式，當你知道它在這種情況下已有效地使用了一次，從而知道以后能否從中提煉出構建以備以后的使用的，即使提煉失敗，至少這個項目也是成功的。

　　宋茂強：

　　我的學生也做過在使用中提煉構建，這是一個非常好的方法，最近我有一個學生剛寫完一個軟件。

　　原倉周：

　　我國多是中小企業采用的軟件多是定制，所以敏捷式開發的確很適合中國。敏捷開發的方法是以人為中心，對人的能力沒有一個準確的評價方法，中小企業人員流動非常大，如果把過程放在第二位，當人員發生變動，如何用其他人來頂替？

　　馬丁.福勒：

　　我在西方也見到過很多類似的問題，因為敏捷開發是以人為主的過程，這個過程本身就有問題，你怎么找到合適的人，怎么留住合適的人做這樣的事。有一個最基本的問題就是問自己為什么這些做得非常有效的人要離開這個地方呢？無論使用什么樣的方法和技術，作為一個企業來說如果不能留住人，無論如何是不能成功的。這個過程中最主要的一點不是找到什么樣的人，而是找到人員離開的原因，把人員留住才是真正有效的方法。這種現象背后肯定有很多具體原因，而這個原因每個具體項目都不同，所以很難做出很普遍的回答。我經常遇到一個問題，我發現在這個過程中如果把一個人作為隨時可替代的單元，通常會加劇人員流動的現狀。

　　謝騰翔：

　　馬丁先生今天給我們帶來了一些新的知識。在中國從軟件工程的角度，在某些程度上已落后于某些國家，與印度來說我們也相對有一個落后，今天我聽到你講了敏捷開發，我想做一個總結，只是個人之見可能不一定對。目前中國企業要開發軟件首先是要占據市場，有效地管控其成本和費用，對軟件開發企業來講，這是一個根本。您剛剛講到敏捷開發與傳統的軟件工程相比，在快速占領市場和節約成本費用方面能否有一個較大的提高，有一個比較明顯的推進作用，那么這個比例跟傳統相比能提高多少？中國一些企業也在做敏捷開發，微軟的開發模式也是疊蓋的，這是敏捷開發最核心的部分。我原來的公司是做開發，現在我們做測試，我覺得中國公司說是遵從軟件工程，其實是靈活應用，在某些方面也是遵從了軟件開發的理論，我們說軟件開發是過程控制，不到一個階段是不能跨越下一階段的。我不知道印度的情況如何，中國很多企業在需求變化過程中也是在不斷重構，實際上它也是疊蓋，我們經常開發一個原型，再不斷開發新的功能補充進去。傳統軟件工程和敏捷開發是否有特別本質的區別？有必要將兩者明確地區分開來嗎？是否可以說兩者是軟件工程中不同方法的選擇或者改進？

　　馬丁.福勒：

　　很難有一個定量的衡量，軟件開發企業最難的就是衡量過程。工程學和敏捷開發之間的區別，所有的方法學之間都有一個量(度)的區別，雖然是疊蓋式方法有很多類似的地方，但工程學和敏捷開發有兩個核心的不同點，第一對于變化觀點是控制還是接受，第二對于人在這個過程中起到作用的評價。如果從傳統開發和敏捷開發有一個過渡的曲線，過渡期間有一個突變的過程，就是對變化的態度和對人的態度，這兩點是非常重要的變化。

　　郭旭：

　　剛剛講了很多敏捷開發的優勢，我們也確實認識到在中國的環境中對敏捷開發的需求非常大，但它有沒有什么缺陷？比如在軟件交付之后我們用傳統的方法開發軟件，里面有很多文檔，用戶可以接過來。而敏捷開發是以人為核心的，那么如果人員發生變動以后，是否對客戶造成影響？

　　馬丁.福勒：

　　傳統來說，任何新出現方法的最大問題就是找不到問題所在，實際上很多缺陷都是在直接使用過程中發現的。比如傳統上在幾年前，很多人認為敏捷開發有一些缺陷，但近幾年發現事實并非如此。比如說過去有些人認為敏捷開發不適用于大項目，而我們公司在大項目上使用這種方法證明這種缺陷是不存在的。我們想可能還需要一段時間進行探索，才能知道敏捷開發的缺陷在哪里。關于交付以后文檔的問題敏捷開發要盡量減少這些文檔的存在。傳統方法交付出的那些文檔到底有多大作用？我們ThoughtWorks的一項工作就是給遇到麻煩無法進行下去的項目提供幫助，我們在半途進入項目以后，發現他們制作出的文檔實際上對理解這個項目沒有什么幫助。大部分的文檔不是沒有完成就是非常過時無法描述現在項目的狀態。實際上在很多時候我們發現很多文檔對于不是使用這種文檔的人心理上是一種安慰，但有效性并不一定非常高。

　　以下為媒體問答實錄

　　賽迪網記者：敏捷開發對軟件跨平臺的移植、升級的需求能否適應？敏捷開發是測試驅動的開發思路，現在還有模型驅動開發思路與之競爭，您作為測試驅動的倡導者，如何看待模型測試思路？

　　馬丁.福勒：對于跨平臺的移植來說通常存在兩種情況。最核心的一點就是從功能角度講，移植前后是否一致。我自己經歷過很多移植性項目，很多時候雖說只是做一個移植，但功能本身也會做很大的變化。通常情況下，很多時候客戶會發現在過去的系統中有些功能是不需要的，而有些功能并不存在。在這種情況下敏捷開發的方式是很適合于功能變化的移植。移植前后所有功能是完全一樣的，確實不一定是傳統敏捷開發能夠真正適應的。一些敏捷開發中的最佳實踐也是可以使用的，比如你可以把所有的需求以測試的方式提煉出來。很多項目都是使用這種方式而且非常成功。而且使用這種疊蓋式方式，也能夠從項目進程的角度看移植進程有多快。如果說這個過程中你只是純粹重復以前的功能，沒有加入新功能的話，確實跟客戶交流的方面就不是那么重要了。

　　記者：您剛剛說面向對象的技術將在未來很長一段時間存在，為什么？

　　馬丁.福勒：首先從我個人以及很多其他人的工作經驗，OO是一種非常有效的設計、實施軟件的技術。從另一方面，這些新出現的主流語言比如JAVA等等其核心都是使用OO技術。事實上我們在OO技術使用過程中還處于非常原始的階段。雖然以OO為基礎的語言已經不斷地出現，而且成為主流編程語言，但在使用這些語言進行編程的時候，很多人還是以面向過程的方式來使用。

　　IT經理世界：敏捷開發是否對做外包的企業有幫助？

　　馬丁.福勒：在印度外包是非常普遍的，我們在印度有一個分公司，專門做歐美外包。我們跟其他公司的區別是即使在做外包的過程中也基本使用敏捷式開發。我們在實踐中發現敏捷式開發對外包也是非常有效的方法。如果有機會一定要跟我們富蘭克.喬治談一下，他有一個案例來說明使用敏捷開發與不使用敏捷開發的區別。在跟客戶溝通的過程中，我們在開發成本和時間上都比競爭對手少三分之一，我們贏得這個項目，并成功交付。這個公司對外包流程非常熟悉，他覺得我們是否估計錯了。因為不是客觀的標準，他們用CIM對這個項目進行了重新估算，得到的結論是他確實需要這么多時間和人做這個項目。就是說實踐中敏捷式開發比他們估算的方法更快，而且用的人要少一些。

　　記者：現在中國有很多典型的外包企業，拿到的是設計，他要做的就是編碼，那么把設計和編碼融合在一起的敏捷開發模式如何應用？

　　馬丁.福勒：一個最簡單的回答，在這種情況下沒辦法真正使用敏捷開發，因為你對這個項目沒有真正的控制權。最重要的一個錯誤已經犯下了，所以在這個時候你沒辦法修改過程。雖然這個項目不能真正地使用敏捷開發的方法，但敏捷開發的方法有很多最佳實踐，從根本理念上有一些方法，有些是從編程中，比如持續集成，測試驅動開發等等。敏捷式開發跟其他方法不同的在于它不光是一個方法學，還是編程中如何提高質量的具體操作，在極限編程里提出的，這些東西都是可以借鑒的。它跟設計沒有什么太大的關系，但你在使用過程中可以真正地提高程序的質量，并非要么是敏捷要么不是敏捷。在實際開發的過程中，你還是可以使用疊蓋式的方法進行內部的開發，雖然你不能對設計進行大的修改，但是疊蓋式的方法還是為提高你的質量，加快速度提供很多幫助。

　　主持人：由于時間的關系，我們的媒體提問就到這里，再次感謝馬丁.福勒先生做的精采演講。謝謝大家！