敏捷軟件開發和極限編程介紹

轉自：http://www.uml.org.cn/SoftWareProcess/201108154.asp 請閱讀原文

0. 軟件開發的本質

先讓咱們看看通常的產品生產：

例一，汽車生產。原材料、配件等採購完畢（我這裏說到了採購配件，這至關於把部分功能的生產轉交給其餘職能公司。對應到軟件生產的(子)項目外包。這個話題在本文就不擴展了），進入生產、組裝、測試車間，進行一系列規定的工做流程。正常狀況下，若是不發生不可抗拒的事件，那麼能夠按時完成合同規定的交付。這中間不會有什麼變更性和不可預測性。

例二，再來看一個例子，好比某人想蓋一棟房子，他想使用環保材料，當開發商給出房子的草圖、價格預算，交給他時，他可能會改變主意。在建造房子的過程當中，他的一些想法會逐漸明朗化。當房子蓋好以後，實物呈如今他眼前時，原先他的那套裝修想法也可能根據房子的實際樣子來作調整，好比廚房的佈局、主臥的裝潢等。總的來講，事先的計劃趕上了變化，站在「客戶至上」的位置上，開發商業就要改變計劃，知足客戶的新須要。至於如何操做，那是合同談判的事。客戶改變想法是有理由的，由於原先那一套東西都是構築在設計中的（紙質設計圖，有的開發上會提供3D圖形或動畫），客戶直到見到實物，纔會有他進一步的，更明確的想法。

軟件開發是也生產性的行業，他的產品是交付給客戶的軟件。類比上面的例子，軟件開發更接近於建築行業，需求會變更，每次生產的東西都不太同樣，甚至大不同。更例外的一點，軟件開發的工做量和時間估計比建築生產更具有不肯定性。這種不肯定性來自於需求變更、資金支持、技術風險、人員流動、質量控制、功能範圍的肯定等。

（另外，通常來講一般客戶只能規定四個變量 「代價、時間、質量、範圍」中的三個，另一個就是開發團隊來選擇了，好比客戶準備花$XXX在這個月底實現全部功能點；那麼在壓力下，質量的選擇就是開發團隊來肯定了；不然就得調整客戶選擇的其餘三個變量。——這四個變量之說來自《擁抱變化》，極限編程的開山之做。）

總的來講，軟件生產的本質是具有創新性的新產品開發。

新產品開發有那些特徵呢？

• 不可能在前期建立一成不變的、詳細的規格說明。
• 在開始階段，很難進行預期分析。隨着經驗數據的出現，計劃與估算的可能性纔會相應增長。
• 在開始階段，識別、定義、調度、和安排全部的細節活動都是不太可能的。經過構建反饋週期，能夠推進自適應步驟。
• 通常狀況是主動適應沒有定義的變更，而且改動率比較高。

與創新性新產品開發對應的就是具有可預見性的製造。它能夠有笨重的前期規格說明、估算、推測計劃等。而新產品開發拒絕這些「可靠的」前期規格說明，理由是：

客戶或者用戶不可能明確知道他們到底要什麼。（須要經過逐步的交流和引導讓其明確起來）

• 他們很難陳述全部的需求和知識。
• 他們想要的許多細節只能在開發過程當中逐步展示出來。
• 細節對於他們可能過於複雜。
• 當他們看到了產品的開發，他們將可能會改變初衷。
• 外部壓力（好比競爭者的產品或者服務）致使需求的變動或者增長。

1. 近年來軟件項目的一些統計數據以及通常性結論

正是由於軟件開發不是循規蹈矩的可預見性的生產活動，而是具創新性的新產品開發活動，因此不少採用遵循可預見性產品生產方式的軟件項目最終都以失敗收場，無論是小企業仍是知名企業。這是新產品開發確定會有的狀況，固然也有方法論的問題。

讓咱們來看一組軟件開發領域的研究和統計數據，這些數據顯示了近年來軟件項目開發的基本狀況：

圖1.顯示了一個對23,000個項目「成功實施—持續時間」的關係，這裏的「成功」定義爲「項目在資金預算和項目工期內完成，並具有全部預先指定的特徵和功能」。（Standish98 Jim Johnson, et al. 1998. ChAOS: A Recipe for Success, 1998. Published Report. The Standish Group）（你們能夠用這個定義來衡量一下本身公司的項目成功率如何。

 

圖1. 項目成功率和項目持續時間的關係圖

（橫座標爲項目持續時間(多少個月)；縱座標是項目成功的比率）

從這個圖中，咱們能夠看出項目持續時間短的成功率比較高。可見小型項目易於成功。另外也有研究代表小團隊的項目更易於得到成功。

圖2. 顯示了軟件項目開展過程當中增長進來的變更性因素的狀況。項目大小以功能點來衡量，在圖中對應橫座標；縱座標表示需求的變更，仍以功能點爲單位。(Jones97 Jones, C. 1997. Applied Software Measurement. McGraw Hill)

圖2. 需求變動和項目大小之間的關係圖

從這個圖中咱們能夠看出需求變更沒法規避，典型地，一個項目確定要面對需求變動的狀況，猶如前面的蓋房例子。需求變動也影響到項目的成功率。（這裏的成功依舊聽從前面的定義。）

圖3. 是需求管理中的要求實現的功能點在軟件產品交付以後實際被使用狀況的比率，這個比率很是驚人地代表幾乎一半的功能甚至從爲被使用過，至關多一部分功能也不多被使用。在競爭性產品市場上，這些功能點多是賣點，從而也增長了項目的體積、複雜性，影響到項目的成功率，交付日期。非競爭性領域，對這些需求應該再考慮考慮:-）按20-80原則，20%的功能具有了產品的80%的重要內容)（Johnson02 Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.）。另外，基於風險和客戶驅動，能夠最大化最常使用的功能。從而一個項目甚至在完成了其20%功能時，就能夠成爲一個較爲有用的階段性發布。

圖3. 產品中要求的功能點在實際中的使用狀況

另外，有證據顯示，隨着功能點的增多，每一個開發人員的生產效率降低，每一個開發人員的錯誤率上升。（Jones00 Jones, C. 2000. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley）。此外有證據顯示失敗項目中很大一部分是採用瀑布模型的。

2. 瀑布模型 vs. 迭代模型

有什麼樣的世界觀，就會有什麼樣的方法論。宇宙萬物變更不居。沒有絕對的靜止。軟件項目的實施過程一樣如此。需求的變更，資金投入的變化、團隊人員進出、質量範圍改變、時間期限變動等之間都有一系列聯動關係。

應對變更性產生了截然相反的兩種態度。

經過分階段的肯定輸入、輸出來規避變更性，先確認輸入是固定不變的（經評審的），這樣就能夠設計產生想要的下一個輸出。這就是所謂「推(Push)」方式，這種方式彷佛規避了變更性，注意，咱們先前的圖2. 說過即使是需求功能點變動也是常有的狀況，因此對這種變更性的認識和響應其實是被推遲到了項目的後期客戶驗收階段。

另一種態度就是積極響應這種變更性，項目開展的整個過程當中都鼓勵加入新的需求這種方式。

若是忽略許多爭論不休的地方，大致上，試圖規避或者說想一步到位獲取需求的線性開發方式就是對應到「瀑布模型（Waterfall Model）」，而積極響應變化的經過屢次反覆的增量式過程就是「迭代模型（Interative Model）」。有必要說明一點，瀑布模型的發明者本人說他是迭代模型的擁護着，它只是認爲瀑布模型是軟件開發中的最簡單的一種模型。

咱們來看一些圖，直觀地看一下這兩種模型。

圖4. 是瀑布模型及其高風險示圖，從這個圖中咱們能夠看到隨着時間的延續，風險增大。恐或正是由於早期的低風險，才使得人們在很長一段時間內喜歡採用這種模型。懼怕風險是人類的通病。而且這種模型很簡單，一個單調的過程，容易記憶，操做起來也很簡單。需求-設計-實現-測試。

圖4. 瀑布模型及其高風險示圖

隨着愈來愈多的證據證實了瀑布模型的高風險和高失敗率以後，瀑布模型自身也發生了一些變化，以至繼續有人採用這種模型的變體來進行項目開發。正如我之前寫過的一個文檔，這個模型通常來講不適合因而軟件開發上。

圖5. 是瀑布模型隨着時間的推移，新加入變更性因素（好比需求變動等）的整體代價關係。

圖5. 瀑布模型的變更性的整體代價

這種模型的一個重要問題就是缺少反饋。他是一種經過單向的控制來完成的，而且相信這種控制都正確的，好比從ANALYSIS -->DESIGN這個過程，根據分析的決議來作設計，而且相信這個ANALYSIS是正確的。這相似於行軍打仗，每一個上級都認爲他的指令被正確的執行，這種指令的正確性暫且不談(這涉及到每層的控制人員的專業素養)，顯然會出現將在外軍令有所不受的狀況，或者失之毫釐，謬以千里。它的控制流程是Push式的，一層層往下推，如圖6.這裏只截取了其中一個部分。

圖6. Push 模式中的一個片斷

學過控制理論的人都知道一個最簡單的道理，「沒有反饋(feedback)，就沒有控制」。反饋的基本原理就是把輸出反饋給輸入，若是誤差很大，就得調整控制過程，最終使得輸出知足輸入的需求。整體上看，軟件開發的輸入是客戶，輸出是軟件產品，控制過程是軟件項目的開發過程。若是隻是一次性地把軟件產品交付給客戶，顯然就是沒有反饋。其過程是線形的： 「客戶 --> 項目實施--> 產品」這樣一個過程，風險很大，因此應該與客戶協做，多進行幾此這樣的過程，讓整個開發過程自適應化，最終交付成功得產品。如圖7.所示：

圖7. 有反饋的，自適應過程

圖7.的過程，在項目開發過程當中，就是屢次的迭代。每一個迭代過程都是具體而微的 「需求-設計-實現-測試」單調過程。正是這樣的屢次迭代，下降了最終交付產品時的風險。

讓咱們看看迭代過程，下圖：

圖8. 迭代過程示意圖

每一個迭代過程都是具體而微的「需求-設計-實現-測試」，經過這樣屢次的小步迭代，逐漸構築成一個完整的系統。如圖9.屢次的迭代，系統增量式地完善起來。

圖9. 屢次迭代，系統增量式完善起來

隨着時間的推移，每次迭代的重點又有所不一樣，圖8.中咱們能夠看出，早期迭代過程當中，需求的比重大，中期則是設計和實現的比重增大。測試是始終比較重要的環節:-)。測試從始至終地控制着質量，下降風險。下圖顯示了瀑布型測試和迭代型測試的對比。

每次迭代，完成客戶要求的優先級別高的風險大的功能點（對應到user-stories）。每次肯定user-stories的時候都容許加入新的需求，一旦肯定了下一個迭代過程要實現的user-stories列表以後，直到這個迭代過程結束，都不容許變更這個列表。順便說一下，全部user-stories的列表就是最終功能測試和驗收測試的依據。User-sotiry不一樣於user-case，簡單說，能夠將user-story當作是user-case的描述部分，便於編寫。而細節則在每次迭代的迭代設計階段細化規格，再簡單地設計，剛夠知足應用就行。複雜的設計會有不少問題哦，作集體項目，並非讓你表現代碼技巧的時候。

圖10. 迭代過程當中引入變化的整體成本走勢

每次迭代開始都歡迎加入新的需求變化，這樣，就逐步的減少了產品完成時候的風險，迭代模型對於變化的整體成本示意圖如圖10.所示。

屢次迭代的一個好處就是能更準確的估算時間。不創建原型，光是紙上談兵，很難準確的肯定項目的工期/工時和工做量(人月)。所謂原型，能夠是拋棄式或非拋棄式的，這種原型的目的除了是驗證架構性信息獲取正確以外，也能夠用來爭取客戶，得到中標的機會。更重要的是，能夠用於估算項目工做量和時間，由於就你的團隊，對這個塑造原型的前幾回迭代所完成的功能點數量，就能夠大體地推斷你的團隊的生產效率和持續前進的速度。從而把握好如何肯定項目的時間。這裏有一個圖顯示了估算項目時間的不肯定性：

圖11.初期迭代以後才能大體估算時間進度表

另外：能夠研究一下《敏捷迭代開發-管理者指南》上提到的如何簽訂兩階段合同的問題：若是我是甲方，我就會在第一階段讓準備競標的各公司給出個人需求的一個原型（能夠是草圖的），最終中標的，對這部分工做也買單。至於合同方面的事，具體的操做由市場部方面研究研究如何操做 :p）

總之，Waterfall-like Model的實施，須要經驗豐富的把關者，不管哪一個階段都是如此。（經驗和不肯定性的關係咱們能夠看圖12。）好比需求分析階段，獲取需求的能力，分析需求的能力；設計階段更是如此，甚至在整個項目成型以前，在這個設計師腦中就已經存在了一棵枝繁葉茂的項目樹，無所不包，甚至包括了哪一個枝幹的哪一個枝丫上果子的大小，顏色，成熟度以及一陣x方向的風吹來如何作運動等等細節。若是不是作過相同的項目，有具有這樣精確設計的設計師，你告訴我，我立馬去拜訪求教。更況且技術普通的一個項目團對呢？！。導師斯大林說：制定了正確的政策，就要靠黨的幹部執行下去。且不說有個無所不能的領袖人物，還要有忠貞不二的業務水準高的衆多幹部。每下一個過程都不得有異議（異議是某種反饋）地執行。類瀑布模型就是這套體制，彷佛落伍了。（團隊成員都知道我有幾個精闢的軟件工程和軟件開發的比喻，不知道你們認爲這個比喻怎麼樣 /(^o^)/，好比說爲何多重繼承麻煩且對象模型難於實做等。）

圖12. 經驗和（估算、推測性設計的）不肯定性之間的關係圖

迭代模型適合於應對變更性的，技術水平通常的，但有進取心的積極求勝的中小項目團隊。在複雜性面前強調簡單性，在質量保證方面強調反饋的重要性，在決策方面強調羣策羣力和交流，在技術難點和技術風險上強調的是勇氣。沒有價值信念，很難讓團隊成員行動起來驅除惰性。Push模式下的成員，習慣性的成了等待工做任務的「代碼員（coder）」（尤爲是項目處在審覈、需求分析、概要設計、詳細設計、文檔評審階段，coder在幹嘛？），而不是「軟件工程師」。在這個滿街都是「客戶經理」、「銷售工程師」的時代，叫一個專業學歷的人作個普通的「代碼員」，即便薪金有吸引力，職業前景也不見得明朗。有進取心的人會有動動的想法。這是合情合理的。

3. 迭代模式的幾種重要方法(以XP爲例子)蜻蜓點水一把

敏捷方法在座標圖的位置如圖13。縱座標是瀑布模型的嚴格程度；橫座標是文檔的正規程度。圖中可見UP(統一過程)是迭代模型，它有比較正式的文檔，若是你使用過UP過程，就會發現它會造成大量的文檔，圖表，UML use-case等，迭代週期可伸縮範圍較大。其實做以RUP最爲著名。

圖13.XP與其餘幾種敏捷方法的示意圖

讓咱們重點看一下XP (Extreme Programming)，是Kent Beck建立的一種增量式迭代(IID)開發方法。這種方法經過快速建立高價值的軟件、技能化和平穩的軟件開發技術以及靈活響應變化等方面來提升用戶滿意度。它主要適用於中小團隊，交付日期爲一年左右的項目。極限的意思就是把各類好的實踐發揮到極至，我在單元測試講座中提過。

文檔方面只有一些非正式的工件，例如歸總的特徵需求索引卡片，稱爲story-cards。

Xp的重要實踐(圍繞這些實踐，應該進行培訓哦:-*)：

圖14. XP的重要實踐

每一個實踐都值得去研究。對於有爭議的地方，尋求個妥協方案出來，總比沒有方案好。我就不細說了。能夠對比圖15.看一下這些實踐的實施：

圖15. Xp的反饋

這麼多的實踐，要由人督促指導實行這種方式。因此剛開始實行XP的團隊都配備一名教練。更重要的使讓你們認同這種方式。孟夫子說「無恆產者無恆心！」。斗膽小輩我加一句「人無價值信念無恆心」。一個開發團隊，一種開發模式要創建起一個信念，一種價值觀，下面是 XP的價值觀，也是XP最看重的：

• 交流

交流的重要性不言而喻，但仍然要鼓勵再鼓勵。項目組成員的天天10分鐘站立式會議，瞭解當天的任務和項目的情況。開發人員之間的即刻交流作設計和編碼等。客戶的參與與促進同客戶的溝通，其方式爲編寫驗收測試和計劃遊戲。總之，沒有交流就沒有軟件開發。意義夠大了吧。

• 簡單性

簡單性是指「作恰好夠用的事」。簡單性不只指設計的簡單，也指需求、項目管理工具等。好比說項目文檔，你三五我的的團隊，有時間維護質量上層的文檔嗎？尤爲我要說是設計文檔，重中之中是詳細設計文檔。認爲XP不用詳細設計是誤解，它在領到user-stories以後，編碼以前的時間來簡單設計。XP不排斥文檔，只不過認爲它是一種開銷，XP堅信（文檔化的）代碼是最好的文檔。並非懶不想寫文檔，是維護這個文檔要花費三倍甚至以上的時間：我在白板上畫好了商量後的草圖，要先抄下來，再寫成標準的word或openoffice文檔，碰到圖還得畫圖，UML還得再畫。因此把它簡單化：草稿，行，存檔！白板，行，拍照存檔。充足的人員和時間偷偷會給你嗎？在項目產品化階段的知識共享和培訓時再完善文檔！把存檔的草稿正式化。另外設計師總傾向於採用精巧的，複雜的設計，好象不這麼作就不是好的設計師似的；這種複雜性還給交流和理解帶來問題，更可能影響到其餘簡單設計就能夠足夠應付的地方配合你「精巧設計」要作複雜更改的問題。

• 反饋

反饋保證了質量和自適應。客戶編寫user-story-card時，程序員馬上就能夠進行評估，這樣客戶就知道工做量。測試先行有反饋，小步迭代有反饋，持續集成有反饋。項目跟蹤人員每日獲得user-sotries-list上完成狀況的跟蹤記錄反饋，客戶每一個迭代結束獲得重要反饋等。

• 勇氣

面對一堆代碼，即便你是你寫的，你敢作變更嗎，你作了變更以後有信心說不會有問題嗎？再進一步，你敢作重大的變更嗎？沒有前面的價值信念和實踐，你確定不敢說有信心。咱們的信念和實踐如今已經作了不少事：單元測試，驗收測試，持續集成，常常性的重構代碼，一致的編碼規範。有了這些保證，你跟之前相比勇氣大多了：）。勇氣除了面對激進的代碼變更，還包括探求新知。面對新技術，要保持一顆年輕的心哦！

XP的生命週期：

• 試探階段

目的：- 充分評估第一次迭代的story-cards

- 可行性保證

活動：- 創建原型（20%的需求就是最重要的基礎架構性的，前面論述過了）

- 技術等方面的試探性論證

- sotry-cards的編寫和評估

• 發佈計劃遊戲（Release Planning Game）

目的：- 對第一次迭代的日期和story-cards達成共識

活動：- 發佈計劃活動

- 故事卡片（story-cards）的編寫和評估

• 迭代計劃遊戲（Interation Planning Game）

目的：- 明確本次的迭代任務

活動：- 用戶從user stories中肯定最有價值的特徵做爲本次迭代的目標

- 加入上次迭代未經過驗收測試的user-stories

• 迭代開發

目的：- 在一個迭代週期內實現user-stories

活動：- 簡單設計、測試、結對編程、重構、迭代期驗收以及在需求細節上與客戶不斷溝通協做

• 發佈

（若是沒有完成發佈前的工做，返回到迭代計劃遊戲階段）

目的：- 產品化，發佈產品

活動：- 產品文檔、技能培訓和團隊知識共享，排除項目中的「知識孤島」現象（其實輪換配對減小了知識孤島的存在，知識孤島讓開發人員都不知道軟件其餘部分，這對維護期是個災難）

- 發佈產品

• 維護期

（略）

XP的工件、角色和實踐：

工件（沒有文檔，除了軟件，項目產生了其餘什麼嗎？）

1）story-cards - 記錄簡明特徵需求（非use-case和場景）的紙質卡片，預示着須要進一步與客戶討論具體細節，粒度2-10天。XP是特徵驅動不是用例驅動。

2）任務列表 – 每次迭代中針對story編寫的任務列表卡片或白板上的表格，任務粒度1-2天。

3）可視化圖表 - 用於便於溝通。

角色

客戶

- 編寫故事(stories)和驗收測試

- 挑選用於發佈和迭代的故事

開發-程序員

- 編寫測試、設計、和代碼

- 重構

- 肯定、領取任務和估算

開發-測試員

- 幫助客戶編寫和開發測試

管理-教練（有經驗的XP團隊可不設置）

- 過程輔導

- 過程定製

- 干預和培訓

管理-項目跟蹤者

- 收集度量狀況

- 報告進度

- 根據簡單的估算進行反饋

其餘-顧問等

- 技術諮詢和指導

實踐

對應到需求：（誰說XP不作需求，並且是持續獲取需求！）

- 計劃遊戲

- 現場客戶

- 驗收測試

設計：

- 系統隱喻

- 頻繁重構

- 簡單設計

實現：

- 頻繁重構

- 編碼標準（一致的風格、文檔化(如doxygen）註釋，這能夠是最好的設計和實現文檔）

- 結對編程

- 代碼的全部權歸團隊

測試和驗證：

- 驗收測試，客戶測試

- 測試先行的開發單元測試

- 現場客戶

項目管理：

- 計劃遊戲

- 小版本發佈

- 平穩的工做進度

- 站立短期會議

配置並改變管理環境：

- 持續繼承

- 公用房間

- 計劃遊戲

核心實踐和描述：（摘自Craig Larman Agile and Iterative Development: A Manager's Guide）

不翻譯，看點原味的吧。

實踐	描述
整個團隊協同工做，或者現場客戶參與	The whole team—programmers and customers—work together in a common project room. One or more customers sit more-or-less full time with the team; they are expected to be subject matter experts and empowered to make decisions regarding requirements and their priority. The customer contribution includes detailed explanation—to the programmers—of the features briefly summarized on story cards, Planning Game participation, clarification, and writing acceptance tests in collaboration with a programmer. The purpose is in response to the consistent project failure research indicating that more customer involvement is paramount to successful projects. The first release of XP spoke of only one onsite customer; this has been recently revised to emphasize a group of customers.
小型而頻繁地發佈	Evolutionary delivery. Not applicable to all projects. Not to be confused with organizing one release cycle into many short iterations.
測試: 驗收測試和客戶測試	Testing practices in XP are very important. All features must have automated acceptance (functional) tests. All tests (acceptance and unit) must run with a binary pass/fail result, so that no human inspection of individual test results is required. The acceptance tests are written with collaboration of the customer—they define a testable statement of what acceptance means. This is called Customer Tests in XP.
測試: 測試驅動開發和客戶測試	Unit tests are written for most code, and the practice of test-driven development (and test-first development) is followed. This includes the practice that the unit test is written by the programmer before the code to be tested. It is a cycle of test Õ code, rather than code Õ test. Usually, the open-source XUnit testing framework family (such as JUnit) is applied (see
發佈計劃遊戲	The Release Planning Game goal is to define the scope of the next operational release, with maximum value (to the customer) software. Typically a half-day one-day session, customer(s) write story cards to describe features, and developers estimate them. There may also exist story cards from prior exploration phase work. The customer then chooses what's in the next release by either 1) setting a date and adding cards until the estimate total matches the time available, or 2) choosing the cards and calculating the release date based on their estimates.
迭代計劃遊戲	The Iteration Planning Game goal is to choose the stories to implement, and plan and allocate tasks for the iteration. It happens shortly before each new iteration (1–3 weeks in length). Customer(s) choose the story cards for the iteration. For each, programmers create a task list (on cards or whiteboard) that fulfill the stories. This is followed by a volunteering step in which the programmers choose a set of tasks. They then estimate their task lengths. If tasks are not estimated in the half-day to two-day range, they are refactored.
簡單設計	Avoid speculative design for possible future changes. Avoid creating generalized components that are not immediately required. The design should avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible.
結對編程	All production code is created by two programmers at one computer; they rotate using the input devices periodically. Pairs may change frequently, for different tasks. The observer is doing a real-time code review, and perhaps thinking more broadly than the typist, considering tests and so forth. Certainly, team productivity is not simply a function of the number of hands typing—it is more nuanced. The XP claim is that the combination of cross learning, the peer pressure of more disciplined practice observance and more hours actually programming than procrastinating, defect reduction due to real-time code review, and the stamina and insight to carry on when one programmer is stuck, all add up to an overall team improvement.
頻繁重構	Refactoring in the XP context is the continual effort to simplify the fine-grained code and larger design elements, while still ensuring all tests pass. That is, cleaning the code and design, without changing functionality. There is supposed to be "lots" of refactoring in XP. This practice is also known as continuous design improvement. The goal is minimal, simple, comprehensible code. It is achieved by small change steps, verifying tests after each, and ideally the use of refactoring tools, now available in some IDEs.
代碼歸集體全部	Any pair of programmers can improve any code, and the XP value system is that the entire team is collectively responsible for all the code. The value of "it's her code, and her problem" is not endorsed; rather, if a problem or chance to improve is spotted, it's the spotter's responsibility. A related goal is faster development by removing the bottleneck associated with change requests in an individual code ownership model. The obvious danger of modifying code one did not originally write is ameliorated in XP by some of the other practices: The guaranteed-present unit and acceptance tests running within an automated continuous integration build process inform you if you broke the code, your pairing partner brings another set of eyes to the change, and common adherence to coding standards ensures all the code looks the same.
持續集成	All checked-in code is continuously re-integrated and tested on a separate build machine, in an automated 24/7 process loop of compiling, running all unit tests and all or most acceptance tests. There are several open-source tools for this, built on the ubiquitous Ant technology, including CruiseControl and Anthill.
平穩的工做節奏	Frequent overtime is rightly considered a symptom of deeper problems, and doesn't lead to happy, creative developers, healthy families, or quality, maintainable code. XP doesn't support it—rather, it promotes "no overtime."
站立會議	With collective code ownership, frequent refactoring, and regular swapping of pair programming partners, everyone needs to follow the same coding style.
系統隱喻	To aid design communication, capture the overall system or each subsystem with memorable metaphors to describe the key architectural themes. For example, the C3 payroll system was described in terms of an assembly line of checks with posting rule "machines" operating on them, extracting money from different "bins." Many have reported this the least necessary practice.

其餘實踐和價值觀：

• 現場客戶代理— Many groups wishing to apply XP cannot find full-time "ultimate" customers to work in the project room. For example, consider a new internal system for (very busy) commodity traders. And this problem is common for commercial products for an external market. The common solution is to designate customer proxies that do join the team in the project room, have good (though not as ideal as true customer) knowledge of the domain and requirements, and that represent the ultimate customers. If proxies are used, it is important that the true customers at least participate in end-of-iteration demos, and preferably, in the Planning Games.
• 隨時聯絡客戶— When the onsite customer is not present, arrange matters so that the customer representative is committed to fast access, such as via a mobile phone.
• 擁抱變化— The overarching attitude that XP promotes is to embrace rather than fight change, in the requirements, design, and code, and be able to move quickly in response to change.
• 徹底自願地 (接受任務)— Tasks are not assigned to people. Rather, during the Iteration Planning Game, people choose or volunteer for tasks. This leads to a higher degree of commitment and satisfaction in the self-accepted responsibility, as has been explored in [DL99].
• 很是輕量級地建模— XP encourages programming very early and does take to "extreme" the avoidance of up-front design work. Any more than 10 or 20 minutes of design thinking (e.g., at the whiteboard with sketches or notes) before programming is considered excessive. Contrast this with Scrum or the UP, for example, where a half-day of design thought near the start of an iteration is acceptable.
• 最少或「剛剛夠的文檔」— With the goal of getting to code fast, XP discourages writing unnecessary requirements, design, or management documents. The use of small paper index cards is preferred for jotting brief descriptions, as are verbal communication and elaboration. Note that the practice of "avoiding documentation" is compensated by the presence of an onsite customer. XP is not anti-documentation, but notes it has a cost, perhaps better spent on programming.
• 度量— XP recommends daily measurement of progress and quality. It doesn't mandate the exact metrics, but to "use the simplest ones that could work." Examples include numbers of completed tasks and stories, and number and success rate of running tests.
• 牆壁圖表— The collected metrics are daily updated on wall graphs for all to easily see.
• 跟蹤和每日跟蹤者— The regular collection of task and story progress metrics is the responsibility of a tracker. This is done with a walk-about to all the programmers, rather than email; commenting on this—and very telling of the XP attitude—Ron Jeffries (one of the XP founders) said, "XP is about people, not computers." Test metrics can be automatically collected by software.
• 遞增的基礎結構— XP recommends (as do the other iterative processes) that the back-end infrastructure (for example, a persistence layer) not be the main focus of implementation in the early iterations, but rather, only enough is implemented to satisfy the user-functional requirements of each iteration.
• 公用項目工做室— XP projects are run in a common project room rather than separate offices. Pair programming tables are in the center of the room, and the walls are clear for whiteboard and poster work. Of course, people may have a private space for private time, but production software development is a team sport in XP.
• 每日站立會議— As in Scrum, there is a daily short stand-up (to keep it short) meeting of status.
• 理想工程小時(IEH)— Task estimates—and possibly story estimates—are done in terms of IEH, or uninterrupted, dedicated, focused time to complete a task.
• 故事評估— To estimate larger stories, some XP practitioners recommend using only coarse values of one, two, or three week durations rather than IEH or day-level estimates.

文字太多了，仍是看些圖表吧，一切盡在不言中！

圖16.是極限編程項目過程總覽

圖16. Xp項目總覽

下圖是XP迭代過程。

圖17. XP的Iteration

下圖是XP的開發圖

圖18. XP的Deveopment圖

下圖是XP的集體代碼全部圖，其實講的是如何合做開發。

圖19. XP的集體代碼全部圖

4. 咱們的方向和要重點研究的幾個問題

首先明確的是類瀑布模型確定不適合軟件開發。XP也不是黑客的編寫邊改方式。借鑑迭代模型和敏捷開發方法勢在必行，而且在過去的項目上曾經使用過所有或者部分重要方法和實踐(我所知道的是Swork Cao & Robin Qiu的項目上)。其實分解開來，這些重要實踐是每一個方法或多或少都包含的。

明確了敏捷軟件開發的方向，就要對其中幾個地方進行探究和學習，好比如何開展商務談判、合同簽訂；如何讓客戶或其代理加入開發團隊或者隨需能夠及時交流；如何作發佈計劃遊戲；如何作迭代計劃遊戲；如何進行短期的站立會議；如何進行簡單設計；測試驅動和編碼以及重構(Refactoring)；如何進行自動化的單元測試和持續集成；驗收測試，以及產品化過程學習和知識共享。

總的來講，在這樣的團隊中，項目成員可以獲得鍛鍊和知識積累，而不象在Push模式下單純接受任務的coder這樣一個枯燥，缺少交流和自信，缺少勇氣和疲於應付Bugs的局面。從而能夠進入到一種積極向上的，心情輕鬆的，良好交流的、具合做氛圍的、不斷克服困難後獲得成就感的良好循環。

軟件開發中有苦悶也有快樂。個人一個同時曾經獨自一我的對付一個子項目，三個月悶頭幹活，至見到計算機就要吐的地步，毫無樂趣，枯燥乏味，項目也沒怎麼完成好。身爲程序員的咱們要會找點樂子自娛自樂。好比Sunwah最合格的程序員Daniel Cao就play violin，過去是驢叫，如今應該有旋律了吧？！。

5. XP的場景和樣板

XP有樣板工程，但我沒去進一步查看能得到那些信息。

我沒能蒐集到更多的圖，下面是一些，還有一個重要連接，你們務必看一下，若是所有複製過來，篇幅太大了。

開發現場，圖20.所示。看過Microsoft的一個廣告的人都知道，會議室的牆壁上，走道甚至室玻璃窗上都畫滿了各類圖表。這個圖沒Microsoft的誇張。

圖20. 常見的開發現場，空出全部的牆面備用

站立會議，圖21所示。其實咱們也是這麼開會的：）坐着開會容易跑題，時間也很差控制，站着，時間一長就累，都想着散會。

圖21. 每日10分鐘的站立會議

篇幅太大了，看個重要的連接

XP Team Room (http://www.scissor.com/resources/teamroom/)，我給出一張圖，引發你們的興趣先！

圖22. XP團隊工做室一角

6.附錄

敏捷軟件開發宣言

• 個體和交互賽過過程和工具
• 能夠工做的軟件賽過面面俱到的文檔
• 客戶合做賽過合同談判
• 響應變化賽過遵循計劃

也就是說，雖然也具備價值，但咱們認爲左邊的項具備更大的價值。

敏捷軟件開發的原則咱們遵循如下的原則:

1）咱們最早要作的是經過儘早地、持續地交付有價值的軟件來使客戶滿意。

2）即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點。

3）常常性地交付能夠工做的軟件，交付的間隔能夠從幾個星期到幾個月，交付的時間間隔越短越好。

4）在整個項目開發期間，業務人員和開發人員必須每天都在一塊兒工做。

5）圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，而且信任他們可以完成工做。

6）在團隊內部以及團隊之間，最有效果而且最富有效率的傳遞信息的方式，就是面對面的交談。

7）能夠工做的軟件是首要的進度度量標準。

8）敏捷過程提倡平穩的開發。

9）發起人、開發者和用戶應該可以保持一個長期的、恆定的開發速度。

10）不斷地關注優秀的技能和好的設計會加強敏捷的能力。

11）簡單——使未完成的工做最大化的藝術——是根本的。

12）最好的架構、需求和設計出自於自我組織的團隊。

13）每隔必定的時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地調整本身的行爲。

7.參考資料

Craig Larman - Agile and Iterative Development: A Manager's Guide
Auer, K., and Miller, R. 2002. - Extreme Programming Applied: Playing to Win. Addison-Wesley. Kent Beck, Cynthia Andres - Extreme Programming Explained: Embrace Change, Second Edition Ambler, S. 2002. - Agile Modeling, John Wiley & Sons Larman, C. 2001. - Applying UML and Patterns: An Introduction to OOA/D and the Unified Process, 2nd edition. Mike Cohn - User Stories Applied for Agile Software Development Ivar Jacobson, Grady Booch, and James Rumbaugh, Rational Software - The Unified Process http://www.extremeprogramming.org http://www.xprogramming.com Paul Hamill - Unit Test Frameworks David Astels - Test-Driven Development: A Practical Guide Martin Fowler - Refactoring: Improving the Design of Existing Code Robert C. Martin - Agile software Development: Principles, Patterns, and Practices

8.後記

原本只想寫個關於瀑布模型和迭代模型對比的文章，後來以爲既然有相關的資料能夠引用，仍是多介紹一些敏捷軟件軟件開發和極限編程方面的內容，敏捷方法中我我的比較欣賞XP的作法，因此不少部分都是XP方面的內容。

寫文檔很花時間，我也沒有工夫認真地一一重畫圖表，因而就複製過來。以爲還有許多地方能夠作得更好，還有不少地方能夠而且須要擴展開來。現階段，咱們的現狀是要把文檔篇幅擴展；你們熟悉了這些過程以後，就能夠提綱挈領，作到綱舉目張的效果。也就是把文檔變薄。

一句話：

擁有一個複雜的思想比較容易。

擁有一個簡單的思想難上加難。

—— Carver Mead