使用面向?qū)ο缶幊套兊每涨捌占�。它使軟件開發(fā)發(fā)生了某種程度上的變革，但最近的研究表明，有半數(shù)的軟件開發(fā)項目滯后，而三分之一的項目則超出預算。問題不在于技術(shù)，而是開發(fā)軟件所使用的方法。所謂的“輕量型”或“靈活”方式，與面向?qū)ο笳Z言的威力和靈活性結(jié)合起來，提供了一種很有意思的解決方案。最常見的靈活方式稱為極端編程（Extreme Programming）或者 XP，但許多人并不真正了解它。對軟件項目使用 XP 可以大大增加成功的機會。本文提供了 XP 的概述，并解釋了它為什么很重要 -- 不是傳言，也沒有騙局。
　

　　在過去的十年中，CEO 們在產(chǎn)生穩(wěn)步增加的收入方面面臨巨大的壓力。他們通過在許多方面采取一系列舉措來解決這一問題，例如縮小公司規(guī)模、外包、再工程、企業(yè)資源規(guī)劃 (ERP) 等等。這些對低效率的解決措施讓 S&P 500 中的許多企業(yè)在 90 年代末能夠連續(xù)幾年保持兩位數(shù)的收入增長。但這種方式也帶來了一些負面影響。
　

　　在 Gary Hamel 所著的 Leading the Revolution（請參閱參考資料）一書中，他聲稱已有一些跡象證明傳統(tǒng)企業(yè)模式的優(yōu)勢已不那么明顯。我們必須找到一些替代方法來為收入的持續(xù)增長提供動力。他建議唯一能讓公司繼續(xù)增長的辦法是進行一次徹底的創(chuàng)新。我們認為在軟件開發(fā)領(lǐng)域中尤其需要這樣。
　

企業(yè)問題
　　如果使用標準軟件開發(fā)方法，那么即使在常用的平臺上進行開發(fā)，也要做好失望的準備。如圖 1 所示，最近的研究表明，有一半項目將滯后，而三分之一的項目將超過預算。這一推測比 1979 年由美國總審計局的研究結(jié)果好不了多少。

圖 1. 軟件項目成功和失敗，過去和現(xiàn)在

　　如果我們希望這些數(shù)字有顯著提高，則需要徹底創(chuàng)新的方法來開發(fā)軟件。有兩個主要因素影響現(xiàn)有的方法： 懼怕失敗、對軟件本質(zhì)的誤解。
　

　　沒有人打算失敗。具有諷刺意味的是為使失敗最小化而創(chuàng)建的方法是失敗的。對軟件的誤解是問題的根源�？謶謱嶋H上只是一種癥狀。現(xiàn)有的方法是由那些有良好愿望但忘記了軟件中的“軟”的那些聰明人所創(chuàng)建的。他們假定開發(fā)軟件就象造橋。因此他們從各種設(shè)計規(guī)范中借鑒了一些適用于“硬”物體（例如橋梁）的最優(yōu)方法。結(jié)果是基于 Big Design Up-front (BDUF) 思想的反映遲鈍的開發(fā)方法，軟件不堪一擊，人們無法使用它們。

〈一〉一種解決方案：靈活方法

　　最近發(fā)生了一些轉(zhuǎn)變，從所謂的“重量型”方法轉(zhuǎn)向了“輕量型”或“靈活”方法，例如 Crystal 方法、適應(yīng)性軟件開發(fā)和（當前最流行的）XP。所有這些過程都有這樣一個事實，即需要人們共同來開發(fā)軟件。成功的軟件過程必須將人們的長處最大化，將他們的缺點最小化，因為優(yōu)點和缺點毋庸質(zhì)疑都存在。在我們看來，XP 最出色的地方在于它能夠解決所有影響參加人員的互補力量。
　

　　XP 提供了十年來最大的一次機會，給軟件開發(fā)過程帶來徹底變革。就象 Peopleware 作家 Tom DeMarco 所說，“XP 是當今我們所處領(lǐng)域中最重要的一項運動。預計它對于目前一代的重要性就象 SEI 及其能力成熟度模型對上一代的重要性一樣�！�
　

　　XP 規(guī)定了一組核心價值和方法，可以讓軟件開發(fā)人員發(fā)揮他們的專長：編寫代碼。XP 消除了大多數(shù)重量型過程的不必要產(chǎn)物，通過減慢開發(fā)速度、耗費開發(fā)人員的精力（例如干特圖、狀態(tài)報告，以及多卷需求文檔）從目標偏離。我們認識到一個稱為“極端編程”的東西可能很難作為正式的開發(fā)過程推薦給管理層，但如果您的公司從事軟件行業(yè)，您應(yīng)該幫助管理層繞過其名稱認識到 XP 可以提供的競爭優(yōu)勢。
　

　　Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價值（請參閱參考資料）。我們對它們進行了總結(jié)：
　

1）交流
　　項目的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流是不可能的事。
　

2）簡單
　　XP 建議您總是盡可能圍繞過程和編寫代碼做最簡單的事情。按照 Beck 的說法，“XP 就是打賭。它打賭今天最好做些簡單的事...而不是做更復雜但可能永遠也不會用到的事。”
　

3）反饋
　　更早和經(jīng)常來自客戶、團隊和實際最終用戶的具體反饋意見為您提供更多的機會來調(diào)整您的力量。反饋可以讓您把握住正確的方向，少走彎路。
　

4）勇氣
　　勇氣存在于其它三個價值的環(huán)境中。它們相互支持。需要勇氣來相信一路上具體反饋比預先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中其他人交流。需要勇氣來使系統(tǒng)盡可能簡單，將明天的決定推到明天做。而如果沒有簡單的系統(tǒng)、沒有不斷的交流來擴展知識、沒有掌握方向所依賴的反饋，勇氣也就失去了依靠。
　

　　XP 的方法將這些價值轉(zhuǎn)換成開發(fā)人員每天應(yīng)做的事情。這里沒什么新鮮內(nèi)容。多年以來，行業(yè)認識到 XP 方法是“最優(yōu)方法”。實際上，XP 中的“極端”來自兩方面：
　

　　XP 采取經(jīng)過證明的業(yè)界最優(yōu)方法并將其發(fā)揮到極致。
　

　　XP 將這些方法以某種方式進行結(jié)合，使它們產(chǎn)生的結(jié)果大于各部分的總和。

　　這是怎樣的情景呢？代碼復查是個好的做法，因此始終通過成對地編寫代碼來做到。測試也是個好的做法，因此總是通過在編寫代碼之前編寫測試來做到。文檔很少與代碼保持一致，因此只做那些最需要的事，余下的部分則取決于明確編寫的代碼和測試。XP 不保證人們總做正確的事，但它允許人們這樣做。它將這些“極端”方法以一種相互支持的方式結(jié)合起來，顯著提高了速度和有效性。

〈二〉XP 的十二種方法
　

　　XP 的十二種方法（如圖 2 所示）將其定義為規(guī)則。讓我們仔細研究每一個方法來對“執(zhí)行 XP”表示什么有個更全面的理解。
　

圖 2. XP 的十二種方法
　

1）規(guī)劃策略
　　有些人會指責 XP 是一種美其名的剽竊，只是一群牛仔在沒有任何規(guī)則的情況下將一個系統(tǒng)拼湊在一起。錯。XP 是為數(shù)不多的幾種承認您在開始時不可能事事通曉的方法之一。無論是用戶還是開發(fā)人員都是隨著項目的進展過程才逐步了解事物的。只有鼓勵和信奉這種更改的方法才是有效方法。狀態(tài)限定方法忽視更改。而 XP 則留心更改。它傾聽所用的方法就是“規(guī)劃策略”，一個由 Kent Beck 創(chuàng)造的概念。
　

　　這一方法背后的主要思想是迅速地制定粗略計劃，然后隨著事物的不斷清晰來逐步完善。規(guī)劃策略的產(chǎn)物包括：一堆索引卡，每一張都包含一個客戶素材，這些素材驅(qū)動項目的迭代；以及對下一兩個發(fā)行版的粗略計劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣（請參閱參考資料）。讓這種形式的計劃得以發(fā)揮作用的關(guān)鍵因素是讓用戶做企業(yè)決策，讓開發(fā)小組做技術(shù)決策。如果沒有這一前提，整個過程就會土崩瓦解。
　

　　開發(fā)小組要決定：估計開發(fā)一個素材要花多長時間 、使用各種技術(shù)選項所花費的成本 、團隊組織 、每個素材的“風險” 、迭代中素材開發(fā)的順序（先開發(fā)風險最大的那一個可以減輕風險）。
客戶需要決定： 范圍（一個發(fā)行版的素材和每一次迭代的素材） 、發(fā)行日期 、優(yōu)先級（根據(jù)企業(yè)價值先開發(fā)哪些特性）規(guī)劃經(jīng)常發(fā)生。這樣，在客戶或開發(fā)人員學習新事物的同時，就為他們調(diào)整計劃提供了頻繁機會。
　

2）成對編程
　　使用 XP，成對的開發(fā)人員編寫所有產(chǎn)品代碼。這種方式聽上去好象缺乏效率。Martin Fowler 說，“當人們說成對編程降低生產(chǎn)力時，我回答，‘那是因為大多數(shù)耗費時間的編程部分是靠輸入來完成的�！�”實際上，成對編程無論在經(jīng)濟還是其它方面都提供了許多好處： 所有設(shè)計決策都牽涉到至少兩個人、至少有兩個人熟悉系統(tǒng)的每一部分、幾乎不可能出現(xiàn)兩個人同時疏忽測試或其它任務(wù)、改變各對的組合在可以在團隊范圍內(nèi)傳播知識、代碼總是由至少一人復查。
　

　　研究還顯示成對的編程實際上比單獨編程更有效（有關(guān)詳細信息，請參閱參考資料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）。
　

3）測試
　　在 XP 中有兩種測試： 單元測試 、驗收測試 。
　

　　開發(fā)人員在他們編寫代碼的同時編寫單元測試�？蛻粼谒麄兌�義了素材后編寫驗收測試。單元測試及時告訴開發(fā)人員系統(tǒng)在某一點上是否“工作”。驗收測試告訴團隊系統(tǒng)是否執(zhí)行用戶希望它執(zhí)行的操作。
　

　　假設(shè)團隊使用的是如 Java 這樣的面向?qū)ο笳Z言，開發(fā)人員在為一些方法編寫代碼之前為每種有可能失敗的方法編寫單元測試。然后他們編寫足夠的代碼使之能通過測試。有時人們會發(fā)現(xiàn)這有點奇怪。答案很簡單。編寫測試首先為您提供：一組可能最完整的測試 、可能能工作的最簡單的代碼 、代碼意圖的明確景象 。
　

　　開發(fā)人員只有在通過所有單元測試后才可以將代碼檢入到源代碼資源庫中。單元測試使開發(fā)人員有信心相信他們的代碼能夠工作。這為其他開發(fā)人員留下線索，可以幫助他們理解最早的開發(fā)人員的意圖（實際上，這是我們看到過的最好的文檔）。單元測試還給了開發(fā)人員勇氣重新劃分代碼，因為測試失敗可以立刻告訴開發(fā)人員存在錯誤。應(yīng)該將單元測試自動化，并提供明確的通過／失敗結(jié)果。xUnit 框架（請參閱參考資料）做到的遠不止這些，因此大多數(shù) XP 小組都使用它們。
　

　　用戶負責確保每個素材都有驗收測試來確認它們。用戶可以自己編寫測試、可以征募組織中的其他成員（例如 QA 人員或業(yè)務(wù)分析員）編寫它們，也可以將這兩種方法結(jié)合起來。測試告訴他們系統(tǒng)是否具有應(yīng)該具有的那些特性，以及是否可以正確工作。理想情況下，用戶在迭代完成之前就應(yīng)該寫好迭代中那些素材的驗收測試了。應(yīng)該將驗收測試自動化，并要經(jīng)常運行來確保開發(fā)人員在實現(xiàn)新特性時沒有破壞任何現(xiàn)有的特性。通常情況下，客戶需要來自開發(fā)團隊的某些幫助來編寫驗收測試。我們對一個項目開發(fā)一個可重用的自動驗收測試框架，可以讓用戶在簡單編輯器中輸入他們的輸入和所期望的輸出�？蚣軐⑤斎朕D(zhuǎn)換成 XML 文件、運行文件中的測試，然后為每個測試顯示“通過”或“失敗”�？蛻粝矚g這一做法。
　

　　不是所有驗收測試都必須在所有情況下通過。問題是驗收測試幫助客戶衡量項目“完成”的情況如何。它們還可以讓客戶獲悉有關(guān)某些事物是否可以發(fā)行的決定。
　

4）重新劃分
　　重新劃分是在不更改功能性的前提下對代碼加以改進。XP 小組在進行重新劃分時毫不手軟。
　

　　開發(fā)人員重新劃分有兩個重要時機：實現(xiàn)特性之前和之后。開發(fā)人員嘗試確定更改現(xiàn)有代碼是否可以讓新特性的開發(fā)更容易。他們查看剛剛寫好的代碼，看是否有方法可以對它進行簡化。例如，如果他們認為有抽象的機會，就會進行重新劃分來從具體實現(xiàn)中除去重復的代碼。
　

　　XP 建議您應(yīng)該編寫可能運行的最簡單的代碼，但同時也建議您應(yīng)該不斷學習。重新劃分讓您將學到的知識加入到代碼中，同時又不會破壞測試。它使您的代碼簡練。這意味著它可以存在相當長的時間、為以后的開發(fā)人員引入更少問題，并為他們指引正確的方向。
　

5）簡單的設(shè)計
　　XP 的誹謗者說該過程忽略了設(shè)計。事實不是這樣。問題是重量型方法建議您做的不過是提前完成大部分瑣碎的設(shè)計任務(wù)。這就象是拍一張靜態(tài)的地平線的照片，靜止不動，然后嘗試畫一張如何到達那里的完美的地圖。XP 說設(shè)計不應(yīng)該在事物將保持不變的前提下預先倉促進行。XP 認為設(shè)計非常重要，因此應(yīng)該是一個持續(xù)的事務(wù)。我們總是先嘗試使用能夠工作的最簡單的設(shè)計，然后隨著現(xiàn)實的不斷顯現(xiàn)來更改它。
　

　　什么是可能工作的最簡單的設(shè)計？它是符合以下條件的設(shè)計（感謝 Kent Beck 為我們一一列出）： 運行所有測試 、不包含重復代碼 、明確陳述程序員對所有代碼的意圖 、包含盡可能最少的類和方法 。
　

　　對簡單設(shè)計的需求并不是說所有設(shè)計都很小，也不表示它們是無足輕重的。它們只不過需要盡可能簡單，但是仍能工作。不要包括不使用的額外特性。我們稱這樣的事物為 YAGNI，表示“您將不需要它（You Aren't Going to Need It）�！辈灰�讓 YAGNI 破壞您成功的機會。
　

6）集合體代碼所有權(quán)
　　小組中的任何人都應(yīng)該有權(quán)對代碼進行更改來改進它。每個人都擁有全部代碼，這意味著每個人都對它負責。這種技術(shù)可以讓人們對部分代碼進行必要的更改而不用經(jīng)過代碼擁有者個人的瓶頸。每個人都負責這一事實消除了無代碼所有權(quán)所帶來的混亂。
　

　　“每人擁有所有代碼”與“沒人擁有代碼”的說法并不一樣。沒人擁有代碼時，人們可以隨處進行破壞而不必負任何責任。而 XP 說，“如果是您破壞的，應(yīng)該您來彌補�！蔽覀冇幸恍┍仨氃诿看渭�成之前和之后運行的單元測試。如果您破壞了某些事物，您要負責進行修補，無論它位于代碼的哪一部分。這需要極端規(guī)則�？赡苓@是名稱中帶有“極端”的另一個原因。
　

7）持續(xù)的集成
　　經(jīng)常進行代碼集成可以幫助您避免集成夢魘。XP 團隊在一天中集成了代碼幾次，每次都在所有單元測試對系統(tǒng)運行后執(zhí)行。
　

　　傳統(tǒng)方法工作方式如下：編寫大量代碼后執(zhí)行一次大爆炸式的集成，然后花費相當長的時間來改正問題。這種笨拙的形式的確使項目速度減緩。大爆炸式的集成給團隊立即帶來大量問題，并且這些問題通常都有幾百種可能的原因。如果經(jīng)常進行集成，任何特定集成失敗的原因都會非常明顯（以前運行過測試，因此錯誤一定是新事物犯下的）。使用這種方法，當遇到問題時，可能的原因就相當有限。修改起來更容易，花的時間少得多，使團隊保持最快速度前進。
　

8）現(xiàn)場客戶
　　要使功能最理想，XP 小組需要在現(xiàn)場有一位客戶來明確素材，并做出重要的企業(yè)決策。開發(fā)人員是不允許單獨做這些事情的。讓客戶隨時在場可以消除開發(fā)人員等待決策時出現(xiàn)的瓶頸。
　

　　XP 不會假裝素材卡是開發(fā)人員交付必要代碼所需的唯一指示。素材是對以后在客戶和開發(fā)人員之間填寫細節(jié)的對話的一項承諾。與將所有要求寫在一個靜態(tài)文檔中不同，其思想是進行面對面的交流，減少產(chǎn)生誤解的機會。
　

　　我們發(fā)現(xiàn)讓客戶在現(xiàn)場是可能最好的一種情形，但這不是解決問題的唯一方案。底線是客戶必須隨時在需要回答問題和根據(jù)企業(yè)價值為團隊提供指示時有空。如果客戶并非在現(xiàn)場專職陪伴團隊的情況下就能做到這些，那很好。如果能和團隊待在一起，這會更方便，但只是建議而已。
　

9）小發(fā)行版
　　發(fā)行版應(yīng)該盡可能地小，同時仍然提供足夠的企業(yè)價值以證明它們值得。
　

　　只要覺得有意義就可以發(fā)布系統(tǒng)。這樣就盡可能早為用戶提供了價值（請記住，今天的錢比明天的錢來得值錢）。小發(fā)行版將為開發(fā)人員提供具體的反饋意見，告訴他們哪些符合客戶需要，哪些不符合客戶需要。然后，小組可以將這些經(jīng)驗教訓包括在其下一發(fā)行版的規(guī)劃中。
　

10）一周 40 小時
　　Kent Beck 說他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿足�！币恢� 40 小時工作可以讓您做到這一點。確切的小時數(shù)并不重要，重要的是原則。長時間地持續(xù)工作會扼殺工作績效。疲勞的開發(fā)人員會犯更多錯誤，從長期來說，將比按“正常”時間表進行的開發(fā)慢得多。
　

　　即使開發(fā)人員可以在長時間很好工作，這也不意味著他們應(yīng)該這樣。最終他們會厭倦，會離開他們的工作，或者產(chǎn)生影響他們工作績效的非工作問題。如果您打亂了人們的生活，將會嘗到它所帶來的惡果。加班并不是解決項目問題的答案。實際上，它是更大問題的癥狀。如果您要走向滅亡，就無藥可救了。
　

11）編碼標準
　　　擁有編碼標準有兩個目的：a.防止團隊被一些例如事物沒有以最大速度發(fā)展這種無關(guān)緊要的愚蠢爭論搞得不知所措；b.它支持其它方法。
　

　　如果沒有編碼標準，重新劃分代碼會更加困難，按應(yīng)當?shù)念l度交換對更困難，快速前進也更困難。目標應(yīng)該是團隊中沒有人辨認得出是誰寫的哪一部分代碼。以團隊為單位對某一標準達成協(xié)議，然后遵守這一標準。目標不是創(chuàng)建一個事無巨細的規(guī)則列表，而是提供將確保您的代碼可以清晰交流的指導方針。編碼標準開始時應(yīng)該很簡單，然后根據(jù)團隊經(jīng)驗逐步進化。不要預先花費太多時間。創(chuàng)建能夠工作的最簡單標準，然后逐步發(fā)展。
　

12）系統(tǒng)比喻
　　體系結(jié)構(gòu)是做什么用的？它提供了系統(tǒng)各種組件以及它們是如何交互的畫面 -- 一種映射，可以讓開發(fā)人員了解新的代碼部分適合放在哪里。
　

　　XP 中的系統(tǒng)比喻與大多數(shù)方法稱作的體系結(jié)構(gòu)差不多。比喻為團隊提供了一致的畫面，他們可以用它來描述現(xiàn)有系統(tǒng)的工作方式、新部件適合的位置，以及它們應(yīng)該采取的形式。
　

　　重要的是要記住，關(guān)鍵要讓每個人理解系統(tǒng)是如何組合在一起的，而不是美麗的比喻。有時您就是無法想到一個好的比喻。想到時就太好了。

〈三〉一起工作的方法
　

　　整體大于各個部分之和。您可以實現(xiàn)單一方法或一小部分方法，比不使用任何方法得到更大收益。但您只能在實現(xiàn)所有方法的情況下獲得最大收益，因為它們的力量來自它們之間的交互。
　

　　最初時按照書籍來執(zhí)行 XP，作為基準。一旦理解了如何進行交互，就擁有了將它們適應(yīng)于自身環(huán)境所需的知識。請記住，“進行 XP”不是目的，而是到達終點的一種手段。目標是快速地開發(fā)高級軟件。如果您的過程有一些變異，已稱不上是在進行 XP，但結(jié)果仍能讓您戰(zhàn)勝所有競爭對手，您已經(jīng)成功了。

〈四〉為什么 XP 很重要
　

　　坦率地說，XP（或者任何其它靈活方法）根本就不重要。它能夠產(chǎn)生的結(jié)果才是關(guān)鍵。如果如 XP 這樣的靈活方式可以幫助您更快地開發(fā)更好的軟件而少受痛苦，那么它值得考慮。
　

　　還記得我們在這篇文章開始時提到的那些令人生畏的數(shù)字嗎？我們相信使用 XP 開發(fā)面向?qū)ο筌浖�可以有機會將它們變得更好。目前我們的經(jīng)驗已經(jīng)證實了這一信念。

〈五〉參考資料
　

　　在 RoleModel Software 的 XP Portal 中了解有關(guān) XP 的詳細信息。
　　可以在 Alistair Cockburn 和 Laurie Williams (XP2000 submission, 2000) 所著的 The Costs and 　　Benefits of Pair Programming 中了解到有關(guān)成對編程所具有的經(jīng)濟方面的意義。
　　在 Pairprogramming.com 上可以知道成對編程的常規(guī)詳細信息。
　　下載 xUnit 測試工具。
　　如果您希望了解有關(guān) XP 的詳細信息，請務(wù)必選取一本本書中引用的書籍：
　　Planning Extreme Programming，由 Kent Beck 和 Martin Fowler 著 (Addison-Wesley, 2000)
　　Extreme Programming Explained: Embrace Change，由 Kent Beck 著 (Addison-Wesley, 1999)
　　Leading the Revolution 由 Gary Hamel 著 (Harvard Business School, 2000)
　　Jeff Canna 有關(guān)單元和功能測試的文章 （developerWorks，2001 年 3 月）將 XP 哲學用在測試上。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標題：采用XP方法使ERP軟件項目獲得更大成功

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/1082025799.html