敏捷開發（agile development）是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。簡言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

        敏捷開發是全新理論嗎？答案莫衷一是。細心的人們可以發現，敏捷開發其實借鑑了大量軟體工程中的方法。迭代與增量開發，這兩種在任何一本軟體工程教材中都會被提到的方法，在敏捷開發模式中扮演了很重要的角色。再向前追溯，我們還也可見到瀑布式與快速原型法的影子，也許還有更多。

        改善，而非創新。敏捷開發可理解為在原有軟體開發方法基礎上的整合——取其精華，去其糟粕。因此敏捷開發繼承了不少原有方法的優勢。“在敏捷軟體開發的過程中，我們每兩週都會得到一個可以工作的軟體，”Fowler介紹，“這種非常短的迴圈，使終端客戶可以及時、快速地看到他們花錢構建的軟體是一個什麼樣的結果。”

        也許是因為時間關係，Fowler只說出了這些優勢中的一部分。允許開發過程中的需求變化、通過早期迭代可以較早發現風險、使程式碼重用變得可行、減少專案返工……借鑑了眾多先進方法和豐富經驗，擁有的眾多優勢使得敏捷開發看來已經成為解決軟體危機的標準答案。

        問題與思考

        然而，我們不得不面對的現實卻是，模式與方法的優化並不意味著問題的終結。作為一種開發模式，敏捷開發同樣需要面對眾多挑戰。

        大專案的拆分意味著更多子專案的出現，協調這些同步或非同步推進的子專案，合理的資源調配都將變得更加複雜。另外，在當前專案和專案組普遍“增容”的情況下，遇到的問題同樣成倍增長。人的重要性被提到了更高的高度，而缺乏有效協調手段，減少人員流動和專案變更對整個專案造成的影響也將成為一大挑戰……新方法帶來眾多便利的同時，也相應引發了幾乎同樣多的問題。

        敏捷開發（agile development）概念從2004年初開始廣為流行。Bailar非常支援這一理論，他採取了"敏捷方式"組建團隊：Capital One的"敏捷團隊"包括3名業務人員、兩名操作人員和5～7名IT人員，其中包括1個業務資訊指導（實際上是業務部門和IT部門之間的"翻譯者"）；另外，還有一個由專案經理和至少80名開發人員組成的團隊。這些開發人員都曾被Bailar送去參加過"敏捷開發"的培訓，具備相關的技能。

        每個團隊都有自己的敏捷指導（Bailar聘用了20個敏捷指導），他的工作是關注流程並提供建議和支援。最初提出的需求被歸納成一個目標、一堆記錄詳細需要的卡片及一些供參考的原型和模板。在整個專案階段，團隊人員密切合作，開發有規律地停頓--在9周開發過程中停頓3～4次，以評估過程及決定需求變更是否必要。在Capital One，大的IT專案會被拆分成多個子專案，安排給各"敏捷團隊"，這種方式在"敏捷開發"中叫"蜂巢式（swarming）"，所有過程由一名專案經理控制。

        為了檢驗這個系統的效果，Bailar將專案拆分，從舊的"瀑布式"開發轉變為"並列式"開發，形成了"敏捷開發"所倡導的精幹而靈活的開發團隊，並將開發階段分成30天一個週期，進行"衝刺"--每個衝刺始於一個啟動會議，到下個衝刺前結束。

        在Bailar將其與傳統的開發方式做了對比後，他感到非常興奮--"敏捷開發"使開發時間減少了30%～40%，有時甚至接近50%，提高了交付產品的質量。"不過，有些需求不能用敏捷開發來處理。" Bailar承認，"敏捷開發"也有侷限性，比如對那些不明確、優先權不清楚的需求或處於"較快、較便宜、較優"的三角架構中卻不能排列出三者優先順序的需求。此外，他覺得大型專案或有特殊規則的需求的專案，更適宜採用傳統的開發方式。儘管描述需求一直是件困難的事，但經過陣痛之後，需求處理流程會讓CIO受益匪淺。

        敏捷開發是由一些業界專家針對一些企業現狀提出了一些讓軟體開發團隊具有快速工作、響應變化能力的價值觀和原則，並於2001初成立了敏捷聯盟。他們正在通過親身實踐以及幫助他人實踐，揭示更好的軟體開發方法。通過這項工作，他們認為：

•個體和互動勝過 過程和工具

•可以工作的軟體勝過 面面俱到的文件

•客戶合作勝過 合同談判

•響應變化勝過 遵循計劃

並提出了以下遵循的原則：

•我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。

•即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。

•經常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。

•在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。

•圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。

•在團隊內部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。

•工作的軟體是首要的進度度量標準。

•敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度。

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

•簡單是最根本的。

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

•每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

一、敏捷開發方法

（一）說明

本文是閱讀Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些筆記和想法，AgileSoftware Development是一組軟體開發方法的總稱，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷開發方法又稱為“輕量級”開發方法。

下面這段話摘自Martin Fowler的一篇文章：

從無到繁重再到敏捷

        多數軟體開發仍然是一個顯得混亂的活動，即典型的“邊寫邊改”（code and fix）。設計過程充斥著短期的，即時的決定，而無完整的規劃。這種模式對小系統開發其實很管用，但是當系統變得越大越複雜時，要想加入新的功能就越來越困難。同時錯誤故障越來越多，越來越難於排除。一個典型的標誌就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期之感，從而對專案的完成產生嚴重的影響。

        我們使用這種開發模式已有很長時間了，不過我們實際上也有另外一種選擇，那就是“正規方法”（methodology）。這些方法對開發過程有著嚴格而詳盡的規定，以期使軟體開發更有可預設性並提高效率，這種思路是借鑑了其他工程領域的實踐。

        這些正規方法已存在了很長時間了，但是並沒有取得令人矚目的成功，甚至就沒怎麼引起人們的注意。對這些方法最常聽見的批評就是它們的官僚繁瑣，要是按照它的要求來，那有做太多的事情需要做，而延緩整個開發程序。所以它們通常被認為是“繁瑣滯重型”方法，或Jim HighSmith 所稱的“巨型”（monumental)方法。

        作為對這些方法的反叛，在過去幾年中出現了一類新方法。儘管它們還沒有正式的名稱，但是一般被稱為“敏捷型”方法。對許多人來說，這類方法的吸引之處在於對繁文縟節的官僚過程的反叛。它們在無過程和過於繁瑣的過程中達到了一種平衡，使得能以不多的步驟過程獲取較滿意的結果。

        敏捷型與滯重型方法有一些顯著的區別。其中一個顯而易見的不同反映在文件上。敏捷型不是很面向文件，對於一項任務，它們通常只要求儘可能少的文件。從許多方面來看，它們更象是“面向原始碼”（code-oriented）。事實上，它們認為最根本的文件應該是原始碼。

        但是，我並不以為文件方面的特點是敏捷型方法的根本之點。文件減少僅僅是個表象，它其實反映的是更深層的特點：

        敏捷型方法是“適配性”而非“預設性”。 重型方法試圖對一個軟體開發專案在很長的時間跨度內作出詳細的計劃，然後依計劃進行開發。這類方法在計劃制定完成後拒絕變化。而敏捷型方法則歡迎變化。其實，它們的目的就是成為適應變化的過程，甚至能允許改變自身來適應變化。

        敏捷型方法是“面向人”的(people-oriented)而非“面向過程”的 (process-oriented)。它們試圖使軟體開發工作順應人的天性而非逆之。它們強調軟體開發應當是一項愉快的活動。

        我認為以上兩個特點很好的概括了敏捷開發方法的核心思想：適應變化和以人為中心

（二）方法背後的思想

Alistair Cockburn在AgileSoftware Development中講述了敏捷開發方法背後的思想

        人們掌握過程（process）可以分為3個階段：

1 following 遵循一個定義好的process

2 detaching 知道不同process的適用範圍，在不同的場合使用不同的process

3 fluent 不關心是否遵循特定的process，知道在什麼情況下采用什麼動作

        軟體開發是一個充滿發明和交流的協作性遊戲 (cooperative game of invertion and communication)。軟體開發的首要目標是生產出軟體，遵循特定的過程和模型只是手段，只要傳遞了足夠的資訊，手段是次要的。交流的效果要遠遠重於交流的形式（Effect of communication is more important than the form ofcommunication）。

一般軟體開發有兩個目標：1 儘快的生產出軟體2 為下一個team或專案做準備，有時這兩個目標是矛盾的，我們要在這兩個目標之間尋求平衡

        在軟體開發中，人的因素要遠遠大於過程和技術。人是有缺陷的：

1 容易犯錯誤，因此必須在錯誤擴散之前找到並改正錯誤

2 當覺得可能失去較多的時候，不願意冒險

3 重新構造而不願意重複使用已有的東西

4 難於堅持一個習慣

       針對個人因素的幾個建議：

1 具體的模型較抽象的模型更容易理解

2 從一個例子開始是容易的

3 通過觀察他人的成果學習

4 要有足夠的不受打擾的時間

5 分配的工作要與個人意向，能力匹配

6 不正確的獎勵會有壞作用，從長期看個人興趣比獎勵更重要，培養在工作中的自豪感：

1) pride in work參與工作的自豪感，通常參與一個重要的工作會有自豪感

2) pride in accomplishment 完成工作的自豪感，長期未完的工作會使士氣低落

3)pride in contribution 為他人貢獻的自豪感

7 鼓勵關心其他人的工作和整體的工作

        在一個團隊之間，交流是最重要的，實踐證明面對面的實時的交流是最有效的，對交流的延誤會損失資訊，白板是最好的交流工具，交流工具的先進並不能提高交流效果。文件的作用是記錄和備忘，不能通過文件交流。

       敏捷開發方法要避免的過程設計的幾個常見錯誤

1 對所有的專案使用同一種過程

2 沒有彈性

3 過於沉重

4 增加不必要的“必須完成”（“shoulddo” is really should？）

5 沒有經過實踐檢驗

        敏捷開發方法過程設計的幾個原理：

1 互動的面對面的交流是代價最小，最迅速的交換資訊的方法

2 超過實際需要的過程是浪費的

3 大的團隊需要重量級方法

4 處理重大問題的專案需要重量級方法強調

5 增加反饋和交流可以減少中間產品和文件的需求

6 輕量級方法更強調理解（understanding）,自律（discipline）和技能(skill)，重量級方法更強調文件（documentation），過程（process）和正式（formality）

understanding指整個團隊關於專案的全部知識，包括討論的過程，documentation只能記錄其中的一部分

discipline是指個人主動的完成工作，process指個人根據指令完成工作

skill指具有良好技能的人可以省略中間的產品，formality指必須按照規定步驟完成工作

7 確定開發中間的瓶徑，提高它的效率

對於瓶徑處的工作應該儘量加快，減少重複，（使用更熟練的人，使用更多的人，使用更好的工具，使瓶徑處的工作的深入儘量穩定）對於非瓶徑處的工作可以多一些重複，在輸入還不確定的情況下也可以儘早開始。

        這些原理的幾個結論：

1 向一個專案增加人員要花費較大代價（constly），因為原有人員和新人員之間的交流要花費大量時間

2 團隊的規模經常是跳躍的，例子：需要6個熟練的程式設計師，但是隻有4個，於是增加不熟練的程式設計師，結果團隊的大量時間花費在培訓不熟練的程式設計師上面，最後增加到了20個不熟練的程式設計師。

3 應該側重於提高團隊的技能而不是擴充團隊

4 對不同的專案使用不同的過程

5 在適用的條件下，輕量級的方法優於重量級的方法

6 對不同的專案要裁減過程

敏捷開發方法的原則是“剛剛好”（Light and Sufficient）

（三） Crystal

Crystal是Alistair Cockburn提出的一組開發方法，分為CrystalClear,Crystal Yellow, Crystal Orange和Crystal Red分別適用於不同的專案。專案可以按照參加的人員和重要性劃分。重要性根據專案中的錯誤引發的後果分為：

C Loss of comfort （某些不舒適）

D Loss of discretionary money (經濟損失)

E Loss of Essential Money (嚴重經濟損失)

L Life Critical (生命危險)

一個專案稱為C6說明參加人員在6人以下，重要性是C級，D20說明人員在6-20人，重要性是D級。

Crystal Clear適用於 C6,D6專案

Crystal Yellow適用於C20,D20,E20專案

Crystal Orange 適用於C40,D40,E40專案

Crystal Red 適用於 C80,D80,E80專案

Crystal Clear

適用於一個辦公室內的一個小組

角色有： sponsor發起人，任務下達者

Senior Designer-Programmer 高階設計開發人員

Designer-Programmer 設計開發人員

User 使用者

其中一個人是專案協調者(Project Coordinator)。Senior Designer-Programmer是關鍵人員

策略：

1 軟體的開發採用有規則的週期性遞增方法，每2-3個月提交（deliver）一個版本

2 使用里程碑(milestone)跟蹤進度（包括delvier和開發期間的重大決定）

3 自動迴歸測試（automatedregression test）

4 使用者直接參與

5 每個release有兩個userviewings(使用者稽核?)

6 在上一個步驟足夠穩定（stableenough to review）時立即開始下一個步驟，儘量並行開發

7 在每個週期的開始和中間進行產品和過程調整

過程產品（指整個過程產生的所有產品，包括軟體和文件）

1 軟體釋放順序（releasesequence）

2 使用者稽核的計劃

3 使用者案例（usecase）或需求描述

4 設計框架和必要的說明

5 介面草圖

6 基本的物件模型

7 執行程式碼

8 migration code

9 測試用例

10 使用者手冊

11 local matters有專案組決定：

上述product的摸班

編碼和使用者介面的標準

迴歸測試的標準和細節

其他文件

需要的工具：

版本控制工具

白板（最好可列印）

Crystal Orange

角色：sponsor 發起人

business export/usage export 業務專家

technical facilitator 技術專家

business analyst/designer 業務分析和設計人員

project manager 專案管理員

architect 系統架構人員

Design Mentor 設計指導人員

Lead Designer-Programmer 主要設計編碼人員、

Other Designer-Programmer設計編碼人員

UI Designer 使用者介面設計人員

Writer 文件寫作人員

Tester 測試人員

策略：

同Crystal Clear (週期可以為3-4個月)

過程產品：

需求文件

計劃

狀態報告

使用者介面設計文件

基本物件模型

外部介面標準

使用者手冊

原始碼

測試用例

migration code

local matters 同CrystalClear

（四） The Agile Alliance

敏捷聯盟是17位不同敏捷開發方法的提倡者共同成立的，目的是推進敏捷開發方法的研究和應用，他們並不要求強制使用某種開發方法，而是提出了敏捷開發的幾個核心價值和基本原則：

core value:

Individuals and interactions over processesand tools

個人和交流重於過程和工具

Working software over comprehensivedocumentation

正在執行的軟體本身重於複雜的文件

Customer collaboration over contractnegotiation

與客戶的溝通和交流重於使用合同約束客戶

Responding to change over following a plan

對變化的快速響應重於跟隨計劃

principles

1 最高目標是通過快速的和經常的釋出軟體滿足客戶的需要

2 提交軟體的週期為幾個星期到幾個月

3 產生正確的軟體是衡量進度的首要標準

4 主動接受需求的改變而不是拒絕

5 商務人員和開發人員工作在一起

6 個人必須有動力，要創造環境支援他們的要求，信任他們

7 最有效的交流方法是面對面的交流

8 最好的結構，需求和設計來自於自組織的團隊（self-organizingteam），允許任何人提出想法和建議

9 持續改進設計和編碼

10 鼓勵正常工作，減少長時間加班

11 保持簡單，減少不必要的部分，認識到簡單的設計比複雜的設計更難（simple design is harder to produce）

12 定期調整過程，獲得更高效率

（五） Extreme Programming

        Extreme Programming（XP，極限程式設計） 是一種輕量級的軟體開發方法，它使用快速的反饋，大量而迅速的交流，經過保證的測試來最大限度的滿足使用者的需求。XP強呼叫戶滿意，開發人員可以對需求的變化作出快速的反應。XP強調team work。專案管理者，使用者，開發人員都處於同一個專案中，他們之間的關係不是對立的，而是互相協作的，具有共同的目標：提交正確的軟體。XP強調4個因素：

交流(communication)，XP要求程式設計師之間以及和使用者之間有大量而迅速的交流

簡單（simplicity），XP要求設計和實現簡單和乾淨

反饋（feedback）通過測試得到反饋，儘快提交軟體並根據反饋修改

勇氣（courage）。勇敢的面對需求和技術上的變化

XP特別適用於需求經常改變的領域，客戶可能並系統的功能並沒有清晰的認識，可能系統的需求經常需要變動。

XP也適用於風險比較高的專案，當開發人員面對一個新的領域或技術時，XP可以幫助減低風險

XP適用於小的專案（人員上），人員在2-12人之間，XP不適用於人員太多的專案，事實上，在需求經常變化或風險比較高的專案中，少量而有效的XP開發人員效率要遠遠高於大量的開發人員。

下面是XP的開發流程

XP的原則和實踐：

1 Planning:

1)user stories。

User stories類似use case， 描述使用者所見的系統功能，但避免使用大量的文件，user stories由使用者編寫（不僅限於描述使用者介面）。User stories使用使用者的語言編寫，不使用技術性的語言，每個user stories限於幾句話。User stories用於在release plan會議上對開發時間進行評估，也用於產生驗收測試（acceptance test），必須使用可以自動進行的驗收測試保證軟體的正確性。User stories與傳統的使用者需求的區別在於詳細的程度，user stories並不會確定需求的每個細節，它只是用來簡單的描述系統功能，供開發人員進行估計開發進度，在開發過程中開發人員和使用者會不斷的交流以討論細節問題。User story應該專注於功能，不應該過分注重使用者介面等細節。一般一個user storiy在1-3周的時間完成，如果估計超過3周，說明user story太大了，需要細分。

2)release plan.

召開一個 release plan會議，產生release plan。Release plan將用於指定每個iteration的計劃。開發人員對每個user story估計開發時間（在不被打斷，無其他工作情況下的開發時間，包括測試），使用者對user stories給出優先順序，release plan會議並不制訂每個iteration的計劃。Release plan要使用者，開發人員和管理者都同意，在完成功能範圍（scope），使用資源（resource）,時間（time）和質量(quality)上達成一致（一般質量是不能改變的）

3) small release

often and small release是XP的一個原則，每個release完成一些使用者有意義的功能集合，儘快的提交給使用者以獲得反饋，及時調整，提交的越晚，調整越困難。

4）project velocity

團隊在開發過程中要收集資料，以便於對自己的開發速度進行評估，用於以後的releazse plan

5)iteration

每個small release的週期稱為iteration，每個iteration約為1-3周，在一個專案中保持每個iteration的時間相等，不要超前制定計劃，每個iteration的計劃在iteration的開始時制定。這樣能夠更靈活的應付變化。不要急於完成本次iteration沒有包括的功能。要注重每個iteration的時間限制，當團隊覺得不能按時完成iteration時，召開一次iteration plan會議，重新評估，減少一些user stories。

下面是iteration的圖示：

6）iteration plan

在每個 iteration開始的時候召開會議，從release plan中選擇還沒有實現的使用者最迫切需要的user stories。上一個iteration中沒有通過驗收測試的功能也要在這個iteration中實現。可以根據上一個iteration的實踐調整團隊速度。User stories和失敗的測試被分解成programming task，task使用技術語言編寫，作為iteration plan的詳細描述。程式設計師主動領取task並估計完成時間，每個task應該在1-3天內完成，超過3天的task應該被細分。如果整個團隊需要的時間多於或少於規定的iteration時間，調整user stories。

7）move people around

不要使每個開發人員侷限於一項工作，不要使某項工作依賴於一個開發人員，增加知識共享，減少資訊孤島，多進行交流和培訓。當專案中的所有人對所有模組都瞭解並可以進行開發時是效率最高的，鼓勵開發人員在不同iteration中開發不同的模組。

8) stand-up meeting

每天工作開始之前，開5-10分鐘的stand-up會議（站立會議），站立的目的是為了強迫節省時間，會議的目的是交流，提出存在的問題，但不要在會議上解決問題。開一個所有人員參加的短會比多個個別人員參加的會議要高效。在會議上提出的問題可以由少數人討論解決，這個少數人蔘加的會議如果涉及到程式碼，可以在計算機前討論。

9) fix XP when it breaks

XP並不是一成不變的，當團隊覺得需要修改的時候，可以根據自己的情況進行修改，任何修改都要經過整個團隊的討論和達成一致

2 Designing

1) Simplicity

保持簡單的設計，在完成同樣的功能的情況下，選擇簡單的設計，不要急於設計沒有計劃的功能，應該認識到：keeping a design simple is hard work

2）system metaphor

使用統一的術語描述系統，在使用者，管理者和開發人員之間使用統一的術語。這將使交流清晰。

3）CRC card

使用CRC(Class, Responsibilities, and Collaboration) card進行系統設計，鼓勵更多的人蔘加設計。每個CRC卡片表示系統中一個物件，寫上物件的名字，責任和每個責任需要互動的其他物件。可以模擬物件之間的互動。CRC卡片是易於理解的，但是是非正式的，如果需要正式的文件，要將卡片轉換為相應的文件。

4) spike solution

使用spike solution減低風險，當遇到技術難題或設計問題時，使用簡單的程式進行測試，找出問題，在不同的解決方法之間進行評估。在早期進行實驗可以有效的降低風險。

5）never add functionearly

不要過早的設計沒有計劃的功能，在一個需求經常變化的環境中，過早的設計經常是沒有用的。

6）refactoringwheneverand wherever

XP鼓勵對設計和程式碼經常進行重構（Refactoring），目的是去除冗餘，提高質量，保持設計簡單。重構必須以完全測試為檢驗條件

3 Coding

1) customer is alaways available

使用者是專案組的成員之一，使用者的參加貫穿整個開發過程，使用者與開發人員之間的交流是重要的

2) coding standard

使用統一的編碼標準，這是保持程式碼整潔和共享程式碼的基礎

3）coding unit testfirst

test first是XP的一個特點，在編寫程式碼之前先編寫單元測試程式碼，單元測試程式碼和程式碼由同一個程式設計師完成。先編寫測試程式碼可以使程式設計師更好的理解需求，避免直接編碼造成的理解偏差，對需求的不清晰，可以在編寫測試程式碼時就發現。測試程式碼也是檢驗程式是否完成的標準。編碼工作應該是以下工作的迴圈：

1 編寫測試程式碼

2 執行測試程式，確認失敗

3 編寫實現這個測試程式要求功能的程式碼，不需要實現其他的功能，只需要實現剛剛滿足測試程式的功能

4 執行測試程式，確認成功

實踐證明，test first方式需要的編碼實踐少於先編碼，後寫測試程式碼

4) Pair Programming

Pair programming是XP的特色，它要求兩個程式設計師在一臺計算機上同時進行程式設計工作。共用滑鼠和鍵盤，通常一個人進行戰略上的思考，程式架構和函式，類之間的關係，一個人進行輸入和戰術上的思考，完成函式和類。兩個人可以經常交換角色。Pair programming需要一段時間學習和適應，實踐證明pair programming並不消耗更多的時間(人*小時)，但是程式碼的質量得到很大的提高。（避免將兩個新手放在一個pair中）

5）sequentialintegration

要保證原始碼庫的狀態是可標識的，同一時間，只允許一個pair的程式進行整和和測試，這樣可以縮小問題產生的範圍。不同的pair可以在自己的機器上隨時進行整和和測試.

6) integrate often

只要有可能就進行程式碼整合，週期可以在幾個小時，最好不要超過一天。經常的整合可以避免錯誤的積累，可以增加可重用的程式碼。在一個pair認為適當的時候並通過了所有的unit test，就可以進行整合，整合後的程式碼必須通過測試。同一時間，只允許一個pair進行整合。(整合失敗是不是要退回原有狀態，供其他pair整合？？)

7) 共同擁有程式碼

鼓勵每個人對專案中的任何人提出新的想法，任何開發人員對專案中的任何程式碼都可以進行增加功能，改正錯誤和重構。沒有程式碼或開發人員成為瓶頸。（我的想法：這確實很難理解，但是這確實是我夢想的目標）。為了達到這個目標，任何的程式碼都必須有相應的測試程式碼，任何程式碼的修改必須100%通過測試。必須加強開發人員的交流和知識共享，必須堅持統一編碼標準。Pair programming可以經常交換夥伴。

8）優化工作放在最後

先使系統能夠正常工作，不要猜測系統的瓶頸，要實際測量

9）NO overtime

不要長時間的加班，大多數加班並不能挽回已有的延遲，連續超過兩個星期的加班說明有問題存在。向一個已經延遲的專案填加人員也不是一個好的選擇。

4Testing

1)所有的程式碼都有單元測試

單元測試是XP的基石，XP中的單元測試應該是可以自動進行的，所以可以很快的進行所有的單元測試，單元測試應該在編碼之前建立。單元測試的程式碼和程式碼一起release，沒有單元測試的程式碼不能夠release。使用自動單元測試可以系統整合時節省大量的發現錯誤和改正的時間。單元測試越完善，節省的時間越多。對面向物件的程式設計來說，應該對每個類都有單元測試。完善的單元測試也是共同擁有程式碼的保證。單元測試也是可以經常重構的保證，每次重構後的程式碼都要重新進行測試

（這裡的unit test好象不只限於測試某個模組的功能？？？，應該可以測試整合起來的整個系統，這樣才能保證整合的正確性。）

2）程式碼在release前必須通過所有的單元測試

3) 發現bug後，首先增加測試

在實際執行中發現bug,首先增加acceptance test，然後增加unit test，在增加完測試後在查詢和修改程式碼，增加的測試保證同樣的錯誤不會再出現

4) acceptance test

acceptance test根據userstories在iteration plan會議上建立，它也應該可以自動執行以便可以經常執行。User stories是否完成是以是否通過acceptance test為檢驗標準。

XP中的角色：

1 customer 使用者

在XP中，使用者是專案組的一部分，使用者負責編寫use stories，確定優先順序，和開發人員討論需求，編寫accept test，執行accept test，使用者驅動iteration(release plan, iteration plan)

2 開發人員

與使用者討論user stories，估計開發時間，將user stories細化成programming task

編寫unit test

編碼

進行重構

整合及測試，保證100通過

3 manager

負責對外聯絡，組織團隊，獲取必要的資源，管理團隊

4 tracker

跟蹤release plan/iteration plan/acceptance test

5 coach

起顧問指導作用，mentor, monitor and help

A Coach is respected, but also respectful.They’re willing to talk, but also willing to listen. They let the team explore,but provide a guard-rail in case of danger.

監督進展，確保過程和規則，必要時改變過程，幫助解決問題，也可以參加pair programming。

二、敏捷開發的設計原則

關於敏捷開發的設計原則：

單一職責原則SRP：Single Responsibility Principle

開放封閉原則OCP：Open－Close Principle

Liskov替換原則LSP：LiskovSubstitution Principle

依賴倒置原則DIP：Dependency Invertion Principle

介面隔離原則ISP：Interface Separate Principle

關於包的設計原則：

重用釋出等價原則REP：Reuse Equivalence Principle

共同重用原則CRP：Common Resue Principle

共同封閉原則CCP：Common Close Principle

無環依賴原則ADP：Acyclic Dependency Principle

穩定依賴原則SDP：Stabilization Dependency Principle

穩定性度量公式：I＝Ce/(Ca+Ce) (I:不穩定度，Ce:輸入耦合度，Ca：輸出耦合度)

I取值範圍在【0，1】，I＝0表示具有最大穩定度；iI＝1標識具有最大不穩定度

穩定抽象原則SAP：Stabilization Abstract Principle

GOF說－－基於物件組合的設計會有更多的物件（而有較少的類）。

如果單純的看這裡，你會明白似乎類較少符合面向物件的邏輯。

但是且慢，我們知道面向物件有一條原則叫單一職責原則－－SRP。

這樣好像類多又是面向物件思想的體現。

其實最重要的是GOF中的這句話－－且系統的行為將依賴物件間的關係而不是被定義在某個類中。

所以類的多少並不是問題的關鍵，是否職責單一也不是大問題，

最重要的是你現在的那些職責是都多少是不能被別的職責通過某種方式所代替的。

在BOB大叔那裡定義職責是變化的原因，因此就可以認為這些變化的原因應該是不可代替的，

也可以說你不能由這個原因推匯出別的原因。

只要這個原因間可以做到相互關聯，那麼你就可以把由於這些變化而引起變化的類組合起來，

而不是把他們規定在新的類中。

開放封閉原則OCP：Open－Close Principle

一個模組在擴充套件性方面應該是開放的而在更改性方面應該是封閉的。

因此在進行面向物件設計時要儘量考慮介面封裝機制、抽象機制和多型技術。

該原則同樣適合於非面向物件設計的方法，是軟體工程設計方法的重要原則之一。

我們以收音機的例子為例，講述面向物件的開閉原則。

我們收聽節目時需要開啟收音機電源，對準電臺頻率和進行音量調節。

但是對於不同的收音機，實現這三個步驟的細節往往有所不同。

比如自動收縮電臺的收音機和按鈕式收縮在操作細節上並不相同。

因此，我們不太可能針對每種不同型別的收音機通過一個收音機類來實現（通過過載）這些不同的操作方式。

但是我們可以定義一個收音機介面，提供開機、關機、增加頻率、降低頻率、增加音量、降低音量六個抽象方法。

不同的收音機繼承並實現這六個抽象方法。

這樣新增收音機型別不會影響其它原有的收音機型別，收音機型別擴充套件極為方便。

此外，已存在的收音機型別在修改其操作方法時也不會影響到其它型別的收音機。

圖1是一個應用OCP生成的收音機類圖的例子：

Liskov替換原則LSP：LiskovSubstitution Principle

子類應當可以替換父類並出現在父類能夠出現的任何地方。

我們以學生為例，夜校生為學生的子類，因此在任何學生可以出現的地方，夜校生均可出現。

這個例子有些牽強，

一個能夠反映這個原則的例子時圓和橢圓，圓是橢圓的一個特殊子類。

因此任何出現橢圓的地方，圓均可以出現。但反過來就可能行不通。

　　運用替換原則時，我們儘量把類B設計為抽象類或者介面，

讓C類繼承類B（介面B）並實現操作A和操作B，

執行時，類C例項替換B，這樣我們即可進行新類的擴充套件（繼承類B或介面B），

同時無須對類A進行修改。

依賴倒置原則DIP：Dependency Invertion Principle

在進行業務設計時，與特定業務有關的依賴關係應該儘量依賴介面和抽象類，而不是依賴於具體類。

具體類只負責相關業務的實現，修改具體類不影響與特定業務有關的依賴關係。

在結構化設計中，我們可以看到底層的模組是對高層抽象模組的實現（高層抽象模組通過呼叫底層模組），

這說明，抽象的模組要依賴具體實現相關的模組，

底層模組的具體實現發生變動時將會嚴重影響高層抽象的模組，顯然這是結構化方法的一個"硬傷"。

　　面向物件方法的依賴關係剛好相反，具體實現類依賴於抽象類和介面

　　為此，我們在進行業務設計時，應儘量在介面或抽象類中定義業務方法的原型，

並通過具體的實現類（子類）來實現該業務方法，業務方法內容的修改將不會影響到執行時業務方法的呼叫

介面隔離原則ISP：Interface Separate Principle

採用多個與特定客戶類有關的介面比採用一個通用的涵蓋多個業務方法的介面要好。

　　ISP原則是另外一個支援諸如COM等元件化的使能技術。

缺少ISP，元件、類的可用性和移植性將大打折扣。

這個原則的本質相當簡單。如果你擁有一個針對多個客戶的類，

為每一個客戶建立特定業務介面，然後使該客戶類繼承多個特定業務介面將比直接載入客戶所需所有方法有效。

以下展示了一個擁有多個客戶的類。

它通過一個巨大的介面來服務所有的客戶。

只要針對客戶A的方法發生改變，客戶B和客戶C就會受到影響。

因此可能需要進行重新編譯和釋出。這是一種不幸的做法。

所展示的技術。每個特定客戶所需的方法被置於特定的介面中，這些介面被Service類所繼承並實現。

如果針對客戶A的方法發生改變，客戶B和客戶C並不會受到任何影響，也不需要進行再次編譯和重新發布。

三、敏捷開發技術在電子商務軟體中的應用

　　第一章背景介紹

　　1.1 電子商務背景

　　隨著企業資訊化的不斷進步，電子商務在中國也越來越得到更多的認可，電子商務的應用也越來越多，但是很多企業對電子商務的概念和應用還不是很清楚，行業內對電子商務的研究模式和實施方法也存在很多問題。因此很多企業在實施電子商務系統的過程中都處在探索和摸索當中，對於專案開發方來說也有著極大的風險性和挑戰性。

　　1.2 電子商務軟體開發存在的問題

　　由於電子商務軟體開發存在很大的風險性，而且電子商務的應用也出在不斷摸索當中，沒有很多成熟的模式可以參考，所以沒有實踐的指導可能會導致的專案噩夢。缺乏有效的實踐會導致不可預測性、重複的錯誤以及努力的白白浪費。延期的進度、增加的預算和低劣的質量致使客戶對我們喪失信心。更長時間的工作卻生產出更加低劣的軟體產品，也使得開發人員感到沮喪。我們希望這些方法這次還會有效，從而消除我們的恐懼。然而，專案並沒有簡單到使用一些約束和人為製品就能夠可靠地防止錯誤的地步。當連續地犯錯誤時，我們會對錯誤進行診斷，並在過程中增加更多的約束和人為製品來防止以後重犯這樣的錯誤。一個大而笨重的過程會產生它本來企圖去解決的問題。它降低了團隊的開發效率，使得進度延期，預算超支。它降低了團隊的響應能力，使得團隊經常建立錯誤的產品。

　　1.3 敏捷開發技術概述

　　敏捷式開發採用適應性方法，而傳統的軟體工程學採用的是預測性方法。敏捷式開發是以人為主的，而傳統的工程學是以過程為主的。

　　1.4 敏捷開發的現實意義

　　適應性和預測性的區別存在於軟體工程學對軟體開發過程的描述中。在傳統的工程學裡，核心的概念就是把設計和構建這兩個過程分開進行。在軟體開發的過程中，我們很難想象，如何真正把設計和程式設計完全區分過來。軟體工程學領域，所有在這裡從事工作的人員，都把設計的過程想象成用圖表、圖象的方式來描述結果的過程。還有一個更重要的問題就是說，軟體本身的需求是在變化的。一個專案在開發過程中需求會出現變化，需求的變化從根本上推翻了工程學方法所建立的一個基礎。當工程學的人儘量減少或者控制系統將來發生變化的可能，他越這樣做問題就越容易出現。既然我們沒辦法避免變化的發生，那麼我們就想找到一種新的方法能夠更有效地適應這種變化現象。這也就是敏捷式開發方法所要達到的效果。

　　第二章敏捷開發技術的應用

　　2.1 敏捷開發技術的幾種主要型別

1.XP（Extreme Programming －－ 極限程式設計

2.Cockburn的水晶系列方法

3.開放式原始碼

4.Highsmith的適應性軟體開發方法〔ASD〕

　　　2.2 敏捷開發技術的特點和優勢

　　1．個體和互動勝過過程和工具

　　人是獲得成功的最為重要的因素。如果團隊中沒有優秀的成員，那麼就是使用好的過程也不能從失敗中挽救專案，但是，不好的過程卻可以使最優秀的團隊成員失去效用。如果不能作為一個團隊進行工作，那麼即使擁有一批優秀的成員也一樣會慘敗。團隊的構建要比環境的構建重要得多。許多團隊和管理者就犯了先構建環境，然後期望團隊自動凝聚在一起的錯誤。相反，應該首先致力於構建團隊，然後再讓團隊基於需要來配置環境。

　　2．可以工作的軟體勝過面面俱到的文件

　　沒有文件的軟體是一種災難。程式碼不是傳達系統原理和結構的理想媒介。團隊更需要編制易於閱讀的文件，來對系統及其設計決策的依據進行描述。然而，過多的文件比過少的文件更糟。編制眾多的文件需要花費大量的時間，並且要使這些文件和程式碼保持同步，就要花費更多的時間。如果文件和程式碼之間失去同步，那麼文件就會變成龐大的、複雜的謊言，會造成重大的誤導。雖然從程式碼中提取系統的原理和結構資訊可能是困難的，但是程式碼是惟一沒有二義性的資訊源。在團隊成員的頭腦中，儲存著時常變化的系統的脈絡圖（road map）。人和人之間的互動是把這份脈絡圖傳授給他人的最快、最有效的方式。

　　3．客戶合作勝過合同談判

　　不能像訂購日用品一樣來訂購軟體。你不能夠僅僅寫下一份關於你想要的軟體的描述，然後就讓人在固定的時間內以固定的價格去開發它。所有用這種方式來對待軟體專案的嘗試都以失敗而告終。有時，失敗是慘重的。告訴開發團隊想要的東西，然後期望開發團隊消失一段時間後就能夠交付一個滿足需要的系統來，這對於公司的管理者來說是具有誘惑力的。然而，這種操作模式將導致低劣的質量和失敗。成功的專案需要有序、頻繁的客戶反饋。專案的需求基本處於一個持續變化的狀態。大的變更是很平常的。在這期間，也會出現整個功能塊被減掉，而加進來另外一些功能塊。然而，合同和專案都經受住了這些變更，並獲得成功。成功的關鍵在於和客戶之間真誠的協作，並且合同指導了這種協作，而不是試圖去規定專案範圍的細節和固定成本下的進度。

　　4．響應變化勝過遵循計劃

　　響應變化的能力常常決定著一個軟體專案的成敗。當我們構建計劃時，應該確保計劃是靈活的並且易於適應商務和技術方面的變化。計劃不能考慮得過遠。

　　2.3 敏捷開發技術的12個原則

1．我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意。

2．即使到了開發的後期，也歡迎改變需求。

3．經常性地交付可以工作的軟體，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好

4．在整個專案開發期間，業務人員和開發人員必須天天都在一起工作。

5．圍繞被激勵起來的個人來構建專案。

6．在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談。

7．工作的軟體是首要的進度度量標準。

8．敏捷過程提倡可持續的開發速度。

9．不斷地關注優秀的技能和好的設計會增強敏捷能力。

10．簡單使未完成的工作最大化。

11．最好的構架、需求和設計出自於自組織的團隊。

12．每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。

　　2.4 敏捷開發技術的適用範圍

1.專案團隊的人數不能太多

2.專案經常發生變更

3.高風險的專案實施

4.開發人員可以參與決策

　　第三章敏捷開發技術在電子商務軟體的實際應用案例

　　3.1 案例說明：鋼鐵貿易企業的網上期貨訂貨系統開發實施

　　專案背景：國內某大型國有鋼鐵貿易企業，其業務形式大部分採用期貨訂貨，客戶群也比較廣泛，訂貨時間相對比較穩定，一般集中在月底的10天左右。該企業原來開發了一套適合自己企業運作的貿易企業ERP系統，但是僅僅是在公司內部使用，功能也很有限，不能夠很好的和客戶進行資訊交流，往往客戶在集中訂貨的時候，因為訂貨量巨大，而且時間集中，所以造成該企業的業務人員忙的團團轉，而且經常會發生排隊訂貨的現象，同時由於是期貨訂貨，所以該企業還得向上遊供應商訂貨，這樣一來一去，給工作帶來極大的不便，也容易造成混亂和漏洞。

　　因此，介於使用者這樣的情況，需要開發一套網上期貨訂貨系統，將訂貨的整個環節都打通，真正實現24小時訂貨。減少人工干預，通過和幾個系統之間的整合，做到實時的資訊流通。但是這樣一個系統對於該企業來說，畢竟是第一回，國內也沒有相關成熟的案例和模型，所以實施存在極大的風險性。而且其他同行業的競爭對手也在著手打造這樣的一個系統，所以儘早建立網上訂貨系統，對於提高顧客的忠誠度和滿意度都是大有裨益的，所以對工期的要求也非常嚴格。

　　根據以上情況，決定採用敏捷開發技術來實施這個專案。

　　3.2 專案組織機構

　　建立聯合實施團隊，由電子商務公司的專案實施人員和客戶方的關鍵使用者一起構成，統一受客戶方的常務副總指揮。

　　工作方式：在客戶現場辦公，在調研的同時做需求，根據系統架構和功能劃分，邊做設計邊做開發。

　　溝通方式：每天下班前半個小時，所有專案組成員必須座在一起溝通交流，對每天的工作進行總結和經驗交流。每週召開一次推進和培訓會議，在不斷的開發過程中進行對使用者的業務知識，系統知識，和操作的培訓，為將來系統的執行維護打下更好的基礎。

　　3.3 專案實施過程

　　第一輪迴圈實施週期兩個月，不但搭建了整個應用的整體框架，還實現了兩大品種的單向期貨訂貨流程。

　　第二輪迴圈實施週期兩個月，打通了向供應商的期貨訂貨環節，並且實現了另外兩個品種的訂貨。同時逐步將前期做好的系統向用戶做推廣使用，在不斷完善的過程中，對本階段的專案開發實施做修正。

　　第三輪迴圈實施週期三個月。由開發人員和客戶方的關鍵使用者對期貨訂貨系統進行完善和優化。

　　3.4 專案實施效果