使用面向?qū)ο缶幊套兊每涨捌占啊Ｋ管浖_(kāi)發(fā)發(fā)生了某種程度上的變革，但最近的研究表明，有半數(shù)的軟件開(kāi)發(fā)項(xiàng)目滯后，而三分之一的項(xiàng)目則超出預(yù)算。問(wèn)題不在于技術(shù)，而是開(kāi)發(fā)軟件所使用的方法。所謂的“輕量型”或“靈活”方式，與面向?qū)ο笳Z(yǔ)言的威力和靈活性結(jié)合起來(lái)，提供了一種很有意思的解決方案。最常見(jiàn)的靈活方式稱為極端編程（Extreme Programming）或者 XP，但許多人并不真正了解它。對(duì)軟件項(xiàng)目使用 XP 可以大大增加成功的機(jī)會(huì)。本文提供了 XP 的概述，并解釋了它為什么很重要 -- 不是傳言，也沒(méi)有騙局。
在過(guò)去的十年中，CEO 們?cè)诋a(chǎn)生穩(wěn)步增加的收入方面面臨巨大的壓力。他們通過(guò)在許多方面采取一系列舉措來(lái)解決這一問(wèn)題，例如縮小公司規(guī)模、外包、再工程、企業(yè)資源規(guī)劃 (ERP) 等等。這些對(duì)低效率的解決措施讓 S&P 500 中的許多企業(yè)在 90 年代末能夠連續(xù)幾年保持兩位數(shù)的收入增長(zhǎng)。但這種方式也帶來(lái)了一些負(fù)面影響。
在 Gary Hamel 所著的 Leading the Revolution（請(qǐng)參閱參考資料）一書中，他聲稱已有一些跡象證明傳統(tǒng)企業(yè)模式的優(yōu)勢(shì)已不那么明顯。我們必須找到一些替代方法來(lái)為收入的持續(xù)增長(zhǎng)提供動(dòng)力。他建議唯一能讓公司繼續(xù)增長(zhǎng)的辦法是進(jìn)行一次徹底的創(chuàng)新。我們認(rèn)為在軟件開(kāi)發(fā)領(lǐng)域中尤其需要這樣。
企業(yè)問(wèn)題
如果使用標(biāo)準(zhǔn)軟件開(kāi)發(fā)方法，那么即使在常用的平臺(tái)上進(jìn)行開(kāi)發(fā)，也要做好失望的準(zhǔn)備。如圖 1 所示，最近的研究表明，有一半項(xiàng)目將滯后，而三分之一的項(xiàng)目將超過(guò)預(yù)算。這一推測(cè)比 1979 年由美國(guó)總審計(jì)局的研究結(jié)果好不了多少。
圖 1. 軟件項(xiàng)目成功和失敗，過(guò)去和現(xiàn)在
如果我們希望這些數(shù)字有顯著提高，則需要徹底創(chuàng)新的方法來(lái)開(kāi)發(fā)軟件。有兩個(gè)主要因素影響現(xiàn)有的方法： 懼怕失敗、對(duì)軟件本質(zhì)的誤解。
沒(méi)有人打算失敗。具有諷刺意味的是為使失敗最小化而創(chuàng)建的方法是失敗的。對(duì)軟件的誤解是問(wèn)題的根源。恐懼實(shí)際上只是一種癥狀。現(xiàn)有的方法是由那些有良好愿望但忘記了軟件中的“軟”的那些聰明人所創(chuàng)建的。他們假定開(kāi)發(fā)軟件就象造橋。因此他們從各種設(shè)計(jì)規(guī)范中借鑒了一些適用于“硬”物體（例如橋梁）的最優(yōu)方法。結(jié)果是基于 Big Design Up-front (BDUF) 思想的反映遲鈍的開(kāi)發(fā)方法，軟件不堪一擊，人們無(wú)法使用它們。
〈一〉一種解決方案：靈活方法
最近發(fā)生了一些轉(zhuǎn)變，從所謂的“重量型”方法轉(zhuǎn)向了“輕量型”或“靈活”方法，例如 Crystal 方法、適應(yīng)性軟件開(kāi)發(fā)和（當(dāng)前最流行的）XP。所有這些過(guò)程都有這樣一個(gè)事實(shí)，即需要人們共同來(lái)開(kāi)發(fā)軟件。成功的軟件過(guò)程必須將人們的長(zhǎng)處最大化，將他們的缺點(diǎn)最小化，因?yàn)閮?yōu)點(diǎn)和缺點(diǎn)毋庸質(zhì)疑都存在。在我們看來(lái)，XP 最出色的地方在于它能夠解決所有影響參加人員的互補(bǔ)力量。
XP 提供了十年來(lái)最大的一次機(jī)會(huì)，給軟件開(kāi)發(fā)過(guò)程帶來(lái)徹底變革。就象 Peopleware 作家 Tom DeMarco 所說(shuō)，“XP 是當(dāng)今我們所處領(lǐng)域中最重要的一項(xiàng)運(yùn)動(dòng)。預(yù)計(jì)它對(duì)于目前一代的重要性就象 SEI 及其能力成熟度模型對(duì)上一代的重要性一樣。”
XP 規(guī)定了一組核心價(jià)值和方法，可以讓軟件開(kāi)發(fā)人員發(fā)揮他們的專長(zhǎng)：編寫代碼。XP 消除了大多數(shù)重量型過(guò)程的不必要產(chǎn)物，通過(guò)減慢開(kāi)發(fā)速度、耗費(fèi)開(kāi)發(fā)人員的精力（例如干特圖、狀態(tài)報(bào)告，以及多卷需求文檔）從目標(biāo)偏離。我們認(rèn)識(shí)到一個(gè)稱為“極端編程”的東西可能很難作為正式的開(kāi)發(fā)過(guò)程推薦給管理層，但如果您的公司從事軟件行業(yè)，您應(yīng)該幫助管理層繞過(guò)其名稱認(rèn)識(shí)到 XP 可以提供的競(jìng)爭(zhēng)優(yōu)勢(shì)。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價(jià)值（請(qǐng)參閱參考資料）。我們對(duì)它們進(jìn)行了總結(jié)：
1）交流
項(xiàng)目的問(wèn)題往往可以追溯到某人在某個(gè)時(shí)刻沒(méi)有和其他人一起商量某些重要問(wèn)題上。使用 XP，不交流是不可能的事。
2）簡(jiǎn)單
XP 建議您總是盡可能圍繞過(guò)程和編寫代碼做最簡(jiǎn)單的事情。按照 Beck 的說(shuō)法，“XP 就是打賭。它打賭今天最好做些簡(jiǎn)單的事...而不是做更復(fù)雜但可能永遠(yuǎn)也不會(huì)用到的事。”
3）反饋
更早和經(jīng)常來(lái)自客戶、團(tuán)隊(duì)和實(shí)際最終用戶的具體反饋意見(jiàn)為您提供更多的機(jī)會(huì)來(lái)調(diào)整您的力量。反饋可以讓您把握住正確的方向，少走彎路。
4）勇氣
勇氣存在于其它三個(gè)價(jià)值的環(huán)境中。它們相互支持。需要勇氣來(lái)相信一路上具體反饋比預(yù)先知道每樣事物來(lái)得更好。需要勇氣來(lái)在可能暴露您的無(wú)知時(shí)與團(tuán)隊(duì)中其他人交流。需要勇氣來(lái)使系統(tǒng)盡可能簡(jiǎn)單，將明天的決定推到明天做。而如果沒(méi)有簡(jiǎn)單的系統(tǒng)、沒(méi)有不斷的交流來(lái)擴(kuò)展知識(shí)、沒(méi)有掌握方向所依賴的反饋，勇氣也就失去了依靠。
XP 的方法將這些價(jià)值轉(zhuǎn)換成開(kāi)發(fā)人員每天應(yīng)做的事情。這里沒(méi)什么新鮮內(nèi)容。多年以來(lái)，行業(yè)認(rèn)識(shí)到 XP 方法是“最優(yōu)方法”。實(shí)際上，XP 中的“極端”來(lái)自兩方面：
XP 采取經(jīng)過(guò)證明的業(yè)界最優(yōu)方法并將其發(fā)揮到極致。
XP 將這些方法以某種方式進(jìn)行結(jié)合，使它們產(chǎn)生的結(jié)果大于各部分的總和。
這是怎樣的情景呢？代碼復(fù)查是個(gè)好的做法，因此始終通過(guò)成對(duì)地編寫代碼來(lái)做到。測(cè)試也是個(gè)好的做法，因此總是通過(guò)在編寫代碼之前編寫測(cè)試來(lái)做到。文檔很少與代碼保持一致，因此只做那些最需要的事，余下的部分則取決于明確編寫的代碼和測(cè)試。XP 不保證人們總做正確的事，但它允許人們這樣做。它將這些“極端”方法以一種相互支持的方式結(jié)合起來(lái)，顯著提高了速度和有效性。
〈二〉XP 的十二種方法
XP 的十二種方法（如圖 2 所示）將其定義為規(guī)則。讓我們仔細(xì)研究每一個(gè)方法來(lái)對(duì)“執(zhí)行 XP”表示什么有個(gè)更全面的理解。
圖 2. XP 的十二種方法
1）規(guī)劃策略
有些人會(huì)指責(zé) XP 是一種美其名的剽竊，只是一群牛仔在沒(méi)有任何規(guī)則的情況下將一個(gè)系統(tǒng)拼湊在一起。錯(cuò)。XP 是為數(shù)不多的幾種承認(rèn)您在開(kāi)始時(shí)不可能事事通曉的方法之一。無(wú)論是用戶還是開(kāi)發(fā)人員都是隨著項(xiàng)目的進(jìn)展過(guò)程才逐步了解事物的。只有鼓勵(lì)和信奉這種更改的方法才是有效方法。狀態(tài)限定方法忽視更改。而 XP 則留心更改。它傾聽(tīng)所用的方法就是“規(guī)劃策略”，一個(gè)由 Kent Beck 創(chuàng)造的概念。
這一方法背后的主要思想是迅速地制定粗略計(jì)劃，然后隨著事物的不斷清晰來(lái)逐步完善。規(guī)劃策略的產(chǎn)物包括：一堆索引卡，每一張都包含一個(gè)客戶素材，這些素材驅(qū)動(dòng)項(xiàng)目的迭代；以及對(duì)下一兩個(gè)發(fā)行版的粗略計(jì)劃，如 Kent Beck 和 Martin Fowler 在他們的 Planning Extreme Programming 中描述的那樣（請(qǐng)參閱參考資料）。讓這種形式的計(jì)劃得以發(fā)揮作用的關(guān)鍵因素是讓用戶做企業(yè)決策，讓開(kāi)發(fā)小組做技術(shù)決策。如果沒(méi)有這一前提，整個(gè)過(guò)程就會(huì)土崩瓦解。
開(kāi)發(fā)小組要決定：估計(jì)開(kāi)發(fā)一個(gè)素材要花多長(zhǎng)時(shí)間 、使用各種技術(shù)選項(xiàng)所花費(fèi)的成本 、團(tuán)隊(duì)組織 、每個(gè)素材的“風(fēng)險(xiǎn)” 、迭代中素材開(kāi)發(fā)的順序（先開(kāi)發(fā)風(fēng)險(xiǎn)最大的那一個(gè)可以減輕風(fēng)險(xiǎn)）。
客戶需要決定： 范圍（一個(gè)發(fā)行版的素材和每一次迭代的素材） 、發(fā)行日期 、優(yōu)先級(jí)（根據(jù)企業(yè)價(jià)值先開(kāi)發(fā)哪些特性）規(guī)劃經(jīng)常發(fā)生。這樣，在客戶或開(kāi)發(fā)人員學(xué)習(xí)新事物的同時(shí)，就為他們調(diào)整計(jì)劃提供了頻繁機(jī)會(huì)。
2）成對(duì)編程
使用 XP，成對(duì)的開(kāi)發(fā)人員編寫所有產(chǎn)品代碼。這種方式聽(tīng)上去好象缺乏效率。Martin Fowler 說(shuō)，“當(dāng)人們說(shuō)成對(duì)編程降低生產(chǎn)力時(shí)，我回答，‘那是因?yàn)榇蠖鄶?shù)耗費(fèi)時(shí)間的編程部分是靠輸入來(lái)完成的。’”實(shí)際上，成對(duì)編程無(wú)論在經(jīng)濟(jì)還是其它方面都提供了許多好處： 所有設(shè)計(jì)決策都牽涉到至少兩個(gè)人、至少有兩個(gè)人熟悉系統(tǒng)的每一部分、幾乎不可能出現(xiàn)兩個(gè)人同時(shí)疏忽測(cè)試或其它任務(wù)、改變各對(duì)的組合在可以在團(tuán)隊(duì)范圍內(nèi)傳播知識(shí)、代碼總是由至少一人復(fù)查。
研究還顯示成對(duì)的編程實(shí)際上比單獨(dú)編程更有效（有關(guān)詳細(xì)信息，請(qǐng)參閱參考資料中 Alistair Cockburn 和 Laurie Williams 所著的 The Costs and Benefits of Pair Programming）。
3）測(cè)試
在 XP 中有兩種測(cè)試： 單元測(cè)試 、驗(yàn)收測(cè)試 。
開(kāi)發(fā)人員在他們編寫代碼的同時(shí)編寫單元測(cè)試。客戶在他們定義了素材后編寫驗(yàn)收測(cè)試。單元測(cè)試及時(shí)告訴開(kāi)發(fā)人員系統(tǒng)在某一點(diǎn)上是否“工作”。驗(yàn)收測(cè)試告訴團(tuán)隊(duì)系統(tǒng)是否執(zhí)行用戶希望它執(zhí)行的操作。
假設(shè)團(tuán)隊(duì)使用的是如 Java 這樣的面向?qū)ο笳Z(yǔ)言，開(kāi)發(fā)人員在為一些方法編寫代碼之前為每種有可能失敗的方法編寫單元測(cè)試。然后他們編寫足夠的代碼使之能通過(guò)測(cè)試。有時(shí)人們會(huì)發(fā)現(xiàn)這有點(diǎn)奇怪。答案很簡(jiǎn)單。編寫測(cè)試首先為您提供：一組可能最完整的測(cè)試 、可能能工作的最簡(jiǎn)單的代碼 、代碼意圖的明確景象 。
開(kāi)發(fā)人員只有在通過(guò)所有單元測(cè)試后才可以將代碼檢入到源代碼資源庫(kù)中。單元測(cè)試使開(kāi)發(fā)人員有信心相信他們的代碼能夠工作。這為其他開(kāi)發(fā)人員留下線索，可以幫助他們理解最早的開(kāi)發(fā)人員的意圖（實(shí)際上，這是我們看到過(guò)的最好的文檔）。單元測(cè)試還給了開(kāi)發(fā)人員勇氣重新劃分代碼，因?yàn)闇y(cè)試失敗可以立刻告訴開(kāi)發(fā)人員存在錯(cuò)誤。應(yīng)該將單元測(cè)試自動(dòng)化，并提供明確的通過(guò)／失敗結(jié)果。xUnit 框架（請(qǐng)參閱參考資料）做到的遠(yuǎn)不止這些，因此大多數(shù) XP 小組都使用它們。
用戶負(fù)責(zé)確保每個(gè)素材都有驗(yàn)收測(cè)試來(lái)確認(rèn)它們。用戶可以自己編寫測(cè)試、可以征募組織中的其他成員（例如 QA 人員或業(yè)務(wù)分析員）編寫它們，也可以將這兩種方法結(jié)合起來(lái)。測(cè)試告訴他們系統(tǒng)是否具有應(yīng)該具有的那些特性，以及是否可以正確工作。理想情況下，用戶在迭代完成之前就應(yīng)該寫好迭代中那些素材的驗(yàn)收測(cè)試了。應(yīng)該將驗(yàn)收測(cè)試自動(dòng)化，并要經(jīng)常運(yùn)行來(lái)確保開(kāi)發(fā)人員在實(shí)現(xiàn)新特性時(shí)沒(méi)有破壞任何現(xiàn)有的特性。通常情況下，客戶需要來(lái)自開(kāi)發(fā)團(tuán)隊(duì)的某些幫助來(lái)編寫驗(yàn)收測(cè)試。我們對(duì)一個(gè)項(xiàng)目開(kāi)發(fā)一個(gè)可重用的自動(dòng)驗(yàn)收測(cè)試框架，可以讓用戶在簡(jiǎn)單編輯器中輸入他們的輸入和所期望的輸出。框架將輸入轉(zhuǎn)換成 XML 文件、運(yùn)行文件中的測(cè)試，然后為每個(gè)測(cè)試顯示“通過(guò)”或“失敗”。客戶喜歡這一做法。
不是所有驗(yàn)收測(cè)試都必須在所有情況下通過(guò)。問(wèn)題是驗(yàn)收測(cè)試幫助客戶衡量項(xiàng)目“完成”的情況如何。它們還可以讓客戶獲悉有關(guān)某些事物是否可以發(fā)行的決定。
4）重新劃分
重新劃分是在不更改功能性的前提下對(duì)代碼加以改進(jìn)。XP 小組在進(jìn)行重新劃分時(shí)毫不手軟。
開(kāi)發(fā)人員重新劃分有兩個(gè)重要時(shí)機(jī)：實(shí)現(xiàn)特性之前和之后。開(kāi)發(fā)人員嘗試確定更改現(xiàn)有代碼是否可以讓新特性的開(kāi)發(fā)更容易。他們查看剛剛寫好的代碼，看是否有方法可以對(duì)它進(jìn)行簡(jiǎn)化。例如，如果他們認(rèn)為有抽象的機(jī)會(huì)，就會(huì)進(jìn)行重新劃分來(lái)從具體實(shí)現(xiàn)中除去重復(fù)的代碼。
XP 建議您應(yīng)該編寫可能運(yùn)行的最簡(jiǎn)單的代碼，但同時(shí)也建議您應(yīng)該不斷學(xué)習(xí)。重新劃分讓您將學(xué)到的知識(shí)加入到代碼中，同時(shí)又不會(huì)破壞測(cè)試。它使您的代碼簡(jiǎn)練。這意味著它可以存在相當(dāng)長(zhǎng)的時(shí)間、為以后的開(kāi)發(fā)人員引入更少問(wèn)題，并為他們指引正確的方向。
5）簡(jiǎn)單的設(shè)計(jì)
XP 的誹謗者說(shuō)該過(guò)程忽略了設(shè)計(jì)。事實(shí)不是這樣。問(wèn)題是重量型方法建議您做的不過(guò)是提前完成大部分瑣碎的設(shè)計(jì)任務(wù)。這就象是拍一張靜態(tài)的地平線的照片，靜止不動(dòng)，然后嘗試畫一張如何到達(dá)那里的完美的地圖。XP 說(shuō)設(shè)計(jì)不應(yīng)該在事物將保持不變的前提下預(yù)先倉(cāng)促進(jìn)行。XP 認(rèn)為設(shè)計(jì)非常重要，因此應(yīng)該是一個(gè)持續(xù)的事務(wù)。我們總是先嘗試使用能夠工作的最簡(jiǎn)單的設(shè)計(jì)，然后隨著現(xiàn)實(shí)的不斷顯現(xiàn)來(lái)更改它。
什么是可能工作的最簡(jiǎn)單的設(shè)計(jì)？它是符合以下條件的設(shè)計(jì)（感謝 Kent Beck 為我們一一列出）： 運(yùn)行所有測(cè)試 、不包含重復(fù)代碼 、明確陳述程序員對(duì)所有代碼的意圖 、包含盡可能最少的類和方法 。
對(duì)簡(jiǎn)單設(shè)計(jì)的需求并不是說(shuō)所有設(shè)計(jì)都很小，也不表示它們是無(wú)足輕重的。它們只不過(guò)需要盡可能簡(jiǎn)單，但是仍能工作。不要包括不使用的額外特性。我們稱這樣的事物為 YAGNI，表示“您將不需要它（You Aren't Going to Need It）。”不要讓 YAGNI 破壞您成功的機(jī)會(huì)。
6）集合體代碼所有權(quán)
小組中的任何人都應(yīng)該有權(quán)對(duì)代碼進(jìn)行更改來(lái)改進(jìn)它。每個(gè)人都擁有全部代碼，這意味著每個(gè)人都對(duì)它負(fù)責(zé)。這種技術(shù)可以讓人們對(duì)部分代碼進(jìn)行必要的更改而不用經(jīng)過(guò)代碼擁有者個(gè)人的瓶頸。每個(gè)人都負(fù)責(zé)這一事實(shí)消除了無(wú)代碼所有權(quán)所帶來(lái)的混亂。
“每人擁有所有代碼”與“沒(méi)人擁有代碼”的說(shuō)法并不一樣。沒(méi)人擁有代碼時(shí)，人們可以隨處進(jìn)行破壞而不必負(fù)任何責(zé)任。而 XP 說(shuō)，“如果是您破壞的，應(yīng)該您來(lái)彌補(bǔ)。”我們有一些必須在每次集成之前和之后運(yùn)行的單元測(cè)試。如果您破壞了某些事物，您要負(fù)責(zé)進(jìn)行修補(bǔ)，無(wú)論它位于代碼的哪一部分。這需要極端規(guī)則。可能這是名稱中帶有“極端”的另一個(gè)原因。
7）持續(xù)的集成
經(jīng)常進(jìn)行代碼集成可以幫助您避免集成夢(mèng)魘。XP 團(tuán)隊(duì)在一天中集成了代碼幾次，每次都在所有單元測(cè)試對(duì)系統(tǒng)運(yùn)行后執(zhí)行。
傳統(tǒng)方法工作方式如下：編寫大量代碼后執(zhí)行一次大爆炸式的集成，然后花費(fèi)相當(dāng)長(zhǎng)的時(shí)間來(lái)改正問(wèn)題。這種笨拙的形式的確使項(xiàng)目速度減緩。大爆炸式的集成給團(tuán)隊(duì)立即帶來(lái)大量問(wèn)題，并且這些問(wèn)題通常都有幾百種可能的原因。如果經(jīng)常進(jìn)行集成，任何特定集成失敗的原因都會(huì)非常明顯（以前運(yùn)行過(guò)測(cè)試，因此錯(cuò)誤一定是新事物犯下的）。使用這種方法，當(dāng)遇到問(wèn)題時(shí)，可能的原因就相當(dāng)有限。修改起來(lái)更容易，花的時(shí)間少得多，使團(tuán)隊(duì)保持最快速度前進(jìn)。
8）現(xiàn)場(chǎng)客戶
要使功能最理想，XP 小組需要在現(xiàn)場(chǎng)有一位客戶來(lái)明確素材，并做出重要的企業(yè)決策。開(kāi)發(fā)人員是不允許單獨(dú)做這些事情的。讓客戶隨時(shí)在場(chǎng)可以消除開(kāi)發(fā)人員等待決策時(shí)出現(xiàn)的瓶頸。
XP 不會(huì)假裝素材卡是開(kāi)發(fā)人員交付必要代碼所需的唯一指示。素材是對(duì)以后在客戶和開(kāi)發(fā)人員之間填寫細(xì)節(jié)的對(duì)話的一項(xiàng)承諾。與將所有要求寫在一個(gè)靜態(tài)文檔中不同，其思想是進(jìn)行面對(duì)面的交流，減少產(chǎn)生誤解的機(jī)會(huì)。
我們發(fā)現(xiàn)讓客戶在現(xiàn)場(chǎng)是可能最好的一種情形，但這不是解決問(wèn)題的唯一方案。底線是客戶必須隨時(shí)在需要回答問(wèn)題和根據(jù)企業(yè)價(jià)值為團(tuán)隊(duì)提供指示時(shí)有空。如果客戶并非在現(xiàn)場(chǎng)專職陪伴團(tuán)隊(duì)的情況下就能做到這些，那很好。如果能和團(tuán)隊(duì)待在一起，這會(huì)更方便，但只是建議而已。
9）小發(fā)行版
發(fā)行版應(yīng)該盡可能地小，同時(shí)仍然提供足夠的企業(yè)價(jià)值以證明它們值得。
只要覺(jué)得有意義就可以發(fā)布系統(tǒng)。這樣就盡可能早為用戶提供了價(jià)值（請(qǐng)記住，今天的錢比明天的錢來(lái)得值錢）。小發(fā)行版將為開(kāi)發(fā)人員提供具體的反饋意見(jiàn)，告訴他們哪些符合客戶需要，哪些不符合客戶需要。然后，小組可以將這些經(jīng)驗(yàn)教訓(xùn)包括在其下一發(fā)行版的規(guī)劃中。
10）一周 40 小時(shí)
Kent Beck 說(shuō)他希望“...每天早晨都感到有活力有激情，每天晚上都感到疲憊而滿足。”一周 40 小時(shí)工作可以讓您做到這一點(diǎn)。確切的小時(shí)數(shù)并不重要，重要的是原則。長(zhǎng)時(shí)間地持續(xù)工作會(huì)扼殺工作績(jī)效。疲勞的開(kāi)發(fā)人員會(huì)犯更多錯(cuò)誤，從長(zhǎng)期來(lái)說(shuō)，將比按“正常”時(shí)間表進(jìn)行的開(kāi)發(fā)慢得多。
即使開(kāi)發(fā)人員可以在長(zhǎng)時(shí)間很好工作，這也不意味著他們應(yīng)該這樣。最終他們會(huì)厭倦，會(huì)離開(kāi)他們的工作，或者產(chǎn)生影響他們工作績(jī)效的非工作問(wèn)題。如果您打亂了人們的生活，將會(huì)嘗到它所帶來(lái)的惡果。加班并不是解決項(xiàng)目問(wèn)題的答案。實(shí)際上，它是更大問(wèn)題的癥狀。如果您要走向滅亡，就無(wú)藥可救了。
11）編碼標(biāo)準(zhǔn)
擁有編碼標(biāo)準(zhǔn)有兩個(gè)目的：a.防止團(tuán)隊(duì)被一些例如事物沒(méi)有以最大速度發(fā)展這種無(wú)關(guān)緊要的愚蠢爭(zhēng)論搞得不知所措；b.它支持其它方法。
如果沒(méi)有編碼標(biāo)準(zhǔn)，重新劃分代碼會(huì)更加困難，按應(yīng)當(dāng)?shù)念l度交換對(duì)更困難，快速前進(jìn)也更困難。目標(biāo)應(yīng)該是團(tuán)隊(duì)中沒(méi)有人辨認(rèn)得出是誰(shuí)寫的哪一部分代碼。以團(tuán)隊(duì)為單位對(duì)某一標(biāo)準(zhǔn)達(dá)成協(xié)議，然后遵守這一標(biāo)準(zhǔn)。目標(biāo)不是創(chuàng)建一個(gè)事無(wú)巨細(xì)的規(guī)則列表，而是提供將確保您的代碼可以清晰交流的指導(dǎo)方針。編碼標(biāo)準(zhǔn)開(kāi)始時(shí)應(yīng)該很簡(jiǎn)單，然后根據(jù)團(tuán)隊(duì)經(jīng)驗(yàn)逐步進(jìn)化。不要預(yù)先花費(fèi)太多時(shí)間。創(chuàng)建能夠工作的最簡(jiǎn)單標(biāo)準(zhǔn)，然后逐步發(fā)展。
12）系統(tǒng)比喻
體系結(jié)構(gòu)是做什么用的？它提供了系統(tǒng)各種組件以及它們是如何交互的畫面 -- 一種映射，可以讓開(kāi)發(fā)人員了解新的代碼部分適合放在哪里。
XP 中的系統(tǒng)比喻與大多數(shù)方法稱作的體系結(jié)構(gòu)差不多。比喻為團(tuán)隊(duì)提供了一致的畫面，他們可以用它來(lái)描述現(xiàn)有系統(tǒng)的工作方式、新部件適合的位置，以及它們應(yīng)該采取的形式。
重要的是要記住，關(guān)鍵要讓每個(gè)人理解系統(tǒng)是如何組合在一起的，而不是美麗的比喻。有時(shí)您就是無(wú)法想到一個(gè)好的比喻。想到時(shí)就太好了。
〈三〉一起工作的方法
整體大于各個(gè)部分之和。您可以實(shí)現(xiàn)單一方法或一小部分方法，比不使用任何方法得到更大收益。但您只能在實(shí)現(xiàn)所有方法的情況下獲得最大收益，因?yàn)樗鼈兊牧α縼?lái)自它們之間的交互。
最初時(shí)按照書籍來(lái)執(zhí)行 XP，作為基準(zhǔn)。一旦理解了如何進(jìn)行交互，就擁有了將它們適應(yīng)于自身環(huán)境所需的知識(shí)。請(qǐng)記住，“進(jìn)行 XP”不是目的，而是到達(dá)終點(diǎn)的一種手段。目標(biāo)是快速地開(kāi)發(fā)高級(jí)軟件。如果您的過(guò)程有一些變異，已稱不上是在進(jìn)行 XP，但結(jié)果仍能讓您戰(zhàn)勝所有競(jìng)爭(zhēng)對(duì)手，您已經(jīng)成功了。
〈四〉為什么 XP 很重要
坦率地說(shuō)，XP（或者任何其它靈活方法）根本就不重要。它能夠產(chǎn)生的結(jié)果才是關(guān)鍵。如果如 XP 這樣的靈活方式可以幫助您更快地開(kāi)發(fā)更好的軟件而少受痛苦，那么它值得考慮。
還記得我們?cè)谶@篇文章開(kāi)始時(shí)提到的那些令人生畏的數(shù)字嗎？我們相信使用 XP 開(kāi)發(fā)面向?qū)ο筌浖梢杂袡C(jī)會(huì)將它們變得更好。目前我們的經(jīng)驗(yàn)已經(jīng)證實(shí)了這一信念。
〈五〉參考資料
在 RoleModel Software 的 XP Portal 中了解有關(guān) XP 的詳細(xì)信息。
可以在 Alistair Cockburn 和 Laurie Williams (XP2000 submission, 2000) 所著的 The Costs and Benefits of Pair Programming 中了解到有關(guān)成對(duì)編程所具有的經(jīng)濟(jì)方面的意義。
在 Pairprogramming.com 上可以知道成對(duì)編程的常規(guī)詳細(xì)信息。
下載 xUnit 測(cè)試工具。
如果您希望了解有關(guān) XP 的詳細(xì)信息，請(qǐng)務(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)單元和功能測(cè)試的文章 （developerWorks，2001 年 3 月）將 XP 哲學(xué)用在測(cè)試上。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.guhuozai8.cn/
本文標(biāo)題：采用XP方法使ERP軟件項(xiàng)目獲得更大成功
本文網(wǎng)址：http://www.guhuozai8.cn/html/consultation/1082025799.html
相關(guān)文章
