雖然我沒能去參加BEA的活動，但是相關的資料已經下載并且瀏覽過了，確實收獲不少。所以，對于莊兄的這些想法我很理解。
相信不只你我，大部分的人都比較認同敏捷化的過程，希望使過程變得敏捷。的確，這是個好東西，之前我也說過“敏捷過程是三贏的”這樣的話。
我所關心的問題是“如何能夠用好XP？”。
莊兄認為“湯的味道，不需要什么過程控制”，我也會認同。為什么？因為你我都是中國人。大部分中國人不會認為湯的味道需要什么過程控制。但是想想看，如果你在不同地方買到的肯德基炸雞味道各異；同一批次生產的同型號的汽車形狀各異；銀行里取出來的一疊百元大鈔大小不一，你不會覺得奇怪么或是有那么一點點憤怒么？
西方人（甚至學習西方的日本人）對品質的重視程度卻完全不同。他們不允許肯德基炸雞的味道有很大偏差（即便你覺得無所謂）；“2毫米工程”不允許整車的總裝長度發生2毫米以上的偏差（即便你覺得無所謂）；百元大鈔……（我想誰都不會無所謂）。
所以，一切質量都有標準，一切標準都應該被度量！這就是工程學的目標之一，為了實現更嚴格的質量標準，就需要過程控制和度量。
莊兄所說，用測試用例保證代碼的質量其實還是采用了“測試用例”作為度量的標準。唯一的問題是：“如何確保測試用例的質量”。顯然，我們不能把一把不直的尺子度量出來的結果作為可靠的參考依據。怎么解決呢？“結對編程”么？嗯，這是一個不錯的方式，那么最終該信賴誰呢？是Pair中的A還是B呢？或者，是Leader么？那么又是誰提出的要求呢？是老板么？還是客戶？政府？法規？市場？……問題沒有終結了。
不要學習哲學家的方法，提出一層又一層無法解決的問題。我們是工程師，應該試圖解決問題才對！解決問題的關鍵在于，XP同樣需要標準！為了制定標準，必要的文檔是不可以少的。而且，標準本身的質量是嚴苛的。因為，作為標準，他不可以含糊其辭、模棱兩可。在標準的基礎之上，我們才可以談什么TDD、Pair Programming之類的實踐。
回到爭論的開端。我引用了林先生的話“UP是正楷；XP是草書。要先學好UP才能學好XP，先學XP會亂套。”我對這句話的理解如下：這句話并沒有批判UP或是XP，只是指出了一個學習的順序。我認為這句話是有實踐依據的，因為UP強調的是一種經典的工程方法。軟件工程本來就源于其他行業的工程實踐經驗。UP利用大量的文檔對開發活動進行約束和記錄。正是這種重量級的過程規范了規范了從PM到Coder的所有活動，有問題可以參照文檔，看看自己應該怎么做。文檔也可以作為日后評估這個過程的依據。隨著整個團隊和每個個人的經驗不斷積累，開發活動中的日常行為漸漸形成了一種職業習慣。然后可以通過對UP的配置，逐漸減少文檔的使用量，一些沒有必要的文檔就可以省去，更具團隊的實際能力調整過程。UP是可配置的，不必要的文檔沒有存在的理由，這一點UP和XP沒有什么兩樣。當然，隨著大家的職業習慣越來越好，經驗越來越豐富，個人和團隊就可以采用更敏捷更輕便的過程，逐漸過渡到XP上去。
反過來，如果一開始就沒有詳盡的文檔，很多活動（比如設計、版本控制）往往會脫離控制，進入一種無序的、混亂的狀態。沒有文檔可參考，就意味著很多問題只能問人，而不同人的回答可能各異，同一個人對同一個問題的兩次回答也可能不同！當然，如果整個團隊的工程素養和個體的職業習慣都比較好的情況下可能不會發生類似的情況。但是這種工程素養和職業習慣從哪里來，可能單靠的XP是不足以培養出來的。
“UP是正楷；XP是草書。要先學好UP才能學好XP，先學XP會亂套。”這句話表明了UP和XP在一定程度上是存在沖突的，并且提出了一條路線去降低和避免這個沖突。
再次需要強調的是莊兄所提到的“XP是一種思想”，這點我認同。但是我認為這個除了思想之外，還是一種“文化”。這種思想和文化也是出于軟件工程多年來的實踐，其中也不免有UP等其他過程。不能簡單地認為“我們只要吸取歷史的教訓，提出新的思想和文化就不會再犯同樣的錯誤了。”很多時候歷史總是一次又一次地重演著。新的思想和文化如果不能被準確地理解和運用，它所帶來的可能仍然是它原本想解決的問題。只有我們具備了引入這種文化的基礎，才能把它變成自己的文化，否則這仍然是掛在嘴邊行于表面的一種不求精髓只求模仿的偽文化、偽思想。這一點對于UP和XP的實踐者來說沒有什么兩樣。