[[164863]]

在CMM（能力成熟度模型Capability Maturity Model的縮寫，是一種側重于軟件開發過程的管理及工程能力的提高與評估的開發模型）神話崩潰以后，敏捷開發逐漸引起了人們的關注，并被寄予厚望。下面我們就來談一談敏捷開發相關的一些知識。

敏捷開發的起源

我們大部分人都學過瀑布開發模型，它是以文檔為驅動的。因為在瀑布的整個開發過程中，開發人員根據需求文檔進行開發，一切以文檔為依據。敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法，是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人，注重的是人與人之間，面對面的交流；它只寫有必要的文檔，或盡量少寫文檔；采用的是迭代式開發。

敏捷開發提倡將一個完整的軟件版本劃分為多個迭代，每個迭代實現不同的特性。重大的、優先級高的特性優先實現，風險高的特性優先實現。在項目的早期就將軟件的原型開發出來，并基于這個原型在后續的迭代不斷完善。迭代開發的好處是：盡早編碼，盡早暴露項目的技術風險。盡早使客戶見到可運行的軟件，并提出優化意見。可以分階段提早向不同的客戶交付可用的版本。

在每個迭代中，架構師負責將所有的特性分解成多個Story Card。每個Story可以視為一個獨立的特性。每個Story應該可以在最多1個星期內完成開發，交付提前測試（Pre-Test）。當一個迭代中的所有Story開發完畢以后，測試組再進行完整的測試。在整個測試過程中（pre-test，test），基于Daily build，測試組永遠都是每天從配置庫上取下最新編譯的版本進行測試，開發人員也隨時修改測試人員提交的問題單，并合入配置庫。

敏捷開發的一個特點是開放式辦公，充分溝通，包括測試人員也和開發人員一起辦公。基于Story Card的開發方式，團隊會在開放式辦公區域放置一塊白板，上面粘貼著所有的Story Card，按當前的開發狀態貼在4個區域中，分別是：未開發，開發中，預測試中，測試中。Story Card的開發人員和測試人員根據開發進度在Story Wall上移動Story Card，更新Story Card的狀態。這種方式可以對項目開發進度有一個非常直觀的了解。

敏捷開發宣言

個體和交互 勝過 過程和工具

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

客戶合作 勝過 合同談判

響應變化 勝過 遵循計劃

雖然右項也有價值，但是我們認為左項具有更大的價值。

敏捷開發的方式

敏捷開發作為一種指導思想或開發方式，Scrum和XP（Extreme Programming：極限編程）是敏捷開發的具體方式。Scrum和XP的區別是，Scrum偏重于過程，XP則偏重于實踐，但是實際中，兩者是結合一起應用的。

Scrum方式

Scrum的英文意思是橄欖球運動的一個專業術語，表示“爭球”的動作；把一個開發流程的名字取名為Scrum，大家像打橄欖球一樣迅速、富有戰斗激情，運用該流程，你就能看到你團隊高效的工作。

Scrum整個開發過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯網產品研發可以使用1周的Sprint)。在Scrum中，使用Product Backlog來管理產品的需求，Product backlog是一個按照商業價值排序的需求列表，Scrum團隊總是先開發對客戶具有較高價值的需求。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。Scrum 采用迭代、增量的方法來優化可預見性并控制風險。

Scrum開發流程中的三大角色

產品負責人（Product Owner）

主要負責確定產品的功能和達到要求的標準，指定軟件的發布日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。

流程管理員（Scrum Master）

主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。

開發團隊（Scrum Team）

主要負責軟件產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面，但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；成員可以采用任何工作方式，只要能達到Sprint的目標。

進行Scrum開發的流程

1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

2、Scrum Team根據Product Backlog列表，做工作量的預估和安排；

3、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；

 [[164864]]

5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；

 [[164865]]

6、做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實TFS就有這個功能，它可以支持每次有成員進行簽入操作的時候，在服務器上自動獲取最新版本，然后在服務器中編譯，如果通過則馬上再執行單元測試代碼，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪Sprint的產品需求中；

XP方式

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

XP的十三種核心實踐

團隊協作(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）

關于規劃策略：計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

關于測試驅動開發：編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功功能能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。

關于隱喻：隱喻同體系結構是同義詞，隱喻用于描述項目的全貌，Story用于描述個別具體的特征。隱喻是將整個系統聯系在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的

XP的一個成功因素是重視客戶的反饋——開發的目的就是為了滿足客戶的需要。XP方法使開發人員始終都能自信地面對客戶需求的變化。XP強調團隊合作，經理、客戶和開發人員都是開發團隊中的一員。團隊通過相互之間的充分交流和合作，使用XP這種簡單但有效的方式，努力開發出高質量的軟件。XP的設計簡單而高效；程序員們通過測試獲得客戶反饋，并根據變化修改代碼和設計，他們總是爭取盡可能早地將軟件交付給客戶。XP程序員能夠勇于面對需求和技術上的變化。

什么是優秀團隊

有家公司的一個團隊的一個項目用的是"敏捷開發方法"，而當時公司的理念恰恰是：開放、協作性強、扁平化團隊，以用戶為中心；和團隊使用的敏捷方法理念正好相同，結果毫無懸疑的拿到了優秀團隊獎。即使開發的項目并不是很成功，但公司需要一個團隊來做榜樣，來激勵其他團隊，而那里正好有這么一個團隊。

如果做不了優秀的團隊，那么就做一個典型的團隊，公司需要這么一個做示范的話題。優秀的團隊并不是拘泥于某種開發方式的，而是最適合某種方式的。希望您也能在一個優秀的團隊。