{iThome 書評—4} 極致軟體製程中譯本

極致軟體製程
— Extreme programming explained : embrace change 極致軟體製程 — 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 提及,導入的難處,主要還是情感上的問題—特別是恐懼感作祟。我很認同! 所以,我從來不與客戶說我要協助你們導入某某方法論,通常就是以誘導的方式,不知不覺的融入,然後把它當成是一種習慣,團隊成員久而久之就會以為理所當然如此。

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

文章導覽

   

共有 3 則迴響

  1. Kenming前輩

    那一家網路書局賣99元
    可以稍微透露一下嗎??

    我用FindBook去比價
    目前的價格是315

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *