敏捷開發 與 Scrum

敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過測試，具有可視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可以使用狀態。

 

 

 什麼是敏捷開發？

敏捷開發(Agile Development)是一種以人爲核心、迭代、按部就班的開發方法。

怎麼理解呢？首先，咱們要理解它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導咱們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發；

 

爲何說是以人爲核心？

咱們大部分人都學過瀑布開發模型，它是以文檔爲驅動的，爲何呢？由於在瀑布的整個開發過程當中，要寫大量的文檔，把需求文檔寫出來後，開發人員都是根據文檔進行開發的，一切以文檔爲依據；而敏捷開發它只寫有必要的文檔，或儘可能少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，因此它強調以人爲核心。

 

什麼是迭代？

迭代是指把一個複雜且開發週期很長的開發任務，分解爲不少小週期可完成的任務，這樣的一個週期就是一次迭代的過程；同時每一次迭代均可以生產或開發出一個能夠交付的軟件產品。

 

敏捷開發由幾種輕量級的軟件開發方法組成,包括極限編程、Scrum、精益開發(Lean Development)、動態系統開發方法、特徵驅動開發(Feature Driver Development)、水晶開發(Cristal Clear)等等。全部這些方法都具備如下共同特徵,它們也是敏捷開發的原則:

 

 

1. 迭代式開發。即整個開發過程被分爲幾個迭代週期,每一個迭代週期持續的時間通常較短,一般爲1到6周。

2. 增量交付。產品是在每一個迭代週期結束時被逐步交付使用,每次交付的都是能夠被部署、能給用戶帶來即時效益和價值的產品。

3. 開發團隊和用戶反饋推進產品開發。敏捷開發方法主張用戶可以全程參與到整個開發過程當中。這使需求變化和用戶反饋能被動態管理並及時集成到產品中。

4. 持續集成。新的功能或需求變化老是儘量頻繁地被整合到產品中。有些是在每一個迭代週期結束的時候集成, 有些則天天都在這麼作。

5. 開發團隊自我管理。人是敏捷開發的核心。敏捷開發老是以人爲中心創建開發的過程和機制,而非把過程和機制強加給人。

 

 

敏捷開發的優點:

知足用戶不斷變化的需求是軟件開發的長期沒法解決的難題之一,經典的瀑布模式在一個迭代週期內表現優異,但一旦需求變化,瀑布模式卻顯得無能爲力。敏捷方法知足需求的辦法主要經過迭代。在每一次迭代週期結束時,都能交付用戶一個可用的、可部署的系統,用戶使用並體驗該系統並反饋意見,在隨後的迭代週期這些意見和需求的其餘變化一塊兒在產品中實現和集成。每次迭代週期應儘量短,以便能及時地處理需求變化和用戶反饋。

 

敏捷開發方式能給企業和用戶帶來如下好處:

1. 精確。瀑布模式一般會在產品起點與最終結果之間規劃出一條直線,而後沿着直線不斷往前走。然而當項目到達終點時,用戶一般會發現那已經不是他們想去的地方。而敏捷方法則採用小步快跑,每走完一步再調整併爲下一步肯定方向,直到真正的終點。

2. 質量。敏捷方法對每一次迭代週期的質量都有嚴格要求。一些敏捷方法如極限編程等,甚至使用測試驅動開發(test-driven development),即在正式開發功能代碼以前先開發該功能的測試代碼。這些都爲敏捷項目的整個開發週期提供了可靠的質量保證。

3. 速度。敏捷團隊只專一於開發項目中當前最須要的、最具價值的部分。這樣能很快地投入開發。另外,較短的迭代週期使團隊成員能迅速進入開發狀態。

4. 豐厚的投資回報率。在敏捷開發過程當中,最具價值的功能老是被優先開發,這樣能給客戶帶來最大的投資回報率。

5. 高效的自我管理團隊。敏捷開發要求團隊成員必須積極主動,自我管理。在這樣的團隊中工做,每一個團隊成員的技術能力、交流、社交、表達和領導能力也都能得以提升。

 

 

主要的敏捷方法：

敏捷開發方法是一組開發方法的統稱,主要包括如下幾種:

極限編程其主要目的是下降需求變化的成本。它引入一系列優秀的軟件開發方法,並將它們發揮到極致,結對編程(pair-programming)就是其中比較知名的方法之一。除此以外, 其核心作法還有小規模、頻繁的版本發佈、短迭代週期、測試驅動開發、持續集成、每日站立會議、共同擁有代碼、系統隱喻等。

Scrum Scrum是一個敏捷開發框架,它由一個開發過程、幾種角色以及一套規範的實施方法組成。在Scrum中,產品需求被定義爲產品需求積壓(product backlogs)。全部的產品需求積壓都是從一個簡單的想法開始,並逐步被細化,直到能夠被開發的程度。Scrum將開發過程分爲多個Sprint週期,每一個Sprint表明一個2~4周的開發週期,有固定的時間長度。

精益開發精益開發的核心思想是查明和消除浪費。在軟件開發過程當中bug、沒用的功能、等待以及其餘任何對實現結果沒有益處的東西都是浪費。浪費及其源頭必須被分析查明,而後設法消除。精益開發的其餘原則包括強調學習、在最後時刻作決定、用最快的速度交付用戶等。

其餘敏捷方法還包括動態系統開發方法(DSDM)、特徵驅動開發(FDD)、Crystal Clear等,各類敏捷方法的區別在於它們對敏捷的不一樣闡釋和不一樣側重。理解這些方法能夠幫助咱們從多個角度理解敏捷開發,而且瞭解更多的最佳應用。

 

關於Scrum和XP

前面說了敏捷它是一種指導思想或開發方式，可是它沒有明確告訴咱們到底採用什麼樣的流程進行開發，而Scrum和XP就是敏捷開發的具體方式了，你能夠採用Scrum方式也能夠採用XP方式；Scrum和XP的區別是，Scrum偏重於過程，XP則偏重於實踐，可是實際中，二者是結合一塊兒應用的，這裏我主要講Scrum。

 

什麼是Scrum？

Scrum的英文意思是橄欖球運動的一個專業術語，表示「爭球」的動做；把一個開發流程的名字取名爲Scrum，我想你必定能想象出你的開發團隊在開發一個項目時，你們像打橄欖球同樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你必定會感到很是興奮的。

而Scrum就是這樣的一個開發流程，運用該流程，你就能看到你團隊高效的工做。

 

【Scrum開發流程中的三大角色】

產品負責人（Product Owner）

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

 

流程管理員（Scrum Master）

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

 

開發團隊（Scrum Team）

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

 

 

Scrum流程圖

 

//------------------------

下面，咱們開始講具體實施流程，可是在講以前，我還要對一個英文單詞進行講解。

什麼是Sprint？

Sprint是短距離賽跑的意思，這裏面指的是一次迭代，而一次迭代的週期是1個月時間（即4個星期），也就是咱們要把一次迭代的開發內容以最快的速度完成它，這個過程咱們稱它爲Sprint。

 

如何進行Scrum開發？

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

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

三、有了Product Backlog列表，咱們須要經過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story做爲本次迭代完成的目標，這個目標的時間週期是1~4個星期，而後把這個Story進行細化，造成一個Sprint Backlog；

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

五、在Scrum Team完成計劃會議上選出的Sprint Backlog過程當中，須要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每一個人都必須發言，而且要向全部成員當面彙報你昨天完成了什麼，而且向全部成員承諾你今天要完成什麼，同時遇到不能解決的問題也能夠提出，每一個人回答完成後，要走到黑板前更新本身的 Sprint burn down（Sprint燃盡圖）；

六、作到每日集成，也就是天天都要有一個能夠成功編譯、而且能夠演示的版本；不少人可能尚未用過自動化的每日集成，其實TFS就有這個功能，它能夠支持每次有成員進行簽入操做的時候，在服務器上自動獲取最新版本，而後在服務器中編譯，若是經過則立刻再執行單元測試代碼，若是也所有經過，則將該版本發佈，這時一次正式的簽入操做才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

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

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