極限編程過程

1. 軟體開發方法

1：瀑布方法
所有軟體方法的祖先是瀑布方法（waterfall methodology）。它之所以被稱為瀑布方法是因為開發模塊相互之間的依次流動，瀑布方法通過控制閥門的一系列活動組成。這些控制閥門決定一個給定的活動是否已經完成並且可以進入下一個活動。需求階段處理決定了所有的軟體需求。設計階段決定整個系統的設計。代碼在代碼階段編寫。代碼然後被測試。最後產品被發布。
對瀑布方法模型最基本的批評就是瀑布方法對於反饋事物發展狀況耗時太長。軟體的一些內容那個很容易被理解，而另一些內容則相反。因此，當用戶對於手邊出現的問題都沒有很好理解的時候，開發人員試圖先完成所有的需求（也就是說，將需求量化到實際的規格說明當中）是非常空難的。更進一步來說，如果在需求中出現一個錯誤，它將傳播到設計階段，傳播到代碼中等。同時一般不存在過程中返回的真正能力。因此，如果進入測試並且發現設計的一部分是無法工作的，那麼就會進行修改並修補問題而交差，但是這種方法將會失去設計活動的所有上下文環境——你只是有目的地對系統權宜行事！
認識到這個問題後瀑布方法已經被修改成幾種形式。例如螺旋式瀑布方法它繼承並使用了多個瀑布模型。這種方法縮短了生命周期向下的時間；也就是說，為解決為題提供了迭代方案。
最終，大家無法脫離瀑布方法是因為它確實是合乎常規的方法。首先，這種方法可以決定將要構建的內容。接著，決定將要如何構建這些，下一步，世界構建這些內容。可以確保自己確實構建自己所需的東西（並且可以成功運行）。
2：統一過程
統一過程應用了基於處理系統首先考慮的最重要方面而實施的短期迭代開發。
開發一個寡慾各種用列（use case）的調查文檔（也就是說，對用戶與系統交互的簡短描述），並且開始排除那些可能對整個系統成功造成風險的用列。只要適合，就可以在開發過程中添加或者刪除用列。
統一過程的4個階段定義如下：
初始(inception)：系統仍然處於決定系統內容的階段——系統將要完成什麼以及系統的邊界是什麼。如果系統能夠很好的理解，那麼這個階段就非常短。
細化(Elaboration)：正在將體系結構的風險移至系統。一種表述該階段的說法是，「你是否已經解決了所有難題？」或者「你知道如何完成你將要去完成的事情嗎？」
構造（Construction）正在完成所有相關的用列來使系統為移交做好准備，也就是說，進入Beta版本。
移交（Transition）使系統通過它的最後發布階段以及Beta版本。它可能包括軟體的操作及維護。
這是一個關注於維護要素的敏捷過程，但是仍然採用了大量用例開發，間模等方面的傳統實踐。
3：極限編程：
極限編程的開發過程就是以代碼為中心的方法。
讓用戶告知你一些有關系統是如何如用轉的故事描述，基於故事相互之間的重要性來定製這些系統這樣就可以為自己的團隊提供一個故事集合，可以在一個給定的迭代中完成他們，大約兩周時間——每周工作40個小時，你將團隊劃分，雙人應付沒一個故事，在代碼被編寫時提供確定數量的內建對等評審。你和你的同伴在編寫自己代碼的同時編寫單元測試。在完成自己負責的那段代碼後，將其拿到集成的機器上，放入代碼基線，運行從所有人的代碼中積累而成的單元測試。在完成iji負責的那段代碼後，將會提供一個運行系統使用戶可以評審來確保自己的工作滿足他們的需要。
注意極限編程並沒有將軟體的設計設置成一個高級階段。相反它認為那些最前端的設計對於整個系統開發不是很有幫助，並且隨著實際開發的進行它最終還是被修改。
極限編程對於需要持續提供運行系統的軟體卡發來說非常適用。當缺少用戶介入或者項目規模很大時極限編程方法將會不好用，因為這時協調和設計活動實際上變得更重要了。
極限編程合理地考慮開發團體的能力，這樣可以有效計劃。

2. 極限編程的核心價值

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

3. 極限編程是什麼意思 《法語助手》法漢

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

4. 什麼是極限編程

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

5. 敏捷開發、極限編程和結對編程這三者什麼關系啊

敏捷開發是十幾種開發方法的統稱，極限編程就是這十幾種開發方法之一。
極限編程包括了十幾種實踐（就是一些具體做法），結對編程是極限編程的一種實踐。

6. 什麼是極限編程

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

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

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

8. 極限編程的計劃項目

XP的計劃過程主要針對軟體開發中的兩個問題：預測在交付日期前可以完成多少工作；現在和下一步該做些什麼。不斷的回答這兩個問題，就是直接服務於如何實施及調整開發過程；與此相比，希望一開始就精確定義整個開發過程要做什麼事情以及每件事情要花多少時間，則事倍功半。針對這兩個問題，XP中又兩個主要的相應過程：
軟體發布計劃（ReleasePlanning）。客戶闡述需求，開發人員估算開發成本和風險。客戶根據開發成本、風險和每個需求的重要性，制訂一個大致的項目計劃。最初的項目計劃沒有必要（也沒有可能）非常准確，因為每個需求的開發成本、風險及其重要性都不是一成不變的。而且，這個計劃會在實施過程中被不斷地調整以趨精確。
周期開發計劃（IterationPlanning）。開發過程中，應該有很多階段計劃（比如每三個星期一個計劃）。開發人員可能在某個周期對系統進行內部的重整和優化（代碼和設計），而在某個周期增加了新功能，或者會在一個周期內同時做兩方面的工作。但是，經過每個開發周期，用戶都應該能得到一個已經實現了一些功能的系統。而且，每經過一個周期，客戶就會再提出確定下一個周期要完成的需求。在每個開發周期中，開發人員會把需求分解成一個個很小的任務，然後估計每個任務的開發成本和風險。這些估算是基於實際開發經驗的，項目做得多了，估算自然更加准確和精確；在同一個項目中，每經過一個開發周期，下一次的估算都會有更多的經驗、參照和依據，從而更加准確。這些簡單的步驟對客戶提供了豐富的、足夠的信息，使之能靈活有效地調控開發進程。每過兩三個星期，客戶總能夠實實在在地看到開發人員已經完成的需求。在XP里，沒有什麼「快要完成了」、「完成了90%」的模糊說法，要不是完成了，要不就是沒完成。這種做法看起來好像有利有弊：好處是客戶可以馬上知道完成了哪些、做出來的東西是否合用、下面還要做些什麼或改進什麼等等；壞處是客戶看到做出來的東西，可能會很不滿意甚至中止合同。實際上，XP的這種做法是為了及早發現問題、解決問題，而不是等到過了幾個月，用戶終於看到開發完的系統了，然後才告訴你這個不行、那個變了、還要增加哪個內容等等。

9. 1.什麼是敏捷過程極限編程 2.他們的要點是什麼 3.與其它的開發模式的區別是什麼

一般來說，XP比較適合周期短，需求靈活性高的項目，僅交流