“UP是正楷，XP是草書。先學好了UP，才能學好XP；先學XP再學UP就會亂套。?”
老師曾這么說。最近，對這句話有了深刻的體會。
軟件過程是一個以人為中心的活動。人是項目中最難確定和控制的因素。休息的質量、情緒的起伏都會影響整個活動。為了盡可能地約束這種個體的不確定行為和減少開發(fā)過程中不必要的誤會。"UP"采用了大量的文檔來對整個開發(fā)過程進行控制。這些文檔主要分為以下幾類：
- 計劃文檔——項目的開發(fā)計劃、迭代計劃、測試計劃等。
- 技術文檔——項目的設計文檔、某個操作的說明文檔等。
- 記錄文檔——日常的會議紀要、每日進度反饋、評估報告等。
文檔成了UP活動的主要部分。在UP中，往往大量的資源用于文檔的制作。這些文檔的目的是為了盡可能減少不必要的溝通成本和誤會，也為了在發(fā)生問題的時候能夠盡快確定原因找到解決方法。
而正是因為如此繁重的資源消耗，導致真正的設計和代碼只占到了總開銷的很少部分。這對很多人來說不可理解，甚至覺得本末倒置。于是很多敏捷方法誕生了，最具代表性也是對UP思想最具顛覆性的就屬XP了。
對外，XP以快速的反應速度來響應客戶的需求；對內，XP以高質量的代碼和設計來確保盡可能不產(chǎn)生不必要的文檔和資源開銷。
從表面上看，在當今，XP確實是一種非常理想的開發(fā)過程。
但是，從沒有過程到XP往往會非常失敗。這是為什么？問題的關鍵還在于人。
UP利用文檔來約束和規(guī)范人們的開發(fā)活動。當一個沒有經(jīng)驗的團隊經(jīng)歷UP后，就等于把性格各異、習慣差別不同的人統(tǒng)一成了“相對較一致的開發(fā)人員”。
他們有一致的編碼習慣，有共同的用語，有嚴格的規(guī)則。隨著經(jīng)驗的積累，這個團隊間的默契越來越高。此時，如果過程由UP向XP切換，付出的代價就會相對較低。
XP主張快速反應。如果一個沒有經(jīng)驗的團隊在一開始就嘗試XP，那么后果可能是慘痛的。因為一個沒有經(jīng)驗的團隊其成員間的相互了解頗少，對于一件事，往往十個人有十種想法。當缺少文檔約束時，在以代碼和設計為中心的活動中，成員之間往往因為水平的參差不齊導致無休止的討論甚至爭論，代碼被不必要地頻繁改動。這是因為，在團隊建設早期，成員之間往往連最基本的尊重和信任都不存在。 這種無意義的活動往往會嚴重影響項目的正常進行。
所以，學習和應用過程不僅僅是個體的事，而是整個團隊的事。只有當團隊采用嚴格文檔化的過程并且經(jīng)過磨合后，才能漸漸向輕量級的過程遷移，逐漸將不必要的文檔刪減掉，采用更靈活的過程。但是，此時并不是“沒有文檔”而是“心中有文檔”。