XP Distilled 中譯

The Business Problem

近十年來總裁們面臨企業獲利必須穩定成長的壓力。他們的做法,例如企業瘦身、部份產業外包、企業重整等等方式,再再展現出這樣的決心。但儘管很多 S&P 排名前 500的企業不斷努力增加效率,而得以在九○年代後期持續保持雙位數字的成長,其中仍然有很多問題隱然浮現。

作家 Gary Hamel 在他的 "Leading the Revolution" 一書中說明,有很多指標顯示傳統企業架構其實已經沒有什麼可以進一步縮編的部份了。企業必須不斷求新求變以找到持續成長的方式。他對於保持企業持續成長的唯一建議就是 -- 徹底的的改革。尤其是在軟體研發的領域。

在研發軟體的過程中,如果你採用標準的軟體發展方法,那麼你最好有失望的心裡準備。近期的研究結果顯示,近半數的計畫會延期結案,三分之一的計畫更超出預算,這樣的情形是很平常的。而且,這項結果比 1979 年的情況好不到哪裡去。

想要明顯改善這個數據,我們需要一個全然不同的方式來開發軟體。現有的研發方法受到兩項因素影響:

沒有人故意要失敗,諷刺的是,那些想要減少錯誤避免失敗的方法似乎都不管用。擔心其實是問題的根源,更象徵著第二個因素的發生。提出這許多方法論的專家們忘了軟體之所以稱為軟體,其中 "軟性" 的本質。
專家們假設研發軟體就像是構築一座橋,於是他們將用在建築一座 "堅硬的" 橋的種種訓練,借過來套用在軟體研發的過程。類似這種 "先設計再施工" 方式的結果就是缺乏彈性,而且做出不堪使用的產品。
最近則出現了許多有別於以往 "重量級" 的軟體研發方法論,這些屬於 "輕量級" 的方法,如 "Crystal Method"、"Adaptive Software"、以致於目前最流行的 "XP", 都回到了基本面:軟體的研發需要人與人之間的相互配合。無可否認的,每個人都同時具有優點以及缺點,成功的軟體研發方法要能夠將工程師的優點發揮到極致,而且盡量降低缺點所造成的影響。就我們的觀察,XP 在組員之間這些互補的力量上處理的非常好。
XP 的出現代表著近十年來軟體界一個改革創新最好的機會。Tom DeMarco 也提到:對現今的軟體界來說,XP 跨出了極重要的一步,我預測它最後會像 SEI 和 CMM 一樣成為不可或缺的基礎。

XP 歸納出四個要素幫助軟體工程師從事他們最專精的工作:撰寫程式。XP 將 "重量級" 軟體研發方法中一些會使進度落後甚至折磨工程師的部分除去。Kent Beck 在他的著作 "eXtream Programming Explaind: Embrace Change" 中對這些要素做了簡述。我們總結如下:

1. 溝通:在計畫中常常可以追蹤並發現,有些問題是因為某人沒有告訴其他組員某個點的重要關鍵。XP 重視溝通。

2. 簡潔:XP 建議只以最簡單的方式做出可用的功能。Kent 是這樣說的:XP 做了一種賭注,認為只要做出眼前必需的最簡單的功能,要比為了將來而做複雜的設計卻可能用不到,要好得多。

3. 回報:儘早開始頻繁確實的回報可以確保努力的成果不至於誤入歧途。

4. 膽識:稍有遲疑就會失敗。膽識會在適當的時候給你勇氣,像是捨去某些程式碼,或是決定重大的修改。
 

回顧程式碼是好習慣,所以從頭到尾都要這麼做。測試是必要的,在寫程式碼之前先寫測試程式。文件和程式碼幾乎無法同步,那就只要做最精簡的版本。XP 不保證從頭到尾所做的都是對的,但是 XP 朝著這個方向做。藉著這些 "extreme" 操作方式相互支援下大幅增加速度以及改善效率。

現在讓我們進一步來了解 "XP" 的十二種程序:

□The Planning Game(概念規劃)  □Simple Design(簡單的設計)
□Continuous Integration(持續整合) □On-Site Customer(顧客實際參與)
□Testing(測試)      □Collective Code Ownership(程式碼共有)
□Pair Programming(兩人小組合作) □Matephor()
□Small Releases(小規模公開) □Coding Standards(撰寫標準碼)
□Refactoring(重整)  □40-hour Week(每週工作40小時)

The Planning Game

有些人批評 XP 就像是一群沒有經過訓練的牛仔拼裝出來的華麗馬車。不!XP 其實是眾多方法中少數體認到我們無法在事情開始進行的時候就顧慮到所有細節的方法。研發人員和顧客雙方都隨著計畫的進行而不斷學習。只有支持並且擁有這種變化特質的方法才是有效率的方法。其他方法所忽略的,正是 XP 所注意到的,也就是 The Planning Game。

"Planning Game" 的基本概念就是先大略的做出計畫,然後萃取出能夠讓計畫主體更清晰的部份。這個階段的產物是一堆記載著顧客對於功能描述的卡片,操控著將來計畫的步驟。其中關鍵的重點是由顧客來作商業方面的取捨,技術部份的判斷則交給工程師來作。如果不這樣作,整個過程可能毫無組織。

研發人員決定:
□ 每一個功能需要多少時間開發
□ 不同的技術所需要的成本
□ 研發團隊成員
□ 不同功能的關鍵程度
□ 開發不同功能的順序 (攸關成敗的關鍵部份先作)

由顧客決定:
□ 軟體走向
□ 出版時間
□ 出版時必須具備的功能
□ 優先權 (根據商業價值決定什麼特色優先開發)

這樣的規劃必須常常進行,研發人員與顧客雙方才有更多的機會隨時對計畫作修正。

Testing

XP 有兩種測試方法:
1. 單元測試
2. 滿意度測試

研發人員在撰寫程式碼的同時也撰寫單元測試計畫;顧客則在訂定功能之後就撰寫滿意度測試計畫。

研發人員在撰寫每一個函式之前,就先撰寫單元測試碼來防堵可能的錯誤。然後撰寫最簡單又可以通過測試的程式碼。大家會覺得這樣做很奇怪,其實不然,預先撰寫測試碼有下列好處:
□ 最完整的測試
□ 最簡潔的可運作程式碼
□ 得到一個目標明確的成品

在研發的每個階段都要通過單元測試,否則不能加入版本控管。通過單元測試讓研發人員確信所寫的程式碼是可行的,並且留下線索給其他人員了解原作者的做法 (我們甚至覺得這是最好的註解文件了)。單元測試的失敗也可以讓研發人員下決心重整程式碼。單元測試必須自動化,並且可以顯示清楚的訊息代表通過或錯誤。xUnit(http://www.xprogramming.com/software.htm)有豐富的功能,很多 XP 小組都在使用。

顧客為每個功能撰寫滿意度測試,這些測試也說明著整個系統該有什麼樣的功能。理想的狀況下,顧客的滿意度測試必須在程式碼撰寫的最後一道手續(iteration)之前完成。滿意度測試必須自動化而且不斷進行以確保研發人員完成預期的目標才進行新單元的研發。通常滿意度測試的撰寫需要研發人員的協助,所以我們發展了一個架構提供顧客輸入條件,等待 HTML 格式的輸出文件報表,報表上記錄著測試被執行、哪些測試通過、哪些測試失敗了。

不是所有的滿意度測試非要通過不可。滿意度測試是用來幫助顧客評估這個計畫的完成度,同時讓顧客知道某個部份是不是可以發表了。

Pair Programming

在 XP 的做法中,程式碼是由多個雙人組的研發人員撰寫,這種方式看來似乎沒什麼效率。Martin Fowler 說:當別人說雙人組程式設計降低生產力,我回答,如果大部分撰寫程式碼的過程都在打字,那的確是會降低效率。事實上,雙人組程式設計方式提供如下好處:
□ 所有的決定至少有兩個人思考過
□ 系統中的每個部份至少有兩個人熟悉
□ 兩個人同時漏掉某個測試或程序的機率很小
□ 交換搭檔使整個團隊擴展所知
□ 程式碼至少有不只一個人檢查

研究亦顯示,雙人組程式設計的效率要好過單打獨鬥。(請參考
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF)

Refactoring

重整是一項改善程式碼而不至於改變功能的技巧,XP 團隊對於重整程式碼毫不遲疑。

研發人員有兩次關鍵的機會對程式碼進行重整:實作一項功能之前與實作一項功能之後。研發人員試著修改已完成的程式碼看看能不能用更簡潔、程式碼更少的方式來實作。舉例來說,如果研發人員發現可共用的程式碼,他會重整程式碼以抽出重複的部份。

XP 說你要用最簡單的程式碼實作出可以運作的軟體,但是它也說,這是需要持續邊做邊學的。重整的動作是你從自己的程式碼中學到東西,它保持你的程式碼的簡潔。也就是說這些程式碼可以存在更久,讓接手的人更不容易出錯。

Simple Design

有人說 XP 忽略設計。BDUF 方法則說你應該先規劃出目標,不可做更改,然後做出一個完美的解答。XP 說設計不應該只做一次,甚至希望永不更改。XP 其實認為設計非常重要,也是一種例行工作。我們總是隨時做能夠達成目的而且最簡單的設計,然後依據現實情況做適當修改。

什麼樣的設計是最簡單又可行的呢?它必須符合以下條件 (感謝 Kent Beck 整理這些要項)
1. 通過各項單元測試
2. 沒有重複的程式碼
3. 從程式碼就可以看出研發人員的想法
4. 使用最少的 class 和 method

簡單的設計不代表設計的規模小,或是這樣的設計一定平平無奇。原則是儘可能做到可運作的最簡單設計,不必預留任何現在用不到的設計。我們以 YAGNI 來稱呼這種原則:You Aren't Going to Need It。別讓 YAGNI 毀了你的計畫。

Collective Code Ownership

研發團隊的任何人必須有權責改善程式碼。程式碼屬於團隊中的所有人,也就是說,每個人都必須對程式碼負責。這樣的通透性有一個好處,它允許成員在需要的時候可以逕行修改程式碼,而不必經過擁有人的管制。但是事實上每個人還是必須避免所有人都擁有程式碼,但是卻變成所有人都不管理程式碼的混亂狀態。

雖然說每個人都擁有這份程式碼,但並不是說沒有特定的權力義務。在這種類似 "無主" 的狀況下,可能發生某人破壞了程式碼卻無人負責的情形。XP 則說:自己玩的玩具,自己收!我們已經事先準備好所有單元測試隨時可用,如果你弄壞了某個部份,你有責任修好它。這需要有非常的紀律,也許這就是 XP 命名當中有 extreme 這個字的理由。

Continuous Integration

常常的、不斷的整合可以讓你避免最後整合面臨的惡夢。XP 團隊每天都會互相整合程式碼直到通過所有的單元測試。

頻繁的整合動作讓任何特殊的問題浮現出來(也許是因為新成員的加入不了解狀況而造成)。如此可以保持團隊效率,避免傳統方法所遭遇到的問題(寫了大部分程式碼,然後做大規模的整合,接著花很長的時間處理問題)。

On-site Customer

為了讓功能最佳化,XP 團隊需要顧客全程參與,適時解釋或釐清所訂定的功能,並且做商業相關的重要決定,工程師無法獨立完成這些事情。顧客駐點可以在工程師遭遇問題時不必為了等待某個決定而延誤進度。

XP 不假設需求描述卡(story card)具備所有工程師必須實作的功能。這個需求描述是一種作為往後顧客與工程師雙方填補細節的協議。主要的想法是,面對面的討論可以避免死板的文件可能造成的誤會。

Small Releases

在尚未達到商品化之前,儘可能在研發過程中以小單位做發表。

將系統儘快做發表,這麼做可以儘早讓顧客看見研發的價值所在。也讓顧客儘早回報什麼是需要的或者什麼是不需要的。顧客也同時學習到經驗,以便用在下一個版本上。

40 hour week

Kent Beck 說他希望 "在每天早晨感覺清新、充滿精力,到了晚上雖然疲累卻感到滿足",每週 40 小時工時可以有這樣的效果。實際的工作時數並不是這個概念的重點,他的信念是不停的工作只會讓效率更差。疲倦的工程師更容易犯錯,你會發現,持續長時間的工作比維持正常的作息更容易延誤進度。

就算工程師能夠忍受長時間工作,也不代表那是應該的。總有一天,他們會對工作產生倦怠,或是被不相關的問題困擾,導致停滯不前。你打亂了他的生活,就需要付出代價。加班並不是定期完成計畫的解決方式,事實上,這樣會產生更大的問題。如果你要的是一群死氣沈沈的士兵,你的確做到了。

Coding Standards

一套撰寫程式碼的標準有兩個好處:
1. 研發團隊不會為了如何訂定參數這種小事延誤了進度
2. 可與其他方法相得益彰。

沒有撰寫程式碼的標準,就很難重整程式碼,也很難交換搭檔配合工作,當然很難快速運作。理想的狀況是團隊裡的人無法分辨某斷程式碼是誰寫的。在團隊中協調出一種標準,並落實它。這樣的標準不見得要列出洋洋灑灑的條文,只要能夠讓程式碼可以清楚的相互交流就可以了。剛開始先制定簡單的標準,漸漸的依照經驗來調整,不可陷入BDUF 模式。

Metaphor

系統意象(metaphor)類似方法論裡所稱的結構,這個意象給研發團隊一個可靠的圖像,他們可以用來描述系統運作的方式,如何加入新的部份,該用什麼形式來實作。

有時候你就是找不出一個清楚的意象,但是如果你找到了,那是很不容易的事情。記住,讓團隊的每個人清楚整個系統的組成與運作比想出一個漂亮的圖騰更重要。

The Pratices Work Together

整體靈活的運用比個別表現的總和更有用。你可以只選擇一種方法,或是其中幾種而得到更多好處。但是,落實所有的方法是獲得最大好處的唯一選擇,因為將這些方法交互運作才能發揮最大功效。

跟著書做 XP 只是一個開始,當你了解這些方法彼此的關係,你就能夠視實際狀況調適做法。記住,使用 XP 並不是最終目標,它只是一種到達終點的方法。真正的目標是快速的研發優質的軟體。如果你的計畫漸漸變得不像在使用 XP,你就會被競爭對手關在門外。加油吧!

References
Beck, K. Extreme Programming Explained: Embrace Change, Addison-Wesley
(1999).
Hamel, Gary. Leading the Revolution, Harvard Business School (2000).