使用面向?qū)ο缶幊套兊每涨捌占啊Ｋ管浖_發(fā)發(fā)生了某種程度上的變革，但最近的研究表明，有半數(shù)的軟件開發(fā)項目滯后，而三分之一的項目則超出預(yù)算。問題不在于技術(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è)問題
如果使用標(biāo)準(zhǔn)軟件開發(fā)方法，那么即使在常用的平臺上進行開發(fā)，也要做好失望的準(zhǔn)備。如圖 1 所示，最近的研究表明，有一半項目將滯后，而三分之一的項目將超過預(yù)算。這一推測比 1979 年由美國總審計局的研究結(jié)果好不了多少。
圖 1. 軟件項目成功和失敗，過去和現(xiàn)在
如果我們希望這些數(shù)字有顯著提高，則需要徹底創(chuàng)新的方法來開發(fā)軟件。有兩個主要因素影響現(xiàn)有的方法： 懼怕失敗、對軟件本質(zhì)的誤解。
沒有人打算失敗。具有諷刺意味的是為使失敗最小化而創(chuàng)建的方法是失敗的。對軟件的誤解是問題的根源?？謶謱嶋H上只是一種癥狀?，F(xiàn)有的方法是由那些有良好愿望但忘記了軟件中的“軟”的那些聰明人所創(chuàng)建的。他們假定開發(fā)軟件就象造橋。因此他們從各種設(shè)計規(guī)范中借鑒了一些適用于“硬”物體（例如橋梁）的方法。結(jié)果是基于 Big Design Up-front (BDUF) 思想的反映遲鈍的開發(fā)方法，軟件不堪一擊，人們無法使用它們。
〈一〉一種解決方案：靈活方法
最近發(fā)生了一些轉(zhuǎn)變，從所謂的“重量型”方法轉(zhuǎn)向了“輕量型”或“靈活”方法，例如 Crystal 方法、適應(yīng)性軟件開發(fā)和（當(dāng)前最流行的）XP。所有這些過程都有這樣一個事實，即需要人們共同來開發(fā)軟件。成功的軟件過程必須將人們的長處化，將他們的缺點最小化，因為優(yōu)點和缺點毋庸質(zhì)疑都存在。在我們看來，XP 最出色的地方在于它能夠解決所有影響參加人員的互補力量。
XP 提供了十年來的一次機會，給軟件開發(fā)過程帶來徹底變革。就象 Peopleware 作家 Tom DeMarco 所說，“XP 是當(dāng)今我們所處領(lǐng)域中最重要的一項運動。預(yù)計它對于目前一代的重要性就象 SEI 及其能力成熟度模型對上一代的重要性一樣。”
XP 規(guī)定了一組核心價值和方法，可以讓軟件開發(fā)人員發(fā)揮他們的專長：編寫代碼。XP 消除了大多數(shù)重量型過程的不必要產(chǎn)物，通過減慢開發(fā)速度、耗費開發(fā)人員的精力（例如干特圖、狀態(tài)報告，以及多卷需求文檔）從目標(biāo)偏離。我們認識到一個稱為“極端編程”的東西可能很難作為正式的開發(fā)過程推薦給管理層，但如果您的公司從事軟件行業(yè)，您應(yīng)該幫助管理層繞過其名稱認識到 XP 可以提供的競爭優(yōu)勢。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價值（請參閱參考資料）。我們對它們進行了總結(jié)：
1）交流
項目的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流是不可能的事。
2）簡單
XP 建議您總是盡可能圍繞過程和編寫代碼做最簡單的事情。按照 Beck 的說法，“XP 就是打賭。它打賭今天做些簡單的事...而不是做更復(fù)雜但可能永遠也不會用到的事。”
3）反饋
更早和經(jīng)常來自客戶、團隊和實際最終用戶的具體反饋意見為您提供更多的機會來調(diào)整您的力量。反饋可以讓您把握住正確的方向，少走彎路。
4）勇氣
勇氣存在于其它三個價值的環(huán)境中。它們相互支持。需要勇氣來相信一路上具體反饋比預(yù)先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中其他人交流。需要勇氣來使系統(tǒng)盡可能簡單，將明天的決定推到明天做。而如果沒有簡單的系統(tǒng)、沒有不斷的交流來擴展知識、沒有掌握方向所依賴的反饋，勇氣也就失去了依靠。
XP 的方法將這些價值轉(zhuǎn)換成開發(fā)人員每天應(yīng)做的事情。這里沒什么新鮮內(nèi)容。多年以來，行業(yè)認識到 XP 方法是“方法”。實際上，XP 中的“極端”來自兩方面：
XP 采取經(jīng)過證明的業(yè)界方法并將其發(fā)揮到極致。
XP 將這些方法以某種方式進行結(jié)合，使它們產(chǎn)生的結(jié)果大于各部分的總和。
這是怎樣的情景呢？代碼復(fù)查是個好的做法，因此始終通過成對地編寫代碼來做到。測試也是個好的做法，因此總是通過在編寫代碼之前編寫測試來做到。文檔很少與代碼保持一致，因此只做那些最需要的事，余下的部分則取決于明確編寫的代碼和測試。XP 不保證人們總做正確的事，但它允許人們這樣做。它將這些“極端”方法以一種相互支持的方式結(jié)合起來，顯著提高了速度和有效性。
〈二〉XP 的十二種方法
XP 的十二種方法（如圖 2 所示）將其定義為規(guī)則。讓我們仔細研究每一個方法來對“執(zhí)行 XP”表示什么有個更全面的理解。
圖 2. XP 的十二種方法
1）規(guī)劃策略
有些人會指責(zé) 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ēng)險” 、迭代中素材開發(fā)的順序（先開發(fā)風(fēng)險的那一個可以減輕風(fēng)險）。
客戶需要決定： 范圍（一個發(fā)行版的素材和每一次迭代的素材） 、發(fā)行日期 、優(yōu)先級（根據(jù)企業(yè)價值先開發(fā)哪些特性）規(guī)劃經(jīng)常發(fā)生。這樣，在客戶或開發(fā)人員學(xué)習(xí)新事物的同時，就為他們調(diào)整計劃提供了頻繁機會。
在過去的十年中，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è)問題
如果使用標(biāo)準(zhǔn)軟件開發(fā)方法，那么即使在常用的平臺上進行開發(fā)，也要做好失望的準(zhǔn)備。如圖 1 所示，最近的研究表明，有一半項目將滯后，而三分之一的項目將超過預(yù)算。這一推測比 1979 年由美國總審計局的研究結(jié)果好不了多少。
圖 1. 軟件項目成功和失敗，過去和現(xiàn)在
如果我們希望這些數(shù)字有顯著提高，則需要徹底創(chuàng)新的方法來開發(fā)軟件。有兩個主要因素影響現(xiàn)有的方法： 懼怕失敗、對軟件本質(zhì)的誤解。
沒有人打算失敗。具有諷刺意味的是為使失敗最小化而創(chuàng)建的方法是失敗的。對軟件的誤解是問題的根源?？謶謱嶋H上只是一種癥狀?，F(xiàn)有的方法是由那些有良好愿望但忘記了軟件中的“軟”的那些聰明人所創(chuàng)建的。他們假定開發(fā)軟件就象造橋。因此他們從各種設(shè)計規(guī)范中借鑒了一些適用于“硬”物體（例如橋梁）的方法。結(jié)果是基于 Big Design Up-front (BDUF) 思想的反映遲鈍的開發(fā)方法，軟件不堪一擊，人們無法使用它們。
〈一〉一種解決方案：靈活方法
最近發(fā)生了一些轉(zhuǎn)變，從所謂的“重量型”方法轉(zhuǎn)向了“輕量型”或“靈活”方法，例如 Crystal 方法、適應(yīng)性軟件開發(fā)和（當(dāng)前最流行的）XP。所有這些過程都有這樣一個事實，即需要人們共同來開發(fā)軟件。成功的軟件過程必須將人們的長處化，將他們的缺點最小化，因為優(yōu)點和缺點毋庸質(zhì)疑都存在。在我們看來，XP 最出色的地方在于它能夠解決所有影響參加人員的互補力量。
XP 提供了十年來的一次機會，給軟件開發(fā)過程帶來徹底變革。就象 Peopleware 作家 Tom DeMarco 所說，“XP 是當(dāng)今我們所處領(lǐng)域中最重要的一項運動。預(yù)計它對于目前一代的重要性就象 SEI 及其能力成熟度模型對上一代的重要性一樣。”
XP 規(guī)定了一組核心價值和方法，可以讓軟件開發(fā)人員發(fā)揮他們的專長：編寫代碼。XP 消除了大多數(shù)重量型過程的不必要產(chǎn)物，通過減慢開發(fā)速度、耗費開發(fā)人員的精力（例如干特圖、狀態(tài)報告，以及多卷需求文檔）從目標(biāo)偏離。我們認識到一個稱為“極端編程”的東西可能很難作為正式的開發(fā)過程推薦給管理層，但如果您的公司從事軟件行業(yè)，您應(yīng)該幫助管理層繞過其名稱認識到 XP 可以提供的競爭優(yōu)勢。
Kent Beck 在他所著的 Extreme Programming Explained: Embrace Change 一書中概括了 XP 的核心價值（請參閱參考資料）。我們對它們進行了總結(jié)：
1）交流
項目的問題往往可以追溯到某人在某個時刻沒有和其他人一起商量某些重要問題上。使用 XP，不交流是不可能的事。
2）簡單
XP 建議您總是盡可能圍繞過程和編寫代碼做最簡單的事情。按照 Beck 的說法，“XP 就是打賭。它打賭今天做些簡單的事...而不是做更復(fù)雜但可能永遠也不會用到的事。”
3）反饋
更早和經(jīng)常來自客戶、團隊和實際最終用戶的具體反饋意見為您提供更多的機會來調(diào)整您的力量。反饋可以讓您把握住正確的方向，少走彎路。
4）勇氣
勇氣存在于其它三個價值的環(huán)境中。它們相互支持。需要勇氣來相信一路上具體反饋比預(yù)先知道每樣事物來得更好。需要勇氣來在可能暴露您的無知時與團隊中其他人交流。需要勇氣來使系統(tǒng)盡可能簡單，將明天的決定推到明天做。而如果沒有簡單的系統(tǒng)、沒有不斷的交流來擴展知識、沒有掌握方向所依賴的反饋，勇氣也就失去了依靠。
XP 的方法將這些價值轉(zhuǎn)換成開發(fā)人員每天應(yīng)做的事情。這里沒什么新鮮內(nèi)容。多年以來，行業(yè)認識到 XP 方法是“方法”。實際上，XP 中的“極端”來自兩方面：
XP 采取經(jīng)過證明的業(yè)界方法并將其發(fā)揮到極致。
XP 將這些方法以某種方式進行結(jié)合，使它們產(chǎn)生的結(jié)果大于各部分的總和。
這是怎樣的情景呢？代碼復(fù)查是個好的做法，因此始終通過成對地編寫代碼來做到。測試也是個好的做法，因此總是通過在編寫代碼之前編寫測試來做到。文檔很少與代碼保持一致，因此只做那些最需要的事，余下的部分則取決于明確編寫的代碼和測試。XP 不保證人們總做正確的事，但它允許人們這樣做。它將這些“極端”方法以一種相互支持的方式結(jié)合起來，顯著提高了速度和有效性。
〈二〉XP 的十二種方法
XP 的十二種方法（如圖 2 所示）將其定義為規(guī)則。讓我們仔細研究每一個方法來對“執(zhí)行 XP”表示什么有個更全面的理解。
圖 2. XP 的十二種方法
1）規(guī)劃策略
有些人會指責(zé) 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ēng)險” 、迭代中素材開發(fā)的順序（先開發(fā)風(fēng)險的那一個可以減輕風(fēng)險）。
客戶需要決定： 范圍（一個發(fā)行版的素材和每一次迭代的素材） 、發(fā)行日期 、優(yōu)先級（根據(jù)企業(yè)價值先開發(fā)哪些特性）規(guī)劃經(jīng)常發(fā)生。這樣，在客戶或開發(fā)人員學(xué)習(xí)新事物的同時，就為他們調(diào)整計劃提供了頻繁機會。