亚洲国产区中文,国产精品91高清,亚洲精品中文字幕久久久久,亚洲欧美另类久久久精品能播放

歷史

極限編程的創(chuàng)始者是肯特·貝克、沃德·坎寧安和羅恩·杰弗里斯（英語：Ron Jeffries），他們在為克萊斯勒綜合報酬系統(tǒng)（英語：Chrysler Comprehensive Compensation System）的薪水冊項目工作時提出了極限編程方法?？咸亍へ惪嗽?996年3月成為克萊斯勒系統(tǒng)的項目負責(zé)人，開始對項目的開發(fā)方法學(xué)進行改善。他寫了一本關(guān)于這個改善后的方法學(xué)的書，并且于1999年10月將之發(fā)行，這就是《極限編程解析》（2005第二版出版）?？巳R斯勒在2000年2月取消了實質(zhì)上并未成功的克萊斯勒系統(tǒng)，但是這個方法學(xué)卻一直流行在軟件工程領(lǐng)域中。至今2006年，很多軟件開發(fā)項目都一直以極限編程做為他們的指導(dǎo)方法學(xué)。

該書闡述了如下的極限編程的哲學(xué)思想：

一種社會性的變化機制

一種開發(fā)模式

一種改進的方法

一種協(xié)調(diào)生產(chǎn)率和人性的嘗試

一種軟件開發(fā)方法

把極限編程一般化并用于其它類型的專案稱為極限專案管理。

極限編程的推廣之一為把不同的敏捷軟件實踐和傳統(tǒng)實踐節(jié)奏地結(jié)合起來，彈性地合用于不同企業(yè)開發(fā)環(huán)境。這就是軟件開發(fā)節(jié)奏（Software Development Rhythms）的中心思想

目標

極限編程的主要目標在于降低因需求變更而帶來的成本。在傳統(tǒng)系統(tǒng)開發(fā)方法中，系統(tǒng)需求是在項目開發(fā)的開始階段就確定下來，并在之后的開發(fā)過程中保持不變的。這意味著項目開發(fā)進入到之后的階段時出現(xiàn)的需求變更—而這樣的需求變更在一些發(fā)展極快的領(lǐng)域中是不可避免的—將導(dǎo)致開發(fā)成本急速增加。

極限編程通過引入基本價值、原則、方法等概念來達到降低變更成本的目的。一個應(yīng)用了極限編程方法的系統(tǒng)開發(fā)項目在應(yīng)對需求變更時將顯得更為靈活。

核心實踐

極限編程實踐作業(yè)的核心可以被區(qū)分為以下四個范圍（12個實踐作業(yè)）:

細微回饋

結(jié)對程序設(shè)計

策劃游戲

測試驅(qū)動開發(fā)

全隊（原名：在場客戶）

持續(xù)程序

持續(xù)集成

設(shè)計最優(yōu)化（原名：軟件重構(gòu)）

小型發(fā)布

共識

編碼標準

代碼集體共有

簡單設(shè)計

系統(tǒng)隱喻

程序員的利益

可持之以恒的速度

在第二版的《極限編程解析》中，在主要實踐之外，還列出了一系列延伸的實踐。

核心實踐源自被廣泛接受的最佳實踐，并且被推向極致：

開發(fā)人員和客戶之間的交互是有益的。因此，一個極限編程的小組從理論上要求需要一個軟件用戶在身邊，這個用戶制定軟件的工作需求和優(yōu)先等級，并且盡可能在各種問題出現(xiàn)的時候馬上就能回答（實際工作中，這個角色是由客戶代理商完成的）.

如果學(xué)習(xí)是好的，那么就把它做到底：這樣減少了開發(fā)和回饋周期的長度，測試也能更早完成。

簡單的代碼更可能工作。所以極限編程的程序設(shè)計師在一個軟件專案中唯寫出能夠滿足目前實際需求的代碼，這樣或多或少降低了代碼的復(fù)雜性和重復(fù)性。

如果簡單的代碼是好的，那么把變得復(fù)雜的代碼改寫成簡單的。

代碼評審是好的。因此，極限編程的程序設(shè)計師以兩人搭檔的方式工作。他們共享一個屏幕和鍵盤，增加了隊員之間的交流，也讓代碼在一被寫出的時候就被人評審了。

測試代碼是好的。因此，在極限編程中，測試用例在實際代碼之前就被寫出來了。代碼只有在通過測試的時候才被認為完成了。（當(dāng)然，需要進一步分解來降低復(fù)雜性）。整個軟件系統(tǒng)用一種周期化的，實時的，被預(yù)先編好的自動化測試方式來保證它的確有作用。參看測試驅(qū)動的開發(fā)。

一般來說，極限編程被認為對于少于12人的小團隊很有用。一些人認為極限編程可以用于大的團隊，但是其它人認為Rational統(tǒng)一過程更適合大的團隊。然而，極限編程很難在一些超過100人的開發(fā)小組中獲得成功。并不是極限編程不能夠推廣到更大的團隊，而是很少有更大的團隊來試著用它。極限編程的人員也拒絕去隨便推測這個問題。

概念

活動

極限編程描述了在軟件開發(fā)過程中四種基本的行為，包括

編碼

測試

傾聽

設(shè)計

極限編程的提倡者爭辯說在系統(tǒng)開發(fā)過程的產(chǎn)物中真正重要的只有編碼，并認為沒有經(jīng)過測試的代碼什么都不是。如果你沒有測試，客戶可能感覺不到，很多軟件在發(fā)布的時候沒有經(jīng)過完整的測試，它們還都在工作（或多或少的工作）。極限編程認為，在軟件開發(fā)程序中，如果一個函數(shù)沒有經(jīng)過測試就不能認為它可以工作。

價值

極限編程技術(shù)以溝通、簡單、回饋、勇氣和尊重為價值標準。

溝通

構(gòu)建一個軟件系統(tǒng)的基本任務(wù)之一就是與系統(tǒng)的開發(fā)者交流以明確系統(tǒng)的具體需求。在一些正式的軟件開發(fā)方法中，這一任務(wù)是通過文檔來完成的。

極限編程技術(shù)可以被看成是在開發(fā)小組的成員之間迅速構(gòu)建與傳播制度上的認識的一種方法。它的目標是向所有開發(fā)人員提供一個對于系統(tǒng)的共享的視角，而這一視角又是與系統(tǒng)的最終用戶的視角相吻合的。為了達到這一目標，極限編程支持設(shè)計、抽象、還有用戶-程序員間交流的簡單化，鼓勵經(jīng)常性的口頭交流與回饋。

簡單

極限編程鼓勵從最簡單的解決方式入手再通過不斷重構(gòu)達到更好的結(jié)果。這種方法與傳統(tǒng)系統(tǒng)開發(fā)方式的不同之處在于，它只關(guān)注于對當(dāng)前的需求來進行設(shè)計、編碼，而不去理會明天、下周或者下個月會出現(xiàn)的需求。極限編程的擁護者承認這樣的考慮是有缺陷的，即有時候在修改現(xiàn)有的系統(tǒng)以滿足未來的需求時不得不付出更多的努力。然而他們主張“不對將來可能的需求上投入精力”所得到的好處可以彌補這一點，因為將來的需求在他們還沒提出之前是很可能發(fā)生變化的。為了將來不確定的需求進行設(shè)計以及編碼意味著在一些可能并不需要的方面浪費資源。而與之前提到的“交流”這一價值相關(guān)聯(lián)來看，設(shè)計與代碼上的簡化可以提高交流的質(zhì)量。一個由簡單的編碼實現(xiàn)的簡單的設(shè)計可以更加容易得被小組中的每個程序員所理解。

回饋

在極限編程中，“回饋”是和系統(tǒng)開發(fā)的很多不同方面相關(guān)聯(lián)的：

來自系統(tǒng)的回饋：通過編寫單元測試，程序員能夠很直觀的得到經(jīng)過修改后系統(tǒng)的狀態(tài)。

來自客戶的回饋：功能性測試是由客戶還有測試人員來編寫的。他們能由此得知當(dāng)前系統(tǒng)的狀態(tài)。這樣的評審一般計劃2、3個禮拜進行一次，這樣客戶可以非常容易的了解、掌控開發(fā)的進度。

來自小組的回饋：當(dāng)客戶帶著新需求來參加項目計劃會議時，小組可以直接對于實現(xiàn)新需求所需要的時間進行評估然后回饋給客戶。

回饋是與“交流”、“簡單”這兩條價值緊密聯(lián)系的。為了溝通系統(tǒng)中的缺陷，可以通過編寫單元測試，簡單的證明某一段代碼存在問題。來自系統(tǒng)的直接回饋信息將提醒程序員注意這一部分。用戶可以以定義好的功能需求為依據(jù)，對系統(tǒng)進行周期性的測試。用Kent Beck的話來說：“編程中的樂觀主義是危險的，而及時回饋則是解決它的方法?！?/span>

勇氣

極限編程理論中的“系統(tǒng)開發(fā)中的勇氣”最好用一組實踐來詮釋。其中之一就是“只為今天的需求設(shè)計以及編碼，不要考慮明天”這條戒律。這是努力避免陷入設(shè)計的泥潭、而在其他問題上花費了太多不必要的精力。勇氣使得開發(fā)人員在需要重構(gòu)他們的代碼時能感到舒適。這意味著重新審查現(xiàn)有系統(tǒng)并完善它會使得以后出現(xiàn)的變化需求更容易被實現(xiàn)。另一個勇氣的例子是了解什么時候應(yīng)該完全丟棄現(xiàn)有的代碼。每個程序員都有這樣的經(jīng)歷：他們花了一整天的時間糾纏于自己設(shè)計和代碼中的一個復(fù)雜的難題卻無所得，而第二天回來以一個全新而清醒的角度來考慮，在半小時內(nèi)就輕松解決了問題。

尊重

尊重的價值體現(xiàn)在很多方面。在極限編程中，團隊成員間的互相尊重體現(xiàn)在每個人保證提交的任何改變不會導(dǎo)致編譯無法通過、或者導(dǎo)致現(xiàn)有的測試案例失敗、或者以其他方式導(dǎo)致工作延期。團隊成員對于他們工作的尊重體現(xiàn)在他們總是堅持追求高質(zhì)量，堅持通過重構(gòu)的手段來為手頭的工作找到最好的解決設(shè)計方案。

原則

組成極限編程基礎(chǔ)的原則，正是基于上面描述的那幾條價值。在系統(tǒng)開發(fā)項目中，這些原則被用來為決策做出指導(dǎo)。與價值相比，原則被描述的更加具體化，以便在實際應(yīng)用中更為簡單的轉(zhuǎn)變?yōu)榫唧w的指導(dǎo)意見。

快速回饋

當(dāng)回饋能做到及時、迅速，將發(fā)揮極大的作用。一個事件和對這一事件做出回饋之間的時間，一般被用來掌握新情況以及做出修改。與傳統(tǒng)開發(fā)方法不同，與客戶的發(fā)生接觸是不斷反復(fù)出現(xiàn)的?？蛻裟軌蚯宄囟床扉_發(fā)中系統(tǒng)的狀況。他／她能夠在整個開發(fā)過程中及時給出回饋意見，并且在需要的時候能夠掌控系統(tǒng)的開發(fā)方向。

單元測試同樣對貫徹回饋原則起到作用。在編寫代碼的過程中，應(yīng)需求變更而做出修改的系統(tǒng)將出現(xiàn)怎樣的反應(yīng)，正是通過單元測試來給出直接回饋的。比如，某個程序員對系統(tǒng)中的一部分代碼進行了修改，而假如這樣的修改影響到了系統(tǒng)中的另一部分（超出了這個程序員的可控范圍），則這個程序員不會去關(guān)注這個缺陷。往往這樣的問題會在系統(tǒng)進入生產(chǎn)環(huán)節(jié)時暴露出來。

假設(shè)簡單

假設(shè)簡單認為任何問題都可以"極度簡單"地解決。傳統(tǒng)的系統(tǒng)開發(fā)方法要考慮未來的變化，要考慮代碼的可重用性。極限編程拒絕這樣做。

包容變化

可以肯定地是，不確定因素總是存在的。“包容變化”這一原則就是強調(diào)不要對變化采取反抗的態(tài)度，而應(yīng)該包容它們。比如，在一次階段性會議中客戶提出了一些看來戲劇性的需求變更。作為程序員，必須包容這些變化，并且擬定計劃使得下一個階段的產(chǎn)品能夠滿足新的需求。

實踐

策劃游戲

在極限編程中主要的策劃程序稱為策劃游戲，本節(jié)將通過程序模型介紹這個程序。

策劃程序分為兩部分：

發(fā)布策劃：

反復(fù)狀態(tài)：

提交狀態(tài)—發(fā)布計劃

這一階段涉及成本、利潤和計劃影響這三個因素，包含四個部分：

按照價值排序：業(yè)務(wù)方按照商業(yè)價值為用戶故事排序。

按風(fēng)險排序：開發(fā)方按風(fēng)險為用戶故事排序。

設(shè)置周轉(zhuǎn)率：開發(fā)方?jīng)Q定以怎樣的速度開展項目。

選擇范圍：挑選在下一個發(fā)布中需要被完成的用戶故事，基于用戶故事決定發(fā)布日期。

價值排序

業(yè)務(wù)方按照商業(yè)價值為用戶故事排序。它們會被分為三類：

關(guān)鍵：沒有這些故事系統(tǒng)無法運作或變得毫無意義。

重要的商業(yè)價值：有重要業(yè)務(wù)價值的非關(guān)鍵用戶故事。

最好能有：并沒有重要商業(yè)價值的用戶故事；例如在可用性或用戶界面上的改進。

風(fēng)險排序

程序員按照風(fēng)險對用戶故事進行排序。他／她們將用戶故事的風(fēng)險劃分成三類：低、中、高。以下是這種方式的一個示例：

決定風(fēng)險索引：依照以下因素給每個用戶故事一個0到2的索引：

為每個用戶故事增加所有這些索引后，給這些用戶故事指定一個風(fēng)險索引：低（0–1），中（2–4），高（5–6）。

激勵狀態(tài)—發(fā)布計劃

在作業(yè)階段開發(fā)人員和業(yè)務(wù)人員可以“操縱”整個程序。這意味著，他們可以做出改變。個體的用戶故事，或是不同用戶故事的相對優(yōu)先檔次，都有可能改變；預(yù)估時間也可能出現(xiàn)誤差。這是做出相應(yīng)調(diào)整的機會。

探索階段—反復(fù)計劃

反復(fù)計劃中的探索階段是關(guān)于創(chuàng)建任務(wù)和預(yù)估實施時間。

收集用戶故事：收集并編輯下一個發(fā)布的所有用戶故事。

組合／分區(qū)任務(wù)：如果程序員因為任務(wù)太大或太小而不能預(yù)估任務(wù)完成時間，則需要組合或分區(qū)此任務(wù)。

預(yù)估任務(wù)：預(yù)測需要實現(xiàn)此任務(wù)的時間。

約定階段—反復(fù)計劃

在反復(fù)計劃的約定階段以不同用戶故事作為參考的任務(wù)被指派到程序員。

程序員接受任務(wù)：每個程序員都挑選一個他／她負責(zé)的任務(wù)。

程序員預(yù)估任務(wù)：由于程序員對此任務(wù)負責(zé)，他／她必須給出一個完成任務(wù)的估計時間。

設(shè)置負載系數(shù)：負載系數(shù)表示每個程序員在一個反復(fù)中理想的開發(fā)時間。比如：一周工作40小時，其中5小時用于開會，則負載系數(shù)不會超過35小時。

平衡：當(dāng)團隊中所有程序員都已經(jīng)被配置了任務(wù)，便會在預(yù)估時間和負載系數(shù)間做出比較。任務(wù)配置在程序員中達到平衡。如果有一個程序員的開發(fā)任務(wù)過重，其它程序員必須接手他／她的一部分任務(wù)，反之亦然。

作業(yè)階段—反復(fù)計劃

各個任務(wù)是在反復(fù)計劃的作業(yè)階段中一步步實現(xiàn)的。

獲取一張任務(wù)卡片：程序員獲取一張由他／她負責(zé)的任務(wù)的卡片。

找尋一名同伴：這個程序員將和另一位程序員一同完成開發(fā)工作。這在實施結(jié)隊程序設(shè)計中會做更深入的探討。

設(shè)計這個任務(wù)：如果需要，兩位程序員會設(shè)計這個任務(wù)所達成的功能。

編輯單元測試：在程序員開始編輯實現(xiàn)功能的代碼之前，他／她們首先編輯自動測試。這在實施單元測試中會做更深入的探討。

編輯代碼：兩位程序員開始編輯代碼。

運行測試：運行單元測試來確定代碼能正常工作。

運行功能測試：運行功能測試（基于相關(guān)用戶故事和任務(wù)卡片中的需求）。

結(jié)對程序設(shè)計

結(jié)對程序設(shè)計的意思是所有的代碼都是由兩個人坐在一臺電腦前一起完成的。一個程序員控制電腦并且主要考慮編碼細節(jié)。另外一個人主要關(guān)注整體結(jié)構(gòu)，不斷的對第一個程序員寫的代碼進行評審。

結(jié)對不是固定的：我們甚至建議程序員盡量交叉結(jié)對。這樣，每個人都可以知道其它人的工作，每個人都對整個系統(tǒng)熟悉，結(jié)對程序設(shè)計加強了團隊內(nèi)的溝通。（這與代碼集體所有制是息息相關(guān)的）.

集體所有制

集體所有制意味著每個人都對所有的代碼負責(zé)；這一點，反過來又意味著每個人都可以更改代碼的任意部分。結(jié)隊程序設(shè)計對這一實踐貢獻良多：借由在不同的結(jié)隊中工作，所有的程序員都能看到完全的代碼。集體所有制的一個主要優(yōu)勢是提升了開發(fā)程序的速度，因為一旦代碼現(xiàn)錯誤，任何程序員都能修正它。

在給予每個開發(fā)人員修改代碼的權(quán)限的情況下，可能存在程序員引入錯誤的風(fēng)險，他／她們知道自己在做什么，卻無法預(yù)見某些依賴關(guān)系。完善的單元測試可以解決這個問題：如果未被預(yù)見的依賴產(chǎn)生了錯誤，那么當(dāng)單元測試運行時，它必定會失敗。

現(xiàn)場客戶

在極限編程中，“客戶”并不是為系統(tǒng)付賬的人，而是真正使用該系統(tǒng)的人。極限編程認為客戶應(yīng)該時刻在現(xiàn)場解決問題。例如：在團隊開發(fā)一個財務(wù)管理系統(tǒng)時，開發(fā)小組內(nèi)應(yīng)包含一位財務(wù)管理人員。

單元測試

單元測試是用以測試一小段代碼的自動測試（例如：類，方法）。在極限編程中，在代碼編輯前就編輯單元測試。這種方式的目的是激勵程序員設(shè)想他／她的代碼在何種條件下會出錯。極限編程認為當(dāng)程序員無法再想出更多能使他／她的代碼出錯的情況時，這些代碼便算完成。

重構(gòu)

由于極限編程教條提倡編輯程序時只滿足目前的需求，并且以盡可能簡單的方式實現(xiàn)。有時會碰上一套僵硬的系統(tǒng)，所謂僵硬的系統(tǒng)，表現(xiàn)之一是需要雙重（或多重）維護：功能變化需要對多份同樣（或類似）的代碼進行修改；另一種表現(xiàn)是對代碼的一部分進行修改時會影響其它很多部分。XP教條認為當(dāng)這種情況發(fā)生時，意味著系統(tǒng)正告訴你通過改變系統(tǒng)架構(gòu)以重構(gòu)代碼，使它更簡單、更泛用。參見重構(gòu)。

極限編程的特征

極限編程方法的基本特征是：

增量和反復(fù)式的開發(fā) - 一次小的改進跟著一個小的改進。

反復(fù)性，通常是自動重復(fù)的單元測試，回歸測試。參見JUnit。

結(jié)對程序設(shè)計

在程序設(shè)計團隊中的用戶交互（在場的客戶）

軟件重構(gòu)

共享的代碼所有權(quán)

簡單

回饋

用隱喻來組織系統(tǒng)

可以忍受的速度

爭論的觀點

極限編程也有其被爭論的一面：

沒有書面的詳細的規(guī)格說明書

客戶代表被安排在項目中

程序員以結(jié)對的方式工作

測試驅(qū)動的開發(fā)

絕大多數(shù)設(shè)計活動都匆匆而過，并漸進式的，開始一個“最簡單的可能工作的東西”并當(dāng)其需要時（測試失?。┎旁黾訌?fù)雜性。單元測試促成為了設(shè)計紀律。

參考文獻

來源

肯特·貝克：《極致編程解析：擁抱變化》，Addison-Wesley, ISBN 0201616416

阿里斯代爾·寇本：《敏捷軟件開發(fā)》，Addison-Wesley, ISBN 0201699699

雷劍文：《超越傳統(tǒng)的軟件開發(fā)——極致編程的幻象與真實》，電子工業(yè)出版社，ISBN 7-121-00657-X

Lui, Kim Man 雷劍文, Software Development Rhythms: Harmonizing Agile Practices for Synergy, John Wiley and Sons, 2008（）

免責(zé)聲明：以上內(nèi)容版權(quán)歸原作者所有，如有侵犯您的原創(chuàng)版權(quán)請告知，我們將盡快刪除相關(guān)內(nèi)容。感謝每一位辛勤著寫的作者，感謝每一位的分享。