林教授：我先用英文來翻譯一下(speak in English)。歡迎您，你被我們稱作教父。我們等你這次演講足足等了一年。我們非常遺憾地錯過你一年之久。
Martin：我保證，我那天非常希望能在酒店裏面進行那一次的演說。
林教授：有趣的是“教父”說要一遍一遍地思考它。我們在軟件行業已經工作了很多年了。我們從C++,到Java……所有這些語言都經歷了比較長的時間。教父介紹給我們不同的語言。但是從我的這類接受傳統教育的軟件業者來看，我們接受的是UML和CMM，來自於RUP。人們都希望能非常嚴格的執行，並且實現起來並不容易。有一些人就在想，爲什麼大多數方法論都來自於美國。很多人從傳統的方法學，轉到敏捷，轉到極限編程，原因是什麼呢？這個我要問問您。
Martin：我不認爲現在大多數的這樣的轉化，和改變都來自於美國。爲什麼敏捷真正的得到了重視？我想是因爲學習的過程。當人們拿到一個大型繁重的方法的時候，他們不願意去使用。當你去到IBM全球服務部門時，他們會給你看很多的文檔，但是並沒有看到任何真正的產品。另外，我們發現，工程仍然會存在失控的問題。有的時候，我們很晚纔會意識到項目要延期了。重型方法論的另一個特點在於它吸引傳統工程的開發，認爲軟件開發是需很準確的預計的。告訴開發者你需要的是什麼，之後花幾年時間得到一個產品。處於理想狀態的時候，這樣做是可以的。然而事情並不像想象的那樣。因此，我們得到了學習。重型方法中指導的一些方法和實踐，實際上不應該被採用。所以我們需要尋找新的方法。在你去探索的時候，你並不知道你走到了哪裏，是不是接近了終點，我們就在這樣探索着敏捷過程的方法論。我非常幸運的處在一個採用敏捷方法的一個公司。但是現在我們還看不到很多的改變。我現在仍然處在這樣的研究過程，我們現在做項目的方式已經和三年前不同了。我相信，再過幾年，又會有一個不一樣的變化。有的時候，人們會談起幾年前的一個項目，然後會說到那是多麼可怕的一個項目，他們的工作是多麼糟糕。我想這是很好的一件事情，因爲你可以看到你已經學會了很多。你可以看看你五年前寫的代碼。如果已經不能理解了，這不是一件好的事情。
林教授：非常好。我曾經在美國工作了很多年，當時我們有大概75%的項目都失敗了，尤其是c++的。你同意麼？
Martin：因爲很多人對“失敗”這個詞有着非常不同的定義,我如果這樣回答就太狡猾（tricky）了。軟件有很多不一樣的分工, 很多人在傳統的計劃驅動的項目裏面失敗了，是因爲他們超過了預算。在敏捷方法裏面，我們用不同的方法看待失敗。如果項目沒有（向客戶）交付價值，那麼它是失敗的。所以一個項目可能是被延期，超過預算，但是它向客戶交付了價值；也可能是按時，在預算內完成，但是卻沒有向客戶交付價值。這兩個定義是不一樣的。大部分的項目都是令人失望的，我們可以做得更好。大部分的項目我們可以進行一些我們正在進行的實踐，使它變得更好。我們這在致力於軟件這個行業，希望能促進它的發展。
林教授：還有什麼問題麼？(開始回答關於正楷與草書的問題)現在Martin Fowler來這裏是一個很重要的時刻。我總是感覺到我們軟件學院的同學們可以思考一個問題，爲什麼這些人早年時受過嚴格的訓練，寫的書也是關於UML的，你不能批評他們不懂UML這些很嚴格的東西，他們本身就是UML的專家。但是，現在整個的思潮像鐘擺一樣轉向了XP這一邊，這一點值得我們深思。當然跟他們的環境有關係，還有一點，他們這些人，我們接觸多了就發現，他們的反思能力特別強。不固執於認爲自己對的一方面，他們始終在前進，去調整自己，所以他們發散性的思維和反思能力是值得我們去學習的。但是，問題是，我說過的那句話，中國軟件業的現狀，2006年，就成熟度講，大概相當於美國的1986年，整整20年的落差。我們的起步是從一個農民的國家，一個完全手工作坊的時代，要改變到大工業，符合世界軟件業的水平，有很多事情要做。正如現在有人開車，中國人開車和美國人開車完全不一樣。我們最主要的，在這個時候，軟件學院的教育更應該傾向於正規化，傾向於講rules，講嚴格的東西。這不像美國的工業。美國的工業從1986年以後，20年的發展，走過了一段很痛苦的時期。它走過一些很複雜的，非常講究，而且可以說是教條主義。所以人們對於從DoD（美國國防部）發展出來的，像CMM這些東西，或者是UP這些東西，在美國有時他們進行反抗，他們進行叛變，這是完全可以理解的。但是，回到我們國家現有的情況，我覺得我們現在好像學習“正楷”還是非常重要的，至於現在他們的傾向，他(Martin)剛纔也說了，他們也在摸索，他甚至於，回答我那個問題，他覺得他們所理解的感受和我們的感受還是有些差別的。他們認爲他們也在這幾年，現在做出來和去年比的話，他覺得他們也許會用另一種方法來做。所以他們的很多想法也在改變中。現在看來，這兩個極端的東西都對我們有好處，我們可以從中學到一些他們長處的地方，特別是XP，像JUnit這樣的軟件，在沒有code以前就先test，這個我看在軟件工程界是已經承認了的。我回答已經完畢，有什麼意見可以討論。
Martin：如果我的理解正確的話，我剛纔提到中國需要經歷一段走向理論化的過程階段，之後在走向敏捷過程，像XP這樣的方法，因爲美國經歷過這樣的一個過程。我不同意這樣的觀點，包括這在美國也是個必須一個過程，很多人確實經歷過這樣的過程。我認爲在美國，很多項目需要花費很多資金用於表面工作，當你認真去觀察事實上的工作的時候，你會發現它完全處於混亂狀態。你看到的是他們已經掩飾好的一個表現，在事實上卻完全不同。 Alistair Cockburn在他很早研究方法論的時候就已經揭示了這個問題。他研究了一些方法論，去採訪了一些項目，詢問他們的工作情況。他的做法是很聰明的，他找到項目領導和架構師，詢問過程是怎麼樣的。做了記錄。之後，他去找那些真正的分析人員，開發人員，並且詢問過程是怎麼樣的。他對這兩個方面進行比較，發現答案根本就不一樣。Official Story看起來還不錯，但是Real Story卻完全不同，顯得比較混亂。很多企業並沒有採取這種重型的開發過程，我們也沒有這樣做。XP可以幫助項目解決這樣無序的問題，他並沒有看到RUP具有有競爭力，這個是在無序性方面的競爭。我們希望公司能夠潛移默化，自然而然的使用方法，並且使它向前發展。雖然在一開始使用的時候也是混亂的。在美國可以使用的這些方法，我想在中國一定也是可以推廣的。所以我不認爲你需要重型的方法，你可以直接跳過這一步。我想說的第二點是，這裏對於UML和統一過程有一個不明確的地方。這是兩個完全不同的東西，但是通常被混在一起。人們發明UML的初衷是，當你使用UML的時候，可以使你避免使用那些重型的方法。我現在使用UML的頻率和十年前是一樣的。我所寫的書裏面也有很多很多UML，特別是關於模式方面的書。UML使溝通變得非常方便。不要認爲你可以通過UML對於一個系統進行完整的分析和設計，這也不是UML唯一的用途。我在白板上畫UML圖，在書中用來解釋一些問題，UML具有非常重要的價值。UML有很多應用的方式。在敏捷過程裏，UML就具有很重要的作用，當然它也可以被用於重型過程。但是不要把這兩個概念混淆在一起。UML是非常重要的工具，有着不同的應用方式。
王海鵬：剛纔林老師講的那一句名言給我一點感觸，實際上就是說如果把它比作楷書或者草書的話，我們不能說楷書優於草書或者草書優於楷書，只能說是誰寫出來的。如果我沒練過的話，那無論是寫草書或者楷書都不能拿到檯面上的。實際上，就我知道的，在敏捷和建模這兩方面實際上是不衝突的，而且有人會把它組合在一起用的很好，比如用feature driven development（FDD），就是由Peter Codd他們一些人做出來的，他非常強調在前端有一個domain的一個設計，做出一些domain的class，然後再進行一次一次的迭代來進行一種敏捷的開發。我想這可能就是說，如果是草書或者楷書的話，那它可能就是介於其中，行書，的一種做法。另外，林教授說Martin先練楷書，再轉到草書，我想到中國書法家有一個人物，也是走過了這樣的道路，就是八大山人。他早期的書法都是很規矩的一板一眼的有側鋒入筆，再提按，再折…練的是顏體。但是在他的晚期之後，他的所有的轉折都已經圓滑了，已經變成草書那種寫法了。我想這個可能和Martin先生的經歷有一點點類似。提到這個比喻，是我剛纔聽到林老師的比喻之後想到的一些問題。