?http://www.360doc.com/content/12/0113/17/1369263_179197744.shtml

在將什么是極限編程之前，咱們先來討論一下，當今信息技術中最迫切的兩個問題是:
How do we deliver functionality to business clients quickly?
如何能快速地向商業用戶交付功能？

How do we keep up with near-continuous change?
如何才能跟上近乎連續的變化?
?? 變化本身也在不斷地變化中。不僅僅是變化的速度在不斷地提高 ，已經成為電子商務支柱的Internet, 就已使大范圍的行業產生劇變--更多的是打斷的平衡而不僅僅是一次劇變。當整個商業模式正在發生變化，當"時間意味著市場"正成為公司的咒語，當適應性與互連性正在成為甚至是最呆板的組織的需要的時候，我們將有必要檢查以下的每一個方面:
????1.商業是如何管理的，
?? 2.客戶為什么而感到高興，
?? 3.以及產品是如何開發的。

終極編程(Extreme Programming )運動成為面向對象編程這個團體的一部分已經有數年了， 但是直到最近才引起了越來越多的注意，特別是最近Kent Beck的《終極編程 釋義:擁抱變化》(Extreme Programming Explained: Embrace Change)一書的出版。

有一種趨勢，特別在那些嚴格的方法論者中，希望剔除那些與"能力 成熟度模型"(Capability Maturity Model CMM)或者是國際標準化組織的標準相比不那么笨重的方法，比如象hacking.注釋: hacking推崇行動而不是思考從而導致了較低的質量。 剔除與某人關于這個世界的假設相沖突的實踐，這倒不失為一種簡單的方法。
從另一個角度來看XP，它倒可能是一個難題的某個潛在的部分，這個一個我在過去18個月中一直都在寫的內容?；靵y 的時期產生新的問題，而后者又導致了新的實踐--新的實踐公然違抗 傳統的知識，但卻得以幸存下來是因為它們能更好地適應這個新的現實世界。至少有四種實踐方式我覺得是屬于這個范疇的:
XP
輕量級的開發(Lean development)
輕量級的Crystal方法(Crystal Light methods
自適應軟件開發(Adaptive software development)

我必須承認一件事情，就是我喜歡XP的原因應該是它沒有其他的那些花哨的東西。支持XP的人們總是會向你指出XP適合的地方以及他的某些局限性。而XP的實踐者Beck以及Ron Jeffties卻相信XP會有更廣泛的應用前景。他們通常對于自己的要求都是很謹慎的。例如：小的（小于10人），公司局部（他們有直接的經驗）兩者對于XP的適應性都是很明顯的；他們并沒有試圖讓人們相信XP可以適用于一個200人的團隊。


xp基礎---工程
最為著名的XP項目是克萊斯勒綜合補償系統（Chrysler Comprehensive Compensation system稱為C3工程）。
最初，C3是一個基于OO（面向對象技術）的開發項目，尤其是它采用Smaltalk語言進行開發。作為著名的Smalltalk專家，Beck被邀請來討論有關SmalTalk性能優化的問題，并且在原項目被認為不可救要的時候將其變為一個采用面向對象OO（XP）方法的試驗性項目。Beck并且帶來了Jeffries用于幫助那些基本的東西，Jeffries在C3組一直干到1999年的春天。最開始的需求是要做一個對約10，000個雇員每月薪水發放進行管理的系統。這個系統由大約2，000個類以及30，000個方法構成，并且在計劃方面提供有合理的容忍度 。當有人問Jeffries他怎樣成功的將C3變為XP并應用到其他的克萊斯勒IT項目。他笑著告訴了我。多年來我為許多大型IT組織開發了不少RAD系統（快速原型開發），因此我知道為什么我們無法將成功的經驗運用于其它項目中. 對于RAD, XP, 輕量級的開發以及其它一些未得到廣泛應用的方法, 它們成功的原因至少有一百條.

xp基礎---實踐
應記住的一件事情就是我們應傾向于在小型的, 局部的團隊中運用XP。除了代碼與測試用例外, 盡量減少有些的影響。XP的實踐既有正面的表現,也有負面的。在某些方面看來，他們聽起來就像一堆規則，要做這個，不要做那個。對此Beck解釋道, 與規則相比, XP更像是指導方針，一個靈活的依賴于具體環境的開發方針。但是諸如“每周工作40小時”等看起來可能會感覺絮絮叨叨。Jeffries使得實踐也會互相作用的，平衡，互相加強。以至于挑選使用的同丟棄的都是棘手的事情。

計劃的制定：XP中關于制定計劃的實現方法中可以反映出大多數迭代式RAD項目的特點。短期的，每三周為一個循環，頻繁地更新，按優先級劃分任務與技術， 分配stories（一個story定義了一個特殊的功能需求并以一種簡單的方式記錄在卡片上），所有的這些就是構成了XP中的計劃。

小版本：“每個版本應該盡可能的小，而且包含最有商業價值的需求”，Beck如是說。這也反映了Tom Gilb在他的<軟件工程管理原則>書中提到的關于漸進式發布的兩點：“所有的大的項目都可以被分為局部的, 有用的小的步驟”以及“進化的步驟會傳遞到下一級。”小型版本的發布意味著具有在大型項目中經常缺少的頻繁的反饋的實現.。 然而，一個開發小組當然需要考慮到“發布”同“可發布”的不同。無論是否是最終的版本發布還是一個簡單的可發行版本的發布, 都需要付出安裝，培訓，轉化等代價。

隱喻：在XP中“隱喻”以及“story”的使用可能會讓人有一點不舒服。但是，這些術語的使用可以幫助我們以一種更人性化的方式加以理解，尤其是對客戶而言。從某種程度上來說，隱喻同體系結構是同意語――他們都著重于從全局描述一個項目。但是體系結構經常會陷于符號與連接的泥潭。而XP使用“隱喻”定義一個從開發者到商業客戶都可聯系的全面一致的主題。隱喻用于描述項目全面的面貌，而Story用于描述個別具體的特征。

簡單的設計：簡單的設計包含兩個部分。一，為已定義的功能進行設計，而不是為潛在地未來可能的功能進行設計。二，創建最佳的可以實現功能的設計。換句話說，不用管未來會是怎樣，只創建一個目前為止可以實現的最好的設計?！叭绻阆嘈盼磥硎遣淮_定的，并且你相信你可以很方便的改變你的主意的話，那么對未來功能的考慮是危險的。”Beck寫到?！爸挥性谀阏嬲枰臅r候才去做“。 數據的質量是使用功能，不是捕捉與存儲。此外，我說數據如果不是很系統的使用便會變壞。數據質量是系統使用的功能，不是可預料的設計。無論預期的對還是錯，試著設計一個我們從來都不會用到的數據，最終結果很可能我們一次也不會用到它們。XP的簡單設計方法反映了相同的觀點。如在本文后來所描述的那樣，這并不意味著不需要預測，而是說為預測的內容所做的設計一旦發生變化，其導致的代價是十分巨大的。


重構：如果我不得不找出一個能夠將XP和其他方法區別開來的東西那就是重構――不斷的軟件再設計以改進它對于變化的反應。RAD方法常常很少甚至根本不與設計相關；XP應當被看作持續設計。當變化既快而且頻繁的時候，應投入更多的精力于重構之上。參見下面的“重構”和“數據重構”部分。


測試：XP充滿發人深思的有趣的難題。例如：什么是“先測試后編碼”？在一些軟件公司是通過代碼的行數來對程序員的績效加以考核，而測試的績效則是通過發現的缺陷的數量來考核的。這兩種方法都不能鼓勵減少測試前產生的缺陷的數量。XP使用兩種測試：單元測試和功能測試。單元測試要求在寫代碼之前就開發出相應功能的測試方法，并且測試應當是自動化的。代碼一完成，它就被立即用有關測試集加以測試，從而能立即得到反饋。

配對編程：代碼檢查（還是直接用Inspection為好？）（也稱審查或走查）也是被廣為接受（至少在理論上）和有效度量的少數軟件工程實踐之一。在最好情況下，Inspection這種協同交互的檢查能夠加速學習，同時發現缺陷。一個較少被知道的關于Inspection的統計數據是盡管它在發現缺陷方面非常有效，但通過團隊對于好的開發實踐持續的學習和協作，可以更好的在第一時間預防缺陷。 一家軟件公司客戶引用一個內部研究結果，表明在測試階段發現一個缺陷需15小時，在Inspection階段發現一個缺陷則需2－3小時，而在Inspection之前發現缺陷只需15分鐘。后面的數據來自于產生于常規審查的持續的團隊學習。配對編程將這個帶入下一步――與其用Inspection來遞增式學習，為什么不用配對編程來學習呢？ “配對編程是兩個人試圖同時編程和理解如何更好編程的一種對話”，Beck寫道。讓兩個人同時坐在一臺終端前面（一個人敲代碼或測試用例，一個人審查和思考）產生一種持續的、動態的交流。Williams在猶他大學進行的博士論文研究證明了配對編程不僅僅是一種美好的想法而且確有實效。


代碼共享：項目組中的每個人都可以在任何時候修改其他項目成員的代碼，這就是XP中所定義的代碼共享。。對許多程序員以及經理而言，，共有代碼的想法會引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現問題我應該怪誰？"等等。共享代碼從另一個層面提供了對配對編程中協作的支持。

經常集成：每日構造（build）在許多公司已經成為規范，許多公司將每日編鏈作為最小要求，XP實踐者將每日集成作為最大要求，選擇每兩個小時一次的頻繁編鏈。XP的反饋周期迅速：開發測試集、編碼、集成（編鏈）和測試。 對于集成缺陷危險的認識已有多年了，但我們并不是總能擁有相應工具和時間將這些知識好好用起來。XP不僅提醒我們有可能有嚴重的集成錯誤，而且從實踐與工具的角度提供了一種新的認識。


每周只干40小時：XP有12條實踐的基本原則，但是有時候，比如象每周只干40小時的原則，聽起來更象規則。我同意XP中的觀點。只是不認為有必要硬性規定工作小時數。相比起來，我更喜歡一句類似于“不要把部隊燒光”的話。在一些情況下，工作40小時太勞累，而在另外一些組里，甚至需要一周60個工作時。 Jeffries提供了關于加班的更多思索："我們說的是加班被定義為我們不想在辦公室的時候呆在辦公室。而且你不應當加班超過一周。如果你超過了，就有什么東西出了問題――你過于勞累，有可能比你按時下班干的還差。我同意你關于60工作時一周的感受。在我們年輕和滿身干勁的時候，這也許沒問題。值得注意的是拖沓的一周又一周。" 我不認為一周的工作時間會造成大的差別。決定區別的是自愿的貢獻。人們愿意來工作嗎？他們對每一天都充滿干勁嗎？人們必須來工作，但是他們通過投入項目來創造巨大成就，而投入僅僅產生于目標感。

現場客戶：這就對應到了最初軟件開發時所提出的問題――用戶參與。XP，同其他的快速開發一樣，要求客戶在現場持續地參與到項目組中。


編碼標準：XP實踐相互支持。例如，如果你進行配對編程并讓他人修改共有代碼，那么編碼標準看起來就是必須的。


價值和規則
在2000年一月一日周六時候，華爾街日報（周一到周五出版的）用一個58頁的版面發布了一個千僖年紀念版。在篇首的有關工業及金融的介紹里標著Tom Petzinger.寫的：“長久的需求與召喚：經濟新的增長點――顯得同以往不同”。底下的一行 Petzinger 寫著：“創造性正代替‘萬金藥’的資本在成為首要的因素”。 Petzinger并沒有談論少數天才的創造性，而是談了以下群體的創造性――從組到部門。一旦我們撇下天才們的個體創造，創造性就是環境的功能，而人們運用并互相協助而達到我們的結果的能力。如果你的公司認為軟件開發只是一個統計上的重復試驗，刻板的，技術性的過程，那么XP對于您也許并不合適。雖然XP中也有技術實踐里的嚴格，但是XP本身是追求"創造"與"溝通"。

環境是靠價值同規則共同驅動的系統。XP（或者其他類似的）可能、也可能不適合您的單位，可是，應該澄清的是成功并不是只靠每周40小時的瘋狂工作或者配對編程，也不是依靠XP之中應用在您單位中的價值或者是規則。 Beck指出了四個價值，五個基本規則，以及十個輔助規則--不過我要提到是這五個規則。

溝通：是的，溝通，可是，這里似乎沒有新的東西在里面？溝通主要是看人們自己的看法，XP構建的基本是人與人，通過最簡潔的文檔，最直接的面對面溝通獲得對任務環境的理解。


簡潔：XP問每個開發組成員：“可能實現的最簡潔的方法是什么？”。今天所保持的簡潔，可以降低明天由于變更所帶來的費用

反饋：Beck說："對于編程而言，樂觀主義是一種冒險。"，"而反饋則是相應的解決良藥。"無論是用反復的構建或者頻繁的用戶功能測試，XP都能不斷地接收到反饋。雖然每次對軟件開發策略進行研討時，我們都會說及反饋--即使是非常有害的瀑布模型--不同的是XP的實踐者認為反饋比起前饋(feedforward)來更為重要。無論是對測試失敗的代碼進行修改或者是對用戶拒收的軟件從新返工，開發環境的快速變化要求開發人員對反饋有更好的認識。

勇氣：無論您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇氣的。許多地方將勇氣定義為做某件事情的權利，即使被迫去做其他的事情。開發人員經常借口壓力而發出帶有許多缺陷的產品，并對此加以堅持。然而，更進一步的應該包括其他的正確的不同的東西進來。通常，人們并不是缺少勇氣，而是缺少一種讓正確實踐獲得承認的理由，而且，也不堅信這點，勇氣不像看起來那么重要。而如果你對之沒有信心，那么是很難盡力工作的。 "勇氣并不只是方法"，Jeffries說道，它是一種最終的價值。如果你在一種基于"溝通"，"簡潔"，"反饋"的模式下工作，你將獲得勇氣，越往前信賴就越不重要。

優質的工作：好，如果你們中有贊成劣質工作的話，那么請舉手離開這兒吧。不論你是一個Rational Unified Process，CMM，或是XP的贊成者，其本質的觀點"你怎樣定義質量"與"什么樣的活動會贏得高質量"，定義"無缺點"質量是這個問題的一個方向。Jerry Weinberg的定義是"質量是對多數人有益"

總結

以上是生活随笔為你收集整理的极限编程XP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。