現在敏捷開發是越來越火了，人人都在談敏捷，人人都在學習Scrum和XP...

為了不落後他人，於是我也開始學習Scrum，今天主要是對我最近閱讀的相關資料，根據自己的理解，用自己的話來講述Scrum中的各個環節，主要目的有兩個，一個是進行知識的總結，另外一個是覺得網上很多學習資料的講述方式讓初學者不太容易理解；所以我決定寫一篇掃盲性的博文，同時試著也與園內的朋友一起分享交流一下，希望對初學者有幫助。

 什麼是敏捷開發？

敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。

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

為什麼說是以人為核心？

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

什麼是迭代？

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

關於Scrum和XP

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

什麼是Scrum？

Scrum的英文意思是橄欖球運動的一個專業術語，表示“爭球”的動作；把一個開發流程的名字取名為Scrum，我想你一定能想象出你的開發團隊在開發一個專案時，大家像打橄欖球一樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你一定會感到非常興奮的。

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

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

產品負責人（Product Owner）

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

流程管理員（Scrum Master）

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

開發團隊（Scrum Team）

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

Scrum流程圖

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

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

什麼是Sprint？

Sprint是短距離賽跑的意思，這裡面指的是一次迭代，而一次迭代的週期是1個月時間（即4個星期），也就是我們要把一次迭代的開發內容以最快的速度完成它，這個過程我們稱它為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天內能完成）；

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開發流程中的一些場景圖：

上圖是一個 Product Backlog 的示例。

上圖就是每日的站立會議了，參會人員可以隨意姿勢站立，任務看板要保證讓每個人看到，當每個人發言完後，要走到任務版前更新自己的燃盡圖。

任務看版包含 未完成、正在做、已完成 的工作狀態，假設你今天把一個未完成的工作已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。

每個人的工作進度和完成情況都是公開的，如果有一個人的工作任務在某一個位置放了好幾天，大家都能發現他的工作進度出現了什麼問題（成員人數最好是5~7個，這樣每人可以使用一種專用顏色的標籤紙，一眼就可以從任務版看出誰的工作進度快，誰的工作進度慢）

 上圖可不是撲克牌，它是計劃紙牌，它的作用是防止專案在開發過程中，被某些人所領導。

怎麼用的呢？比如A程式設計師開發一個功能，需要5個小時，B程式設計師認為只需要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，如果時間差距很大，那麼A和B就可以討論A為什麼要5個小時...

敏捷開發的4句宣言

個體與互動 勝過 過程與工具

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

客戶協作 勝過 合同談判

響應變化 勝過 遵循計劃

敏捷開發知識體系整體框架

敏捷開發工程實踐

專案管理

• 迭代開發
• 風險價值生命週期
• 多級專案規劃
• 完整團隊
• 每日站立會議
• 任務板
• 燃盡圖

需求管理

• 需求訂單
• 業務流程草圖
• 用例驅動開發
• 使用者故事

架構

• 演進的架構
• 演進的設計
• 基於元件的架構設計

開發

• 結對程式設計
• 測試驅動開發
• 重構
• 程式碼規範

測試

• 單元測試
• 並行測試
• 測試管理

變更管理

• 持續整合
• 自動構建
• 團隊變更管理

敏捷開發管理實踐描述

• 定義和特徵說明
• 主要角色
• 主要活動和最佳實踐
• 主要輸入輸出
• 工作流程

敏捷開發工程實踐描述

• 定義和特徵說明
• 應用說明
• 案例說明

敏捷開發核心價值觀和原則

敏捷軟體開發宣言

個體和互動 高於 流程和文件
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
也就是說, 儘管右項有其價值, 我們更重視左項的價值.

• 1
• 2
• 3
• 4
• 5

• 1
• 2
• 3
• 4
• 5

敏捷軟體開發的核心價值觀

敏捷開發的核心理念就是以最簡單有效的方式快速打成目標, 並在這個過程中及時地響應外界的變化, 做出迅速的調整.

核心價值觀

• 以人為本
• 目標導向
• 客戶為先
• 擁抱變化

敏捷開發的原則

• 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
• 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
• 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
• 業務人員和開發人員必須相互合作，專案中的每一天都不例外。
• 激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。
• 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
• 可工作的軟體是進度的首要度量標準。
• 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
• 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
• 以簡潔為本，它是極力減少不必要工作量的藝術。
• 最好的架構、需求和設計出自自組織團隊。
• 團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。

敏捷開發管理實踐

Scrum

Scrum是一種迭代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。

Scrum中的角色

“豬”角色

• 產品負責人（Product Owner） 
  
  • 通常由市場部門的人擔任
• 敏捷教練 (Scrum Master) 
  
  • 通常由開發組組長擔任
• 開發團隊 (Scrum Team) 
  
  • 包括開發,需求,測試

“雞”角色

• 使用者 
  
  • 軟體是為了某些人而建立！就像“假如森林裡有一棵樹倒下了，但沒有人聽到，那麼它算髮出了聲音嗎”，“假如軟體沒有被使用，那麼它算是被開發出來了麼？”
• 利益所有者 (客戶，提供商) 
  
  • 影響專案成功的人, 但只直接參與衝刺評審過程。
• 管理者 
  
  • 為產品開發團體架起環境的那個人

主要活動和最佳實踐

• 迭代式軟體開發
• 兩層專案規劃 (Two-Level Project Planning)
• 整體團隊協作 (Whole Team)
• 持續整合
• 衝刺規劃會議 (Sprint Plan Meeting)
• 每日站立會議 (Sprint Daily Meeting)
• 衝刺複審會議 (Sprint Review Meeting)
• 衝刺回顧會議 (Retrospective Meeting)

主要輸入輸出

• 產品訂單(Product Backlog)
• 衝刺訂單(Spring Backlog)
• 燃盡圖(Burndown Chart)
• 新的功能增量

工作流程

專案管理過程

• 在Scrum專案管理過程中產品負責人獲取專案投資, 並對整個產品的成功負責.
• 產品負責人協調個中利益干係人, 確定產品訂單中初始的需求清單及其優先順序, 完成專案商業價值分析和專案整體規劃, 並任命合適的敏捷教練開展專案工作.

專案開發過程

在Scrum軟體開發過程中, 每個衝刺就是較短的迭代, 通常為2~4周.

• 在每個衝刺開始時, 產品負責人和敏捷教練通過召開衝刺規劃會議和”兩層專案規劃”的最佳實踐, 制定衝刺訂單(類似迭代計劃)
• 產品負責人明確在本次衝刺中實現的需求清單, 響應的工作任務和負責人.
• 在每個衝刺迭代中, 團隊強調應用”整體團隊協作”的最佳實踐, 通過保持可持續發展的工作節奏和每日站立會議, 實現團隊的自組織, 自適應和自管理, 高效完成衝刺工作.
• 在每個衝刺結束時, 團隊都會召開衝刺複審會議, 團隊成員會在會上分別展示他們開發出的軟體(或其他有價值的產品), 並從產品負責人和其他利益關係人那裡, 得到反饋資訊.
• 在衝刺複審會議之後, 團隊會自覺招開衝刺回顧會議, 回顧整個專案過程, 討論哪些方法做的好, 哪些方面可以改進, 實現軟體交付過程的持續, 自發的改進.

XP

OpenUp

Lean

敏捷開發工程實踐

迭代式開發

敏捷迭代開發是指每次按照相同的開發方式短期的開發軟體的部分, 或前期開發並不詳盡的軟體, 每次開發結束獲得可以執行的軟體, 以供各方干係人觀測, 獲得反饋, 根據反饋適應性的進行後續開發, 經過發福多次開發, 逐步增加軟體部分, 逐步補充完善軟體, 最終開發得到最後的軟體. 每次反覆開開發叫一次迭代, 在Scrum中成為Sprint, 中文常譯為”衝刺”.

持續整合

持續整合(Continuous integration)是指當代碼提交後, 馬上啟動自動編譯, 自動部署金額自動化測試來快速驗證軟體, 從而儘快的發現整合錯誤.

多級專案規劃

多級專案/產品規劃, 在軟體開發領域, 是指以迭代開發為基礎, 形成多層次的, 逐步細化的專案或產品計劃. 這些層層相關的專案/產品規劃包括:

• 專案/產品願景
• 專案/產品路線圖
• 版本釋出計劃
• 迭代計劃
• 每日實現

專案/產品願景

在計劃階段, 首先, 專案stakeholder, 專案/產品負責人將參與並組成工作組, 他們負責闡述專案的重要性, 給出專案成功失敗的關鍵標準以及專案整體層面”完成”的定義; 在過程中, 可以利用形成專案願景的一些個工具, 包括願景盒子(Vison Box), 業務收益矩陣(Business Benefits Matrix), 專案範圍矩陣(Scope Matrix), 滑動器(Slider), 成本收益矩陣(Cost/Benefit Matrix)等; 最後, 專案願景需要使用盡量簡要的文件固定下來, 並保證專案團隊成員都能瞭解.該文件需要包括:

• 當前的問題
• 機會描述和理由(描述專案的重要性)
• 專案的價值
• 專案如何和組織的戰略目標達成一致
• 解決方案綜述
• 專案包含的關鍵功能
• 專案必須服從的技術和約束條件
• 專案範圍
• 專案的關鍵時間線
• 專案收益分析
• 專案和其他專案的依賴性
• 專案的相關風險以及如何消除

專案/產品路線圖

主要描述為了達到產品願景而需要交付的關鍵功能和特性, 這些特性基本處於Epic和特性層面, 不包裹使用者故事(User Story). 它從時間的維度來表述對願景的支援和實現. 它從時間維度來表達對願景的支援和實現. 當專案/產品需要釋出多個版本時, 專案線路圖就非常重要, 否則, 它和釋出計劃相同, 專案/產品線路圖由專案負責人和專案經理維護, 並保持更新. 通常, 會形成路線圖問題或幻燈片, 使用大圖示顯示重要的里程碑, 包含的功能和釋出日期等, 讓所有專案/產品相關人員都清楚產品各個元件的可能釋出日程.

版本釋出計劃

版本釋出計劃由團隊成員和專案/產品負責人共同制定, 並通過版本釋出計劃會議討論通過. 它包括了當前版本需要交付的, 達成一致的關鍵功能, 並經過優先順序排序, 可以包含EPIC和User Story. 版本釋出計劃中常使用的概念包括:故事點, 迭代團隊速率和優先順序排序. 通常, 專案/產品負責人提出本次釋出的目標, 團隊成員根據目標和功能特性的重要性對故事進行排序, 並依據團隊速率覺得本次釋出需要包含的故事點. 前幾次版本釋出使用估算值, 其準確性隨著專案/產品的時間持續而逐步精確. 版本釋出計劃是劇本適應性可調整的計劃, 會隨著專案演進而改變.

迭代計劃

迭代計劃是對版本釋出計劃的再次細化, 同樣由團隊成員和專案/產品負責人共同制定, 並聽過迭代計劃會議討論通過. 迭代會議負責兩件事情:

• 根據當前狀態確定是否需要對版本計劃做出更新
• 為當前的迭代計劃制定迭代計劃

迭代計劃中常使用的概念包括: 拆分Epic和User Story, 任務, 任務估算. 在迭代會議上, 成員首先根據當前的專案變化對釋出計劃進行更新, 然後根據更新後的, 重新排序過的故事制定當前迭代需要完成的故事, 並對這些故事進行詳細的任務拆分. 成員在認領完任務後, 會對任務的實現時間做出估算, 估算值需要具體到這些估算資訊可以方便任何成員追蹤任務的進度.

每日實現

沒事實現是團隊成員完成任務的具體過程, 它依據任務估算值並根據任務最終實現情況更新該值. 在敏捷方法中, 使用每日站會議來報告進度. 通過15分鐘的站立形式, 團隊成員報告故事或者任務的完成,未完成狀態, 而解決層面的問題則在會議之後處理.

完整團隊

Scrum團隊必須具備的三個完整性:

團隊職責完整性

產品負責人（Product Owner）

• 確定產品的功能。
• 決定釋出的日期和釋出內容。
• 為產品的收益(profitability of the product)負責。
• 根據市場價值確定功能優先順序。
• 在30天內調整功能和調整功能優先順序。
• 接受或拒絕接受開發團隊的工作成果

敏捷教練 (Scrum Master)

• 負責監督整個Scrum專案程序, 調整開發計劃
• 保證團隊資源完全可被利用並且全部是高產出的。
• 保證各個角色及職責的良好協作。
• 解決團隊開發中的障礙。
• 做為團隊和外部的介面，遮蔽外界對團隊成員的干擾。
• 保證開發過程按計劃進行，組織 Daily Scrum, Sprint Review and Sprint Planning meetings。
• 需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估計可能已經發生變化. 根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的燃盡圖
• 需要找出阻礙Scrum的障礙和依賴, 根據優先順序指定計劃解決這些障礙
• 個人問題或衝突在Scrum裡是需要解決的。這些都需要被澄清，或通過內部的溝通解決，或向管理層和HR尋求幫助解決
• Scrum Master需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估計可能已經發生變化。Scrum Master需要根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的Burndown Chart。 Scrum Master還必須仔細考慮進展中的開放任務數，進展中的工作需要得到最小化，以實現精益生產率的收益。
• Scrum Master需要找出阻礙Scrum的障礙和依賴。他們需要的優先次序和跟蹤。根據優先順序指定計劃解決這些障礙。其中有些問題可以在團隊內部解決，有些則要團隊之間的協調，還有的要管理層的介入來解決.

開發團隊 (Scrum Team)

• 具有不同特長的團隊成員，人數控制在5-7個左右, 跨職能, 包括開發, 需求, 測試
• 弱化分工, 每個人都參與設計, 開發與測試
• 確定Sprint目標和具體說明的工作成果。
• 在專案嚮導範圍內有權利做任何事情已確保達到Sprint的目標。
• 向Product Owner演示產品功能。

團隊素質完整性

• 要具備很強的集體協作精神.
• 要具備良好的溝通能力
• 必須能積極主動的接受新的事物, 要具備創新能力
• 要具備極強的自我管理能力和積極主動的精神

溝通的完整性

• Sprint啟動會
• 每日站立會議
• Sprint回顧會

案例

驗收測試驅動開發ATDD

TDD 只是開發人員的職責，通過單元測試用例來驅動功能程式碼的實現。ATDD在準備實施一個功能或特性之前，首先團隊需要定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試指令碼開發。面向開發人員，強調如何實現系統以及如何檢驗。

• 挑選使用者故事
• 為故事寫測試
• 實現測試
• 實現故事

結對程式設計

結對程式設計可以看做是一種敏捷化的Code Review

新結對程式設計

兩位程式設計師新成結對小組, 每人一臺電腦, 坐在臨近的工位上, 兩人合作完成一組功能(可以是兩個或多個獨立的模組)的設計, 程式碼實現. 但對已某一個模組來說設計和程式碼是分開的, 一個人負責設計, 另一個人負責寫程式碼, 對於其他模組則反之.

確定衝刺計劃

定義和說明

• 目的: ST和PO共同決定在接下來的衝刺週期內的目標以及那些功能和任務需求要完成
• 主要角色: ST, PO, SM
• 主要輸入: Product backlog, 團隊的能力
• 主要輸出: Sprint Backlog

衝刺會議分兩個部分 
1. 解決本次衝刺要完成哪些需求 
2. 解決這些選擇的需求要如何被完成

案例

故事點估算

故事點是表述一個使用者故事, 一項功能或一件工作的整體大小的一種度量單位. 數值本身不重要, 重要的是這些故事之間對比體現相對大小.

計劃撲克

• 開始時, 美人得到一張撲克, 上面有任務點(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 無窮).?代表無法估算, 無窮代表故事太大
• 開始對故事進行估算, 先由PO介紹這個故事的描述. 接著澄清問題
• 每一個組員從撲克中挑選可以代表這個故事的卡片, 集體亮牌
• 最高分和最低分的組員像團隊做出解釋
• 全組成員自由討論幾分鐘
• 重新打分, 直到全組統一.

敏捷估算2.0(Agile Estmating 2.0)

• PO像團隊成員介紹每一個使用者故事, 確保所有需求相關的問題都在做估算前得到解決
• 整個團隊參與遊戲: 一次由一人將一個故事卡片放在合適的位置, 規模小的在左,規模大的在右, 一樣大的豎排. 輪流移動故事卡片, 直到整個團隊都認同白板上故事卡的排序為止.
• 團隊將故事點(Story Point)分配給每個故事.

需求訂單(Product Backlog)

記錄使用者需求的列表, 包括產品所有需要的特徵.

• 每一項包含了需求標題, 描述, 重要性, 故事點(或其他表示大小的數字)
• 需求訂單式開放的, 團隊每個成員都可以編寫和維護
• 在整個專案開放生命週期內, 需求訂單需要不斷維護, 管理與跟蹤需求變化

燃盡圖

在專案完成之前, 對需要完成的工作的一種視覺化表示. 燃燒故事點.每天更新一次

• 具備可視性
• 具備風險預估, 提醒團隊目前完成情況
• 具備可估量, 直接顯示當前還需要的時間.

燃盡圖常見問題

每日站立會議(Daily Scrum)

每日站立會議旨在讓團隊統一目標, 協調內部問題的解決, 絕非進度彙報.一般不超過15分鐘.

• 我們上次開會後你都幹了什麼
• 在我們下次開會之前你要做什麼
• 每個你負責的、正在做的任務還剩下多少時間
• 你的工作被阻礙了嗎

任務板(Task board)

• 為專案團隊提供一個便利的工具用於管理他們的工作
• 是團隊成員對本衝刺的工作一目瞭然

任務板通常設立與專案團隊日常工作的公共空間的一面牆上. 任務板上得資訊包括該沖洗計劃完成的使用者故事和相應的任務, 分別解除安裝卡片上, 按照一定的方式貼在任務板上(To Do, In Progress, Done). 團隊成員通過調整任務卡得位置和上面的資訊反映任務的執行情況.

使用者故事卡

每張卡片記錄一條使用者故事, 故事點.

任務卡

每個使用者故事卡片通對應的多個任務卡. 每張卡片記錄一條任務, 到目前為止完成該任務所需的工作量(小時).隨著進展試試更新.

任務板的使用

使用者故事

作為<某個角色>, 我希望<實現何種功能>, 以便<帶來何種價值>.

如: 作為一個使用者, 我希望在每次退出系統前得到是否儲存的提示, 以便所有內容都被成功儲存了.

測試驅動開發(TDD)

先開發測試用例, 然後再開發程式碼