極致軟體製程 — Extreme programming explained : embrace change ———————————– 作者／Kent Beck/著 譯者／李潛瑞/譯 出版社／培生 出版 ISBN／9867910311

內容簡介
本書分成三大部分：

第一部份：問題
從『基本的問題』到『回歸基本面』的章節，構築出XP試圖要解決的問題，並點出評估對策的標準。這部分會告訴你整個XP的概念。

第二部份：對策
從『快速走一遍』到『測試的策略』的章節，把第一部份抽象的概念，轉變成具體方法論的實踐。這部分說的就不是大體的狀況了，而是會把每一種實際做法，跟第一部份所說的問題和原則銜接起來。

第三部份：實踐
從『XP的導入』到『XP的應用』的章節，圍繞在如何實踐XP的各式主題上—像是實踐出適合自己的XP、它對『非常專案』中各種成員角色分工的期待、以及對商業人士的意涵。

這本書談的是XP背後的一些想法—它的緣起、哲學、故事、和迷思。
本書意欲幫助你在獲得充分訊息的狀況下，做出是否導入XP的決定。

如果你 讀過本書後，正確地做出用與不用XP的決定，我都已經達到我的目標。
本書的第二個目標，是要幫助那些正在使用XP的人，能夠對它有更深入的了解。

前言

製程是否與軟體設計有關？ 我以為設計本來就不能昧於現實，要能在現實與理想之間，找出調和的解決方案—這會與現實的開發環境有關；再加上設計必然會面對團隊開發時，眾多“人”觀點之間的謀和溝通等議題—這也會與製程有關。所以我也會在「軟體設計必讀經典」系列中，介紹關於製程、方法論等一些好書。其中，本次書評的主角—極致軟體製程，最會是我想推薦給讀者們的經典指標。看到這本書，就如同在舊書攤找到絕世的武功秘籍一般，講究的是心法的傳授，整本書沒有一行程式碼、只有少數幾張圖而已，全都是口述的文字，但閱讀起來完全不沈悶，非常的白話，如同閒話家常般的告訴你軟體的一些道理。

XP, eXtreme Programming (X 要大寫，凸顯了 Magic Letter)，中文翻譯為“極致”軟體製程，我覺得 eXtreme 一字也可翻為“極端”，極致代表的是將軟體製程發揮到最善；極端表達的則是有些顛覆傳統開發的方法，但很有效。(例如，搭檔編程，兩個人一起寫一支程式，開發效能反而提升)

教祖康貝特 (諧音)，從本書發表以後，儼然成為與 UP (Unified Process)相對立的一種教派：一為輕量級 (XP)、另一為重量級 (UP)的開發製程。(當然，事實上那是僅從方法論的角度來比較看待之，這些製程的根本精髓仍是一致的) 其後闡述 XP 的書籍如雨後春筍，眾多有經驗的軟體開發者們，提出了從 XP的根本價值與原則，來找出解決實務問題的最佳對策與方法等，有三十本以上之多，而目前中譯本也出版了有五、六本左右，但賣得好像不好，本書在某書局又是只賣 NT$ 99。

從問題的根本找出解決方案

第一章開宗明義就提到：軟體的根本問題在於風險！ 諸如無法準時交付、錯蟲太多、需求變更、不合適與不必要的功能、人員流動率 …等。因為看到這些問題，XP 先找出影響軟體製程的四個變數因子，然後提出了四種價值觀，再以此訂出開發的基本原則，然後回歸到簡單的基本面，制訂因應的對策，找出實務的解決方法，然後實踐它！

四個變數因子：成本、規模、時程、品質。 你會發現有趣的一件事，其中的三個因子，成本、規模與時程，幾乎都是被控制在客戶手裡，而開發承包單位大概只能控制品質這個因子而已。而品質這個因子正是與前三個因子為反比，所以，成本越低、規模越大、時程越短，那麼，品質必然會差。這種就是根本性的問題，這些變數因子如果沒有作有效控制，那麼導入如 CMMI 等，也是枉然的 (搞不好還更糟糕，增加了太多高度儀式化的工作)。 Kent Beck 在本書中提到了，他發現到可以先專注在規模變數的控制，也就是把規模收斂，專注在客戶真正想要的，早一點釋放出版本 (Release early)，如此也比較容易消弭客戶與開發單位見解上的歧異。

四種價值觀：溝通、簡單、回饋、勇氣。 我覺得這就是群體生活最符合人性的恆常價值了。 團隊開發，不說出話來，如何溝通呢？ 如果沒有回饋，如何知道你的問題呢？ 沒有勇氣表達出你的觀點與決心，如何持續實踐下去呢？ 經常性的溝通、回饋、有勇氣表達，團隊自然會造成一種良性的正回饋環路，而更容易有一致性的共識，而往往，簡單的呈現就會出來了。

當你認知到軟體開發的根本問題與所影響的變數，並有了團隊整體的開發價值觀後，就會比較容易找出開發的根本原則了。諸如，快速的回饋、把簡單視為正常、漸進式的改變、擁抱改變、作有品質的事。

把握住基本原則後，再來才是找出解決實務的方法。本書提出了十二種實務 (當然，具體實踐的作法，是在其它書籍中深入說明的)，相當具有學習參考的價值，不過，可不要全盤照抄，國情、人文等因素，有些不一定行得通 (例如，要求客戶駐在承包公司)，況且，方法是“How-to”，我們應該是從原則來自行找出方法來的，這才是符合 XP 的精神！

簡單的道理卻難以執行

我覺得 Kent Beck 是生活的大師，他把許多生活的哲理帶入了軟體領域來，書中也提到，他媽媽教導他開車時，不是讓車子一直保持在「正確」的方向，而是時時保持專注，這裡修正一點、那裡修正一點。嘿，這正是漸進修正的最根本道理啊。所以書中的副標題為何叫做“擁抱改變”？ 因為，軟體開發中的每一件事物都會改變，而問題不在於改變本身，而是在於無法應付改變。

是的，我非常認同 XP 的智慧，不過我也不是 XP 的狂熱份子，我會動態找 How-to，所以例如，“測試先行 (XP 十二項實務之一)”，是我會主張在客戶單位堅持要導入的，而且是以使用案例(加上測試案例)作為功能測試的單位—而這就不是 XP 的方法了。 XP 是建議以 “Story board (或稱為使用者陳述)” 來作為需求的功能點，不過，我覺得使用案例實在很好用，沒必要完全拋掉 UML。 (XP 這點比較奇怪一點，幾乎不見 UML 的影子，甚至連圖形的設計表達都很少)

XP 的道理相當單純，但「執行面」可是很難執行。這在本書第二十四章有特別說明之。Kent Beck 提及，導入的難處，主要還是情感上的問題—特別是恐懼感作祟。我很認同！ 所以，我從來不與客戶說我要協助你們導入某某方法論，通常就是以誘導的方式，不知不覺的融入，然後把它當成是一種習慣，團隊成員久而久之就會以為理所當然如此。

對了，為什麼簡單的道理反而不容易執行？ 因為，人類往往有兩種天生的傾向：一、對於我們所碰觸的任何事物，通常會弄得過度複雜，基於這個原因，二、我們往往不能看到事物最明顯的一面。