談談我理解的敏捷開發

「敏捷開發」 幾乎成了互聯網家戶喻曉的一個熱門話題。每一個人都在聊敏捷、Scrum、XP。

我對「敏捷」的認識還算是在一個正在探索的階段。網上有很是多的資料，五花八門，對於初學者來講無形之中會設了不少的坎。恰好藉此機會寫個文章幫助本身進行知識的梳理和總結，另一方面也但願對剛接觸的人有所幫助。

「敏捷開發」 知多少？

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

它並非一門技術，而是一種開發方式，也就是一種軟件開發的流程。它會指導咱們用規定的環節去一步一步完成項目的開發。由於它採用的是迭代式開發，因此這種開發方式的主要驅動核心是人。

那爲何說人才是主要的驅動核心了？咱們學過瀑布開發模型，它是以文檔做爲驅動，開發人員都是根據產品部門提供的需求文檔進行開發的，一切的核心是文檔，因此說文檔是這個模型中的一個核心。而敏捷開發的意義在於它只關注文檔中的重要點，或者儘量的去簡化文檔，敏捷開發其實更注重的是人與人之間的溝通、交流。因此它強調以人爲核心。

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

Scrum 和 XP 

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

XP:極限編程（Extreme Programming）。可參考：http://blog.csdn.net/fw0124/article/details/48713959

文章開頭談敏捷的時候更注重的是概念性的，並無談到實際敏捷開發的實際應用情景。這裏開始之因此聊 Scrum 和 XP，由於這就是敏捷開發的具體方式了。在實際開發中，你能夠採用 Scrum 方式也能夠採用 XP 方式。

Scrum 和 XP 的區別是，Scrum 偏重於過程，XP 則偏重於實踐，可是實際中，二者是結合一塊兒應用的。

Scrum開發流程中你會常常聽到三個項目角色，好比 PO \ SM \ ST ，對於一個剛接觸敏捷開發的初學者來講，聽到這種簡稱心裏仍是極爲崩潰的，我當初也是感同身受。這裏順便簡單的補充下關於這三個角色的一個簡介

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

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

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

Scrum 的流程圖：（如下圖片來自網絡）

讀到這裏，我想你對敏捷開發應該有了一個初步的認識了。接着咱們繼續聊下敏捷開發的具體開發流程。

在此以前，咱們先來談個在敏捷開發中最長聽到的單詞 「Sprint」 。談到這個詞，以往我第一次聽到的時候私下去查了，各類各樣的解釋，真是十臉懵逼。藉着此次機會也給你們簡單的解釋下。

請看如下小段落：

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

那麼最後咱們來細聊下如何進行 Scrum 的開發。

1.首先咱們須要確認一個 PB ( Product Backlog , 即按優先順序排列的一個產品需求列表) ，這是由 PO（Product Owner） 負責的

2.ST（Scrum Team） 會根據 PB 列表，進行工做量的預估和安排

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

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

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

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

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

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

下面是運用 Scrum 開發流程中的一些場景圖：

（每日站立會議，參會人員能夠隨意姿式站立，任務看板要保證讓每一個人看到，當每一個人發言完後，要走到任務版前更新本身的燃盡圖）

（任務看版包含 未完成、正在作、已完成 的工做狀態，假設你今天把一個未完成的工做已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。每一個人的工做進度和完成狀況都是公開的，若是有一我的的工做任務在某一個位置放了好幾天，你們都能發現他的工做進度出現了什麼問題（成員人數最好是5~7個，這樣每人可使用一種專用顏色的標籤紙，一眼就能夠從任務版看出誰的工做進度快，誰的工做進度慢）

 

（計劃紙牌，它的做用是防止項目在開發過程當中，被某些人所領導。

怎麼用的呢？好比A程序員開發一個功能，須要5個小時，B程序員認爲只須要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，若是時間差距很大，那麼A和B就能夠討論A爲何要5個小時）