標籤: 暫無標籤

極限編程(ExtremeProgramming,簡稱XP)是由KentBeck在1996年提出的。KentBeck在九十年代初期與WardCunningham共事時,就一直共同探索著新的軟體開發方法,希望能使軟體開發更加簡單而有效。Kent仔細地觀察和分析了各種簡化軟體開發的前提條件、可能性以及面臨的困難。1996年三月,Kent終於在為DaimlerChrysler所做的一個項目中引入了新的軟體開發觀念——XP。

1概述

極限編程是一個輕量級的、靈巧的軟體開發方法;同時它也是一個非常嚴謹和周密的方法。它的基礎和價值觀是交流、樸素、反饋和勇氣;即,任何一個軟體項目都可以從四個方面入手進行改善:加強交流;從簡單做起;尋求反饋;勇於實事求是。XP是一種近螺旋式的開發方法,它將複雜的開發過程分解為一個個相對比較簡單的小周期;通過積極的交流、反饋以及其它一系列的方法,開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等,並根據實際情況及時地調整開發過程。

2相關概念

客戶的權利和義務
定義每個用戶需求的商業優先順序;
制訂總體計劃,包括用多少投資、經過多長時間、達到什麼目的;
在項目開發過程中的每個工作周,都能讓投資獲得最大的收益;
通過重複運行你所指定的功能測試,準確地掌握項目進展情況;
能隨時改變需求、功能或優先順序,同時避免昂貴的再投資;能夠根據各種變化及時調整項目計劃;
能夠隨時取消項目;項目取消時,以前的開發工作不是一堆垃圾,已開發完的功能是合乎要求的,正在進行或未完成的的工作則應該是不難接手的。
其他問題
靈巧的輕量級軟體開發方法
一套軟體開發方法是由一系列與開發相關的規則、規範和慣例。重量級的開發方法嚴格定義了許多的規則、流程和相關的文檔工作。靈巧的輕量級開發方法,其規則和文檔相對較少,流程更加靈活,實施起來相對較容易。
在軟體工程概念出現以前,程序員們按照自己喜歡的方式開發軟體。程序的質量很難控制,調試程序很繁瑣,程序員之間也很難讀懂對方寫的代碼。1968年,Edsger Dijkstra給CACM寫了一封題為GOTO Statement Considered Harmful的信,軟體工程的概念由此誕生。程序員們開始摒棄以前的做法,轉而使用更系統、更嚴格的開發方法。為了使控制軟體開發和控制其它產品生產一樣嚴格,人們陸續制定了很多規則和做法,發明了很多軟體工程方法,軟體質量開始得到大幅度提高。隨著遇到的問題更多,規則和流程也越來越精細和複雜。
到了今天,在實際開發過程中,很多規則已經難於遵循,很多流程複雜而難於理解,很多項目中文檔的製作過程正在失去控制。人們試圖提出更全面更好的一攬子方案,或者寄希望於更複雜的、功能更強大的輔助開發工具(CaseTools),但總是不能成功,而且開發規範和流程變得越來越複雜和難以實施。
為了趕進度,程序員們經常跳過一些指定的流程,很少人能全面遵循那些重量級開發方法。
失敗的原因很簡單,這個世界沒有萬能葯。因此,一些人提出,將重量級開發方法中的規則和流程進行刪減、重整和優化,這樣就產生了很多適應不同需要的輕量級流程。在這些流程中,合乎實際需要的規則被保留下來,不必要的複雜化開發的規則被拋棄。而且,和傳統的開發方法相比,輕量級流程不再象流水生產線,而是更加靈活。
ExtremeProgramming(XP)就是這樣一種靈巧的輕量級軟體開發方法。
為什麼稱為「Extreme」(極限)
「Extreme」(極限)是指,對比傳統的項目開發方式,XP強調把它列出的每個方法和思想做到極限、做到最好;其它XP所不提倡的,則一概忽略(如開發前期的整體設計等)。一個嚴格實施XP的項目,其開發過程應該是平穩的、高效的和快速的,能夠做到一周40小時工作制而不拖延項目進度。

3核心價值

極限編程中有四個核心價值是我們在開發中必須注意的:溝通(Communication)、簡單(Simplicity)、反饋(Feedback)、勇氣(Courage)、此外還擴展了第五個價值觀:謙遜(Modesty)。  XP用「溝通、簡單、反饋、勇氣和謙遜」來減輕開發壓力和包袱;無論是術語命名、專著敘述內容和方式、過程要求,都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐,在一定範圍內成功地打破了軟體工程「必須重量」才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵,是用「溝通、簡單、反饋、勇氣和謙遜」的態度來對待XP;輕鬆愉快地來感受XP的實踐思想;自己認真實踐后,通過對真實反饋的分析,來決定XP對自己的價值;有勇氣接受它,或改進它。

4開發

需求
客戶應該是項目開發隊伍中的一員,而不是和開發人員分開的;因為從項目的計劃到最後驗收,客戶一直起著很重要的作用。開發人員和客戶一起,把各種需求變成一個個小的需求模塊(UserStory),例如「計算年級的總人數,就是把該年級所有班的人數累加。」;這些模塊又會根據實際情況被組合在一起或者被分解成更小的模塊;它們都被記錄在一些小卡片(StoryCard)上,之後分別被程序員們在各個小的周期開發中(Iteration,通常不超過3個星期)實現;客戶根據每個模塊的商業價值來指定它們的優先順序;開發人員要做的是確定每個需求模塊的開發風險,風險高的(通常是因為缺乏類似的經驗)需求模塊將被優先研究、探索和開發;經過開發人員和客戶分別從不同的角度評估每個模塊后,它們被安排在不同的開發周期里,客戶將得到一個儘可能準確的開發計劃;客戶為每個需求模塊指定驗收測試(功能測試)。
每發布一次開發的軟體(經過一個開發周期),用戶都能得到一個可以開始使用的系統,這個系統全面實現了相應的計劃中的所有需求。而在一些傳統的開發模式中,無論什麼功能,用戶都要等到所有開發完成後才能開始使用。
編程
既然編程很重要,XP就提倡兩個人一起寫同一段程序(PairProgramming),而且代碼所有權是歸於整個開發隊伍(CollectiveCodeOwnership)。程序員在寫程序和重整優化程序的時候,都要嚴格遵守編程規範。任何人都可以修改其他人寫的程序,修改後要確定新程序能通過單元測試。結對編程的好處是,一個人編寫代碼時另一個人在思考。思考者的頭腦中保持總體概念,不僅手頭問題的這一段,而且還有XP指導方針。例如,如果兩個人都在工作,就不太可能會有其中一個說「我不想首先寫測試」而離開。如果編碼者遇到障礙,他們就交換位置。如果兩個人都遇到障礙,他們的討論可能被在這個區域工作的其他人聽到,可能給出幫助。這種結對方式,使事情順暢、有章可循。也許更重要的是,他能使程序設計更具有社交性和娛樂性。
項目開發小組
在XP中,每個對項目做貢獻的人都應該是項目開發小組中的一員。而且,這個小組中必須至少有一個人對用戶需求非常清晰,能夠提出需求、決定各個需求的商業價值(優先順序)、根據需求等的變化調整項目計劃等。這個人扮演的是「客戶」這個角色,當然最好就是實際的最終用戶,因為整個項目就是圍繞最終用戶的需求而展開的。程序員是項目開發小組中必不可少的成員。小組中可以有測試員,他們幫助客戶制訂驗收測試;有分析員,幫助客戶確定需求;通常還有個Coach(教練),負責跟蹤開發進度、解決開發中遇到的一些問題、推動項目進行;還可以又一個項目經理,負責調配資源、協助項目內外的交流溝通等等。項目小組中有這麼多角色,但並不是說,每個人做的工作是別人不能插手或干預的,XP鼓勵每個人儘可能地為項目多做貢獻。平等相處,取長補短;這就是最好的XP開發小組。
重構
XP強調簡單的設計,但簡單的設計並不是沒有設計的流水賬式的程序,也不是沒有結構、缺乏重用性的程序設計。開發人員雖然對每個USERSTORY都進行簡單設計,但同時也在不斷地對設計進行改進,這個過程叫設計的重構(Refactoring)。這個名字最早出現在MartinFowler寫的《Refactoring:ImprovingtheDesignofExistingCode》這本書中。
Refactoring主要是努力減少程序和設計中重複出現的部分,增強程序和設計的可重用性。Refactoring的概念並不是XP首創的,它已經被提出了近30年了,而且一直被認為是高質量的代碼的特點之一。但XP強調,把Refactoring做到極致,應該隨時隨地、儘可能地進行Refactoring,只要有可能,程序員都不應該心疼以前寫的程序,而要毫不留情地改進程序。當然,每次改動后,程序員都應該運行測試程序,保證新系統仍然符合預定的要求。
XP開發小組經常整合不同的模塊。為了提高軟體質量,除了測試驅動開發和PairProgramming以外,XP要求每個人的代碼都要遵守編程規範,任何人都可以修改其他人寫的代碼,而且所有人都應該主動檢查其他人寫的代碼。
集體擁有代碼
在很多項目開發過程中,開發人員只維護自己的代碼,而且很多人不喜歡其他人隨意修改自己的代碼。因此,即使可能有相應的比較詳細的開發文檔,但一個程序員卻很少、也不太願意去讀其他程序員的代碼;而且,因為不清楚其他人的程序到底實現了什麼功能,一個程序員一般也不敢隨便改動其他人的代碼。同時,因為是自己維護自己的代碼,可能因為時間緊張或技術水平的局限性,某些問題一直不能被發現或得到比較好的解決。針對這點,XP提倡大家共同擁有代碼,每個人都有權利和義務閱讀其他代碼,發現和糾正錯誤,重整和優化代碼。這樣,這些代碼就不僅僅是一兩個人寫的,而是由整個項目開發隊伍共同完成的,錯誤會減少很多,重用性會儘可能地得到提高,代碼質量是非常好。
為了防止修改其他人的代碼而引起系統崩潰,每個人在修改後都應該運行測試程序。(從這點,我們可以再次看到,XP的各個慣例和規則是怎樣有機地結合在一起的。)

5編程規範

XP開發小組中的所有人都遵循一個統一的編程標準,因此,所有的代碼看起來好像是一個人寫的。因為有了統一的編程規範,每個程序員更加容易讀懂其他人寫的代碼,這是是實現CollectiveCodeOwnership的重要前提之一。
5Metaphor(系統比喻),不加班
XP過程通過使用一些形象的比喻讓所有人對系統有個共同的、簡潔的認識。XP認為加班是不正常的,因為這說明關於項目進度的估計和安排有問題。
Metaphor(系統比喻)
為了幫助每個人一致清楚地理解要完成的客戶需求、要開發的系統功能,XP開發小組用很多形象的比喻來描述系統或功能模塊是怎樣工作的。比如,對於一個搜索引擎,它的Metaphor可能就是「一大群蜘蛛,在網上四處尋找要捕捉的東西,然後把東西帶回巢穴。」

6其他相關

大量的加班意味著原來的計劃是不準確的,或者是程序員不清楚自己到底什麼時候能完成什麼工作。而且,開發管理人員和客戶也因此無法準確掌握開發速度;開發人員也因此非常疲勞。XP認為,如果出現大量的加班現象,開發管理人員(比如Coach)應該和客戶一起確定加班的原因,並及時調整項目計劃、進度和資源。
XP中一些基本概念的簡介
UserStory:開發人員要求客戶把所有的需求寫成一個個獨立的小故事,每個只需要幾天時間就可以完成。開發過程中,客戶可以隨時提出新的UserStory,或者更改以前的UserStory。
StoryEstimates和開發速度:開發小組對每個UserStory進行估算,並根據每個開發周期(Iteration)中的實際情況反覆計算開發速度。這樣,開發人員和客戶能知道每個星期到底能開發多少UserStory。
ReleasePlan和ReleaseScope:整個開發過程中,開發人員將不斷地發布新版本。開發人員和客戶一起確定每個發布所包含的UserStory。
Iteration(開發周期,或稱迭代)和IterationPlan:在一個Release過程中,開發人員要求客戶選擇最有價值的UserStory作為未來一兩個星期的開發內容。
TheSeed:第一個迭代(Iteration)完成後,提交給客戶的系統。雖然這不是最終的產品,但它已經實現了幾個客戶認為是最重要的Story,開發人員將逐步在其基礎上增加新的模塊。
ContinuousIntegration(整合):把開發完的UserStory的模塊一個個拼裝起來,一步步接近乃至最終完成最終產品。
驗收測試(功能測試):對於每個UserStory,客戶將定義一些測試案例,開發人員將使運行這些測試案例的過程自動化。
UnitTest(單元測試):在開始寫程序前,程序員針對大部分類的方法,先寫出相應的測試程序。
Refactoring(重構):去掉代碼中的冗餘部分,增加代碼的可重用性和伸縮性。

7影響

通過軟體工程設計的簡單而優美的軟體並不比那些設計複雜而難以維護的軟體有價值。這是真的嗎?XP認為事實並非如此。 一個典型的項目花在人力上的金錢是花在硬體上的時間的20 倍,這意味著一個項目每年要花200 萬美元在程序員身上,而僅僅花10 萬美元在電腦設備上。很多聰明的程序員說:「我們如此聰明,發現一種方法可以節省20%的硬體開銷」,然後他們使得源程序大而且難懂和難以維護,他們會說:「但是我們節省了20%或者2 萬美元每年,很大的節省」。反之,如果我們寫我們的程序簡單而且容易擴展,我們將至少節省10%的人力開銷,一筆更大的節省,這是你客戶一定會注意到的一些事情。
另外一個對客戶來說很重要的問題就是程序的BUGS 。XP 不只是強調測試,而且要求正確的測試。測試必須是能自動進行的,以便為程序和客戶提供一個安全的環境。在編碼的所有階段,我們不斷增加測試用例。當找到bug 時,我們就添加新的測試,一個緊密的安全網就這樣產生了。同一個BUG 不出現兩次,這些一定會引起用戶的注意。你的客戶必須注意的另外一件事情:XP 開發者擁抱需求變化。XP 使我們能夠接受需求的變化。
一般情況下,客戶只有在系統被開發完成以後能真正去體會它。XP 卻不一樣,它通過加強客戶的反饋來縮短開發的周期,同時獲得足夠的時間來改變功能和獲得用戶的認同。在XP 中,你的客戶應該明確的知道這一點。
XP開發過程的大多的革命是在軟體開發的方法上,代碼質量的重要程度超出人們一般所認為的。僅僅因為我們的客戶不能明白我們的源代碼並不意味著我們可以不努力去管理代碼的質量。

8使用

XP方法的產生是因為難以管理的需求變化,從一開始你的客戶並不是很完全的知道他們要的系統是怎麼樣的,你可能面對的系統的功能一個月變化多次。在大多數軟體開發環境中不斷變化的需求是唯一的不變,這個時候應用XP 就可以取得別的方法不可能取得的成功。XP 方法的建立同時也是為了解決軟體開發項目中的風險問題。假如你的客戶在特定的時間內,需要一個相當難開發的系統,而且對於你的項目組來說,這個系統是一個新的挑戰(從來沒有做過),那風險就更大了,如果這個系統對於整個軟體行業來說都是新的挑戰,那麼它的風險就更大了,採用XP 將可以減少風險,增加成功的可能。 XP方法是為小團體開發建立的,在2-10 個人之間。假如你的團體恰好合適,你就不需要用其他的軟體工程方法了,就用XP ,但是要注意你不能將XP 方法應用於大團體的開發項目中。我們應該注意,在需求一慣呈動態變化或者高具有高風險的項目中,你就會發現XP 方法在小團體的開發中的作用要遠遠高於在大團體的開發。
XP方法需要一個擴展的開發團體,XP 團體不僅僅包括開發者,經理、客戶也是其中的一員,所有的工作一環扣一環,問問題,商討方法和日程,增加功能測試,這些問題的解決不僅僅涉及到軟體的開發者。
另一個需要是可測試性,你必須能增加自動的單元測試和功能測試,然而在你進行這個需求的時候,你會發現有許多的問題很難測試,這需要充分發揮你的測試的經驗和智慧,而且你有時還要改變你的設計以便它可以更容易的進行測試。記住:那兒有需求,那兒就應該有測試的方法。
在XP方法的好處的清單上,最後一條是生產力。在同樣的合作環境下,XP 項目都一致的表現出比使用其他方法高的多的生產力。但這從來不是XP 方法學的真正目標。XP 真實追求的目標是:在規定的時間生產出滿足客戶需要的軟體。假如對於你的開發來說,這是很重要的方面,你就可以選擇XP 了。

9實踐

1、完整團隊
XP項目的所有參與者(開發人員、客戶、測試人員等)一起工作在一個開放的場所中,他們是同一個團隊的成員。這個場所的牆壁上隨意懸挂著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。
2、計劃遊戲
計劃是持續的、循序漸進的。每2周,開發人員就為下2周估算候選特性的成本,而客戶則根據成本和商務價值來選擇要實現的特性。
3、客戶測試
作為選擇每個所期望的特性的一部分,客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。
4、簡單設計
團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試,不包含任何重複,表達出了編寫者想表達的所有東西,並且包含儘可能少的代碼。
5、結對編程
所有的產品軟體都是由兩個程序員、並排坐在一起在同一台機器上構建的。
6、測試驅動開發
編寫單元測試是一個驗證行為,更是一個設計行為。同樣,它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環,尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作,他們先增加一個失敗的測試,然後使之通過。
7、改進設計
隨時利用重構方法改進已經腐化的代碼,保持代碼儘可能的乾淨、具有表達力。
8、持續集成
團隊總是使系統完整地被集成。一個人拆入(Check in)后,其它所有人責任代碼集成。
9、集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責,每個人都可以參與任何其它方面的開發。
10、編碼標準
系統中所有的代碼看起來就好像是被單獨一人編寫的。
11、隱喻
將整個系統聯繫在一起的全局視圖;它是系統的未來影像,是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符,那麼你就知道該模塊是錯誤的。
12、可持續的速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作,他們保存精力,他們把項目看作是馬拉松長跑,而不是全速短跑。

10小結

XP的一個成功因素是重視客戶的反饋——開發的目的就是為了滿足客戶的需要。XP方法使開發人員始終都能自信地面對客戶需求的變化。XP強調團隊合作,經理、客戶和開發人員都是開發團隊中的一員。團隊通過相互之間的充分交流和合作,使用XP這種簡單但有效的方式,努力開發出高質量的軟體。XP的設計簡單而高效;程序員們通過測試獲得客戶反饋,並根據變化修改代碼和設計,他們總是爭取儘可能早地將軟體交付給客戶。XP程序員能夠勇於面對需求和技術上的變化。
XP很象一個由很多小塊拼起來的智力拚圖,單獨看每一小塊都沒有什麼意義,但拼裝好后,一幅美麗的圖畫就會呈現在你面前。
上一篇[Scrum]    下一篇 [瀑布模型]

相關評論

同義詞:暫無同義詞