不光是做軟件，凡是做產品，最后關注的總是產品的質量。
舉個例子，比如你做一鍋湯：
今天你狀態很好，做完后嘗了嘗，感覺很美味，你的家人嘗了以后也有同感，喝完后感覺心情舒暢、意猶未盡。
隔了一個禮拜，你做同樣的湯給家里人喝。做完后你嘗了嘗，感覺依然美味，盼望著得到家人的賞識，然而他們卻說味道咸了點。你很奇怪，為什么同樣自己嘗過了，家里人卻感覺不一樣呢？是不是最近加班多了，休息不好，味覺不準了？
一個月過后，你要去國外出差，給家里請了個臨時保姆。一天，他也做了這么個湯，做完后，他也嘗了嘗，感覺口味很不錯，可是端上桌，家里人說這湯太辣了。原來這保姆才從湖南老家出來不久……
因此，只把焦點放在最后的產品上往往是不夠的。需要對“做湯的過程”加以控制。所以工程界會比較關注過程的管理，在軟件領域也稱作“軟件生命周期管理”。
再來看看UP和XP。它們都屬于軟件過程，只不過各有特色。
再拿剛才那個做湯的例子：
大家都聽說過德國人的廚房像化學實驗室，天平、計時器、量杯……裝備齊全，再配上精確的菜譜，嚴謹的德國人能夠確保不用嘗那最后一口都做出口味基本一致的湯。
換了中國人，大部分人都不會模仿德國人做菜的方式。解決方案很簡單，讓你的太太和孩子都嘗那最后一口，再根據反饋調整幾次，同樣能做出全家人滿意的湯。
這個例子也許不太貼切，但是可以聯想一下:德國人做湯傾向于UP;中國人做湯傾向于XP。
UP和XP最終目的都是為了保證產品的質量，不同的是，兩個過程所強調的方法不同。我想，沒有人會說“UP的目的在于變態地追求文檔的完美”、“UP是為了要程序員學會寫各種各樣文檔”……之類的話。同時，也沒人會說“XP就是不要文檔只要代碼”、“XP就是要變態地追求完美的代碼”……這樣的話。
這些不正確的看法，只是人們對于這兩種過程的誤解。或許是來自于開發人員和項目經理的那些“不堪回首的經歷”。
“UP害慘了整個軟件行業，讓開發人員沒完沒了地寫文檔而忽略了代碼，XP才是王道”這樣的話，我不敢茍同，仍然有很多企業使用著UP這樣的重型軟件工程，就好比德國人依然喜歡把廚房弄得像個實驗室。
XP固然是個好東西。但是，不知道大多數人對于XP的熱衷是出于對XP文化的理解，還是國人慣有的“一窩蜂”似的行為。不曉得一個“能夠熟練閱讀代碼的Leader”是不是能夠真正運用好XP，確保他的團隊能夠盡可能少地出現"Over engineering"這種違背Agile精神的東西，或是能夠讓他的團隊保證“每周只工作40小時”這樣的基本實踐？
對于不同的技術和過程，應該給予冷靜的分析和慎重的選擇。每個過程和技術都不能以“正確”或“不正確”來定性，只能以“合適”和“不合適”來定性。因為正確或不正確是要嚴格證明的，而合適不合適是來源于工程實踐的結果。所以，COBOL依然在金融領域起著舉足輕重的作用，科學家們仍不忘Fortran，匯編和C仍然健在……
另外不得不提的是文化上的差異。為什么很多時候，我們學習國外的先進技術，購買了整套生產線，引進了全套圖紙，請國外專家做了詳細的全程化培訓，國人生產出的產品品質依然不如國外原產的？這是每個中國人都應該思考的問題……
?