不知道他身份的話，遠遠望去，也不過是一個很普通的老外，絡腮鬍子，禿頂的腦門（這使我想到了C++創始人那同樣禿頂的腦門
，是不是每個聰明的人都回絕頂啊）。現在就不客觀的回顧一下昨天的演講，爲什麼叫不客觀呢，因爲我不能忠實的記錄大師的每一句話，我在聽的過程中也一直在思考，所以，我想，我的記錄恐怕夾雜了很多我自己的想法和臆測吧。如果各位想要看看完全真實的記錄話，我還是建議去CSDN的網站咯。首先是ThoughtWorks公司的中國區總裁Mr. Pinney，Fowler現在的身份應該是ThoughtWorks公司的首席科學家，專門指導敏捷開發的。ThoughtWorks是一傢什麼樣的公司呢，就我的理解應該是一家IT Service的公司，自從藍色巨人開始向IT服務轉變後，我才發現，美國的軟件行業早已經全面的向IT服務轉變了，列的出名字的除了剛纔說的ThoughtWorks還有 Ivar Jocobson International, EDS,挨森哲等等。大體來講這樣的公司業務都分爲兩塊，一塊是軟件定製，一塊是軟件開發諮詢。而ThoughtWorks的特色就是不管是自己開發行業軟件還是對其他企業進行軟件開發諮詢，都採取敏捷的開發方式，並且取得了巨大的成功。呵呵，扯遠了，詳細地內容敬請期待我的下篇blog《IT服務的時代》
言歸正傳，隨着Martin Fowler的登場，我們來聊聊他的演講。首先，Fowler先生把我們傳統的開發方式稱爲plan driven的開發方式，也就是計劃驅動。不同於敏捷方法所採用的測試驅動，計劃驅動的開發方式是以預測性味基礎，以過程爲核心的開發方式。這種開發方式，往往強調設計的重要性，希望在正式構建之前（所謂構建，也就是我們常說的coding過程），能夠把一個軟件的方方面面都能想到，並用文檔的方式和圖的形式得以保留，這也是UML產生的初衷——爲了更好的描述設計，Martin Fowler作爲UML的專家，豪不隱諱自己曾經也使用傳統的開發方式很多年的事實。正式多年的傳統方法的開發方式，使他發現了以下三種情況是plan driven的開發方式所恨難避免也很難解決的。
其一，如果把軟件工程跟其他的工程領域來比較，其他的工程領域設計階段只佔用整個生產週期的10%左右的時間，而軟件工程卻佔用了40%到50%的時間，問題出在哪裏？是這個類比不恰當？還是我們所謂的“設計”劃分的時間點不正確？
其二，與建築商的設計不同，軟件設計在紙上是很容易完成的，而拿到實際開發中卻發現有這樣或者那樣的問題，作爲資深的軟件開發專家，Fowler先生也很誠實的承認，無法在設計階段把所有可能的問題都考慮得周全
其三，需求總是在不斷的變化的，不像建築工程那樣是建立在靜態需求之上。
這樣的三個問題，直接就導致了敏捷開發的產生。敏捷開發是以適應性爲基礎，以人爲核心的開發方式，目的就是解決以上三條plan driven無法避免的問題。說到以人爲核心我又要插兩句話了，最近國內所謂的“軟件工程”是很火的了，軟件學院每年不知道培養了多少“軟件工程師”和“軟件藍領”，很多人都要學習所謂的印度模式，想要把中國變成一個巨大的軟件加工廠，而這種思想所代表的正是 plan driven的開發方式所提倡的過程管理：以過程爲核心，人就像零件一樣是可以替換的。對於Fowler先生的觀點來看，這種思想是不可理喻，無法實現的烏托邦式的思想。爲什麼敏捷開發如此強調人的作用？對於此Fowler先生給預了專門的闡述。首先，根據調查（IBM的某位牛人的調查，應該是艾克.卡文），“大凡成功的項目，基本上沒有什麼可以重複的經驗（process）可以用來參照，唯一的一點，就是有一個好的開發團隊”。項目管理，說白了，就是管理項目開發的主體——人，人在項目開發中起着絕對主導的作用，絕不是像零件那樣可以隨意替換的。這裏Fowler先生做了一系列的對比：基於plan driven的開發，把程序員當作了computer，甚至有人還提出軟件開發本身也可以被編程。而對於敏捷開發來說，不同於機器零件，人沒有持續性的也不可重複，人的優勢和機器的優勢並不一樣，人應該是第一位的，凌駕於過程（Process）之上的。“人與人之間的交往互動比方法和工具更重要”（《敏捷宣言》）。方法應該用來適應人，在一個好的開發團隊中，人應該能選擇方法。過程是不一樣的，對於敏捷開發的每一次迭代，都必須總結改進開發的過程。
在演講的最後，Martin Fowler先生也指出了，敏捷開發不是萬能藥，本身也還是在一個不斷的探索階段。而且，及時在美國，也不是一個普及的開發方式，不過他對敏捷開發的未來還是很有信心的。
接着就是嘉賓的圓桌會議，主要也就是敏捷開發這個領域結合各自的開發世紀和中國的實情進行了一些討論。討論本身我就不再記錄了，不過導是抽出了一些觀點。
一個就是，關於程序員素質的問題（我覺得那位大哥想說的應該是程序員的經驗），Fowler先生認爲開發經驗的不足並不是敏捷開發不能實現的理由，恰恰相反，敏捷開發可以快速的幫助程序員成長。但這裏面有一個默認條件，那就是需要教練，呵呵，是這麼翻譯的，不過我覺得翻譯成師傅也很恰當（取義自《軟件工匠》），一個敏捷的團隊最好有一個經驗豐富的靈魂人物作爲指導，才能夠比較快速的成長，尤其是當一個團隊的經驗不豐富的時候。
二個就是，不同於工程學的比喻，軟件開發更像一個律師和客戶那種基於協議，協商的一種工作，筆者把它比作諮詢式開發，或者我們以後可以叫做軟件諮詢學。另外一種情況就是，軟件工程所類比的工程學也是N多年以前的工程學了，現代傳統工程學越來越注重需求的變化，淡化設計和構建的分界，對此，正是軟件工程學所需要好好反思的。
三個就是，雖然自上而下或者自下而上的推廣敏捷開發都可以，但是就目前國內成功的案例來說一般還是自上而下的推廣，才能成功，而這，正是國內推廣敏捷開發的巨大阻力。
四個就是，現場客戶對於敏捷開發（我覺得對於所有的開發都是這樣）的成功，是十分重要的。殊途同歸，軟件開發的核心就是緊緊抓住客戶的需求。
在活動的最後，我眼疾手快，以最敏捷的方式舉手示意，終於得到了一次提問的機會，呵呵，而且一問就是三個（哎呀這三個問題，差點讓我沒有得到CSDN神仙姐姐送的紀念品）。那麼我這裏就比較詳細的記錄了Fowler先生的回答。（個人認爲我的問題還是比較尖銳和有針對性地
）
Q1:既然敏捷開發如此的強調人的作用，那麼怎樣避免在開發過程中出現個人英雄主義，也就是過分依賴於團隊中某些人的技術，而當這些人離職後會導致開發的中斷甚至癱瘓。
A: 就我們的開發事實來說，這樣的“個人英雄”走了，團隊的開發反而變得容易了，敏捷開發強調人的作用，強調的是團隊的合作而不是個人英雄主義
Q2:國內很多公司都在試圖通過CMMI的認證，您認爲如何把敏捷方法引入到CMMI的體系中。
A: 嗯，在CMMI中溶入敏捷其實事件很困難的事情。CMMI的提出，本來是爲了幫助個人進步的一種機制，首先，它的產生背景，源自一個plan driven的開發方式相當普遍的時代，所以比較強調過程的管理。但是並不是說CMMI中引入敏捷是不可能的，事實上CMMI對敏捷也是非常友善的。但是對於CMMI來說最可怕的是證書的興起（說的好，這就是一個政治的問題而非一個技術的問題了），它破壞了CMMI的初衷。
Q3: 對於傳統的非面向對象的語言，比如說VB是否可以引入敏捷開發
A: 敏捷開發本身是語言無關的，XP也不是敏捷的全部，不過VB不支持創建自動化測試確實也是個問題，但還是有實施的可能，特別是.Net平臺以後，這一切都變的非常容易了（俺這麼問自然是因爲我在開發中確實沒有辦法自己選擇開發語言嘛，要是能用.Net，我也就沒有這個疑惑了，5555）
以上就是我寫的特別報道，感謝CSDN提供了這次交流的機會，同時感謝Microsoft和CSDN提供的blog空間......（此處省略N多字）。最後的問題是，我寫了這麼長，不知道會不會有人來看啊
