極限編程

A. 敏捷開發和極限編程的關系是什麼

『敏捷』這個詞是指軟體開發的一種理念。好些個方法都可以歸入敏捷型旗下，如極限程序設計（XP），Scrum，精悍開發（Lean Development）等等。每種方法都有自己特定的思路、社群和領軍人物。當然，一個社群如果要宣稱自己是敏捷論者，它必須要遵循一些相同的原則。每個社群也從其他社群中借鑒相互的思想與技術。也有許多人士在不同的社群間來來往往，因此把不同的思想傳來播去。所有這些都讓敏捷社會成為一個復雜而動態的生態系統。

B. 極限編程的方法

基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐
團隊協作(Whole Team)
規劃策略(The Planning Game)；
結對編程(Pair programming)
測試驅動開發(Testing-Driven Development)
重構(Refactoring)
簡單設計(Simple Design)
代碼集體所有權(Collective Code Ownership)
持續集成(Continuous Integration)
客戶測試(Customer Tests)
小型發布（Small Release）
每周40小時工作制（40-hour Week）
編碼規范（Code Standards）
系統隱喻（System Metaphor） 計劃項目（PlanningGame）、驗收測試、小規模發布（SmallReleases）
XP開發小組使用簡單的方式進行項目計劃和開發跟蹤，並以此預測項目進展情況和決定未來的步驟。根據需求的商業價值，開發小組針對一組組的需求進行一系列的開發和整合，每次開發都會產生一個通過測試的、可以使用的系統。

C. 什麼是極限編程

極限編程(Extreme Programming，XP)是一門針對業務和軟體開發的規則，它的作用在於將兩者的力量集中在共同的、可以達到的目標上。它是以符合客戶需要的軟體為目標而產生的一種方法論，XP使開發者能夠更有效的響應客戶的需求變化，哪怕是在軟體生命周期的後期。它強調，軟體開發是人與人合作進行的過程，因此成功的軟體開發過程應該充分利用人的優勢，而弱化人的缺點，突出了人在軟體開發過程中的作用。極端編程屬於輕量級的方法，認為文檔、架構不如直接編程來的直接。

D. 極限編程和敏捷方法的關系

極限編程強調的是邊進行項目邊測試，強調的是一個迭代的過程，而敏捷方法是強調可以省略標准過程中對於項目意義不大的步驟。可能我說的也不是很准確，可以去仔細看看軟體工程的書，上面有介紹

E. 瀑布模型和極限編程方法分別適用於什麼類型的軟體產品

瀑布模型、極限編程、敏捷開發是有代表性的開發模式，在對開發者、客戶、最終的產品的關註上的變化，體現了軟體開發管理者在管理模式上的變化。

瀑布模型
是一種理想化的開發模型，要求有明確的需求分析，無法解決軟體需求不明確或不準確的問題。
瀑布模型像工廠流水

F. 極限編程的使用

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

G. 什麼是極限編程

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

H. 極限編程(Extreme Programming)為什麼簡稱XP而不是EP

電腦網路軟體問題。根據你的描述，極限編程(Extreme Programming)簡稱XP而不是EP。原因是：第一個發音與字母x同音，所以用x而不同e。

I. 極限編程和其它的軟體開發方法的區別。 盡量全一點。2000字左右

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

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

極限編程中有四個核心價值是我們在開發中必須注意的：溝通（Communication）、簡單（Simplicity）、反饋（Feedback）和勇氣（Courage）。 XP用「溝通、簡單、反饋和勇氣」來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定范圍內成功地打破了軟體工程「必須重量」才能成功的傳統觀念。

XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用「溝通、簡單、反饋和勇氣」的態度來對待XP；輕松愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。

XP中一些基本概念的簡介 UserStory：開發人員要求客戶把所有的需求寫成一個個獨立的小故事，每個只需要幾天時間就可以完成。開發過程中，客戶可以隨時提出新的UserStory，或者更改以前的UserStory。 StoryEstimates和開發速度：開發小組對每個UserStory進行估算，並根據每個開發周期（Iteration）中的實際情況反復計算開發速度。這樣，開發人員和客戶能知道每個星期到底能開發多少UserStory。 ReleasePlan和ReleaseScope：整個開發過程中，開發人員將不斷地發布新版本。開發人員和客戶一起確定每個發布所包含的UserStory。 Iteration（開發周期，或稱迭代）和IterationPlan：在一個Release過程中，開發人員要求客戶選擇最有價值的UserStory作為未來一兩個星期的開發內容。 TheSeed：第一個迭代（Iteration）完成後，提交給客戶的系統。雖然這不是最終的產品，但它已經實現了幾個客戶認為是最重要的Story，開發人員將逐步在其基礎上增加新的模塊。 ContinuousIntegration（整合）：把開發完的UserStory的模塊一個個拼裝起來，一步步接近乃至最終完成最終產品。 驗收測試（功能測試）：對於每個UserStory，客戶將定義一些測試案例，開發人員將使運行這些測試案例的過程自動化。 UnitTest（單元測試）：在開始寫程序前，程序員針對大部分類的方法，先寫出相應的測試程序。 Refactoring(重構)：去掉代碼中的冗餘部分，增加代碼的可重用性和伸縮性。