極限編程(eXtreme Programming)是一種開發紀律，以簡單性、交流、反饋和勇氣為基本宗旨。它的做法是以有效的實踐規則將整個團隊緊密聯系起來，通過充分的反饋使團隊能隨時知道自己目前的狀況和恰當的調節規則以適應自己的特殊情況。
在極限編程中，每一個項目貢獻者都是“團隊”完整的一部分。這個隊伍是圍繞著一個每天和隊伍坐在一起共同工作的商業代表——“客戶”建立起來的。
核心實踐：整體團隊
極限編程的隊伍采用一種簡單的方式來進行規劃和跟蹤，以決定下一步要做什么和預知項目什么時候會完成。聚焦于商業價值，團隊通過一系列的通過了客戶定義的測試和完全集成的小的發布來創作軟件系統。
核心實踐：規劃策略，小發行版，客戶測試
極限編程者通過成對和小組的方式共同工作，通過簡單設計和強制測試的代碼，不斷的提升設計以保證設計總是適合當前的需求。
核心實踐：簡單設計，成對編程，測試優先開發，設計改進
極限編程隊伍會總是保持系統能夠集成并且在所有的時間運行。程序員以成對的方式編寫所有的產品代碼，并且在所有時間內都共同工作。他們以相似的形式編碼以保證所有成員都可以按需要理解和改進所有的代碼。
核心實踐：持續集成，集體代碼所有權，編碼標準
極限編程隊伍分享一個公共并且簡單的系統藍圖。所有成員可以按照一種不時保持同步的節奏進行工作。
核心實踐：系統比喻，可接受的步伐
核心實踐
團隊整體
一個XP項目的所有參與者都作為一個團隊的成員坐在一起。這個團隊必須包括一個業務的代表——“客戶”，他提供需求，設置優先度，并掌管整個項目的方向。最好這個客戶或者他的助手是一個最終用戶，了解該領域，知道什么是所需要的。團隊當然還要有程序員。團隊可能會包含測試員，他幫助客戶定義客戶驗收測試。分析員可以作為客戶的助手，幫助客戶定義需求。通常還會有一個指導,他幫助整個團隊跟蹤、推動開發進程。也可能會有一個管理者，他提供資源、處理對外交流和分工協作。這些職責中沒有任何一個是必須某個個人獨有的：每一個XP團隊的成員都以任何他們所能做到的方式參與，最好的團隊沒有專家，只有一些有著特殊的技能的一般的參與者。
規劃策略
XP的計劃解決軟件開發中的兩個關鍵問題：預知在責任期內哪些東西將被完成，并且確定下一步需要做什么。重點是把握項目的正確軌道——這是相當簡單明了的——更勝于希望精確預知哪些東西將會需要以及可能花費多少時間——這是相當困難的。在XP這里有兩個關鍵的規劃步驟，用來解決這兩個問題：
發布計劃是一個實踐讓客戶向程序員們演示所希望獲得的特性，然后程序員們評估它們的難度。當手中有了代價的評估和這些特性的重要程序的認知之后，客戶安排一個項目計劃。最初的發布計劃需要留有足夠的余地：優先級以及評估都不是真實可靠的，并且知道團隊開始工作以前，我們都無法確切地了解隊伍的開發進度。甚至最初的發布計劃也不是足夠精確能進行決斷，所以XP隊伍通常會不時地校正發布計劃。
迭代計劃是一個實踐籍此可以為團隊提供每幾個開發周的導向。XP隊伍通過兩周的“迭代”來建立軟件系統，在每一個迭代結束時提供可以運行的有實際用途的軟件系統。在進行迭代計劃時，客戶演示下兩周內希望完成的特性。程序員們將它們分割成若干個任務，并且評估它們的成本（比發布計劃要細致一些）。基于在之前的迭代中完成的工作，團隊簽定當前迭代中將要承擔的工作。
這些計劃十分的簡單，然而他們為客戶提供了非常好的信息和極好的操縱控制。每隔幾周，多少進展都可以一目了然。在XP中沒有“百分之九十完成”：一個特性故事要么完成了，要么沒有完成。關注可視結果方法在于一個很好的小的對立論點：一方面來說，非常直觀地，如果進度不能令人滿意，客戶可以在某一個位置取消項目。從另一方面說，進度是顯而易見地，并且判斷哪些東西將會完成的能力是很完善的，因此XP項目往往可以在較少的壓力下完成更多的需要的東西。
客戶測試
作為每一個所要求特性的演示的一部分，XP客戶定義一個或者多個自動進行的接受測試來表明特性已經能夠實現。團隊實現這些測試并且用它們來向自己和客戶證明特性已經被正確的實現了。由于時間的壓力，自動化是很重要的，手工測試將被跳過。這就像當黑夜來臨的時候，就可以關掉你的燈一樣。
最好的XP團隊會將他們的客戶測試當作程序員的測試一樣對待：一旦測試運行了，從此之后團隊會保持它能夠一直正確運行。這意味著系統只能夠被改進，總是向前的，從不會倒退。
小發行版本
XP團隊通過兩個重要的方式實踐小發行版本：
第一，團隊在每一個迭代發布可以運行的，測試過的軟件系統，提供客戶選擇的商業價值。客戶可以為任何目的使用這個軟件系統，無論是評估還是發布給最終用戶（強烈推薦）。最重要的方式是在每一個迭代結束的時候軟件系統是可見的，并且提交給了客戶。這保證了任何事情都是公開和真實的。
第二，XP團隊盡可能頻繁地發布給他們的最終用戶。XP網站項目每天都進行發布，居家項目則每月或者更頻繁地發布。甚至可以簡包裝的產品可以每季度地發運。
這么頻繁地創建好的版本也許顯得不太可能，但是XP團隊每時每刻都在進行著發布。更多信息可以參看持續集成，并請注意這些頻繁的發布通過XP中隨處可見的測試（如同客戶測試和測試優先開發中所描述的）變得現實了。
簡單設計
XP團隊建構軟件系統為一個簡單的設計。他們從簡單開始，并且在整個程序員測試和設計改進過程中，他們保持著簡單的設計。一個XP團隊保持著設計總是剛好適合系統當前的功能要求。這里沒有多余的投入，并且軟件系統總是為將來做好了準備。
在XP中設計并不是一次性完成的事情，也不是一件從上到下的事情，它是自始至終的事情。在發布計劃和迭代計劃中都有設計的步驟，在快速設計過程中集合了團隊的能力并且在整個項目過程地構中改進設計。在類似于極端編程這樣的遞增和迭代過程中，良好的設計是本質。這是在整個開發過程中必須更多的關注設計的原因。
成對編程
在XP所有的產品軟件都是由兩個程序員并排坐在一起，在同一臺機器上共同完成的。這個實踐保證了所有的產品代碼都至少有一個其它的程序員進行了審視，而結果是更好的設計，更好的測試和更好的代碼。
讓兩個程序員去做“一個程序員的工作”看起來有些效率低下，但是實際上剛好相反。研究表明成對編程在讓程序員們單獨工作相同的時間內會得到更好的代碼。這證明了：兩個頭腦加在一起比一個好得多！
很多程序員在還沒有嘗試過的情況下就反對成對編程。這確實需要一些實踐來做好它，而且你需要認真地實踐數周以上的時間來看到結果。百分之九十的學習過成對編程的程序員都會喜歡這樣，因此我們向所有的團隊強烈推薦它。
除開提供更好的代碼和測試之外，成隊也提供了知識在團隊中間傳遞。當成對地程序員交換伙伴時，每個人都會從其它的某個人那里學到新的知識。程序員們在學習，他們的技術在提高，他們對團隊和公司來講變得更有價值。成對，即使它本身在XP過程之外實施，也是每個人的巨大成功。
測試優先開發
極端編程圍繞著反饋，而在軟件開發中，好的反饋需要好的測試。最優秀的XP團隊實踐“測試優先開發”，在一個很小的循環中增加一個測試，然后讓它能夠工作。幾乎是輕而易舉的，團隊提供的代碼接近100%都有測試程序覆蓋著，在絕大多數情況下這是很重要的進步。（如果你的程序員已經提供了更多的現有測試程序，你會擁有更多的力量。將它們保存下來，他們只會提供幫助的！）
僅僅寫了測試程序還是不夠的：你必須要運行它們。這里，極限編程也是極限的。這些“程序員測試”，或者說“單元測試”是一個完整的集合，每當程序員們發布任何代碼到代碼庫的時候（成對的程序員通常每天發布兩次或者更多次），每一個程序員測試必須能夠正確的運行。每時每刻都是百分之百運行！這意味著程序員們可以立刻得到有關他們做得究竟如何的反饋。進一步說，這些測試提供了軟件設計改進時無價的支持。
設計改進
極限編程在每一個迭代都關注于提供商業價值。為了在整個項目過程中完成這個目標，軟件系統必須有良好的設計。可選擇性可能會降低并且最終停滯。因此XP采用一種持續改進設計的過程，稱為“重構”，來自于Martin Fowler 的書名，“重構：改進現有代碼的設計”。
重構的過程關注在去掉重復（一個低劣設計的明確標志），以及提高代碼的“內聚”，還有減少“耦合”。高內聚和低耦合在最近三十年以來被公認為是良好設計的特點。結果就是XP團隊從一個好的簡單的設計出發，并且總是讓軟件系統有一個好的簡單的設計。這讓他們能保持他們的開發速度，并且通常在實際上提高了項目開發速度。
重構自然是通過全面的測試來提供有力的支持的，這些測試用來確認當設計改變的時候不會破壞系統中的任何東西。因此客戶測試和程序員測試都是有效的評價因素。XP的實踐是相互支持的：他們會比各自獨立時更為強壯。
持續集成
極限編程隊伍總是保持的系統完全地集成在一起。我們說每日建構版本是為弱者提供的：XP團隊每天都要構建系統很多次。（一個40人的XP團隊每天至少集成八到十次！）
這個實踐的好處可以通過回想你可能聽說過的（或者是親身參與過的）項目來了解：當系統構建是每周或以更低的頻率進行時，通常會陷入“集成的地獄”，在那里所有東西都不能運行而且沒有人知道為什么。
極少進行集成會給軟件項目帶來一系列的問題。第一個，盡管集成是發行好的工作代碼的條件， 但是團隊并不去實踐它，而且通常它被委派給那些對整個系統并不十分了解的人。第二，極少集成的代碼通常是——我寧愿說總是——錯漏百出。
集體代碼所有權
在一個極限編程項目中，每一對程序員都可以在任何時候改進任何一處的代碼。這意味著所有的代碼在很多人的關注下獲得更多的收益，這樣就提升了代碼質量并且減少了缺陷。這里還有另外一個重要的好處：當代碼僅由單個人負責的時候，要求的特性往往會放到了錯誤的位置，因為一個程序員發現他需要一個特性但是那段代碼卻不歸他管理。代碼的所有者太忙樂而不能去增加這個特性，所以這個程序員只好把這個特性加進了這個特性本不應該存在的他自己的代碼中。這導致了難看的，難于維護到代碼，充斥著重復和低（差）的內聚。
如果有人在他們所不理解的代碼上進行盲目的修改時，集體代碼所有權可能帶來問題。XP通過兩種關鍵技術來避免這類的問題：通過程序員測試來捕獲錯誤，成對編程則表明在不熟悉的代碼上工作的時候最佳途徑是找一個這方面的專家作為伙伴。為了確保在需要是進行好的修改，這種實踐將知識延伸到了整個團隊。
編碼標準
XP團隊遵循一個公共的編碼標準，因此系統中所有的代碼看上去都像出自單獨一個——非常有能力的——人之手。這個標準的規定并不重要：重要的是要讓所有的代碼看上去很相似，用來支持集體代碼所有權。
系統比喻
極限編程團隊對于程序如何運作形成一個共識，我們稱之為“系統比喻”。在最佳狀態時，系統比喻是關于程序如何運作的一個簡單的靈魂描述，例如用“這個程序工作時就像一箱子蜜蜂，外出尋找花粉并帶回蜂箱”作為一個基于代理的信息查詢系統的描述。
有些時候一個十分詩意的想象可能不會出現。在任何情況下，無論有沒有生動的比喻，XP團隊都會選用一個公共的命名系統來確保每個人都能理解系統是如何工作的，以及到哪里去找到你所需要的功能，或者找到你要增加功能的正確位置。
可接受的步伐
極限編程團隊都會在這里很長的一段時間。他們努力的工作，并且在一個能夠不斷維持的步伐下。這意味著在有效的時候他們會加班工作，而且他們經常這樣工作來保證每周都有最大的生產力。這恰當的解釋了死亡競賽式的項目既不會有生產力也不會創造有質量的軟件系統。XP團隊在這里是要勝利而不是要死亡。
posted on 2008-04-12 22:24
Macaulish 閱讀(683)
評論(0) 編輯 收藏 引用