什麼是SCRUM

首先要知道SCRUM是敏捷開發的方法論之一。
在學習SCRUM之前我們需要簡單儲備一下基本的知識。
什麼是敏捷開發？
敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。
怎麼理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去一步一步完成專案的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發；

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

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

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

什麼是Scrum？
Scrum是一種靈活的敏捷軟體開發管理過程。這個名詞來源於英式橄欖球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，而Scrum就是這樣的一個開發流程，運用該流程，你就能看到你團隊高效的工作。它將軟體開發團隊比作橄欖球隊，全隊有明確的最高目標：釋出產品的重要性高於一切。團隊高度自治，隊員們熟悉開發過程中涉及到的各種技術，緊密合作，確保每個迭代都朝著最高目標推進。而且每隔2至6周，每個人都能看到能實際工作的軟體，並且據此決定是釋出這個版本還是繼續開發以加強它的功能。

敏捷的四大宣言是什麼，滿足四大宣言符合十二準則的即屬於敏捷：

TechTarget中國原創內容，原文連結：http://www.searchcio.com.cn/showcontent_54322.htm
敏捷宣言，也叫做敏捷軟體開發宣言，正式宣佈了對四種核心價值和十二條原則，可以指導迭代的以人為中心的軟體開發方法。
　　敏捷軟體開發關注保持簡潔的程式碼，經常性測試以及及時地交付應用的功能模組。敏捷宣言的建立是為了替代文件驅動的繁重的軟體開發流程，例如瀑布式方法。
　　敏捷宣言強調的敏捷軟體開發的四個核心價值是：
　　·個人和互動高於流程和工具
　　·工作軟體高於詳盡文件

　　·客戶協作高於合同談判
　　·變化響應高於遵循計劃

　　敏捷選擇提出的12條原則已經應用於管理大量的業務以及與IT相關專案中，包括商業智慧（BI）。12原則包括：
　　1.通過早期和連續型的高價值工作交付滿足“客戶”。
　　2.大工作分成可以迅速完成的較小組成部門。
　　3.識別最好的工作是從“自組織的團隊”中出現的，
　　4.為積極員工提供他們需要的環境和支援，並相信他們可以完成工作。
　　5.建立可以改善可持續工作的流程。
　　6.維持完整工作的不變的步調。
　　7.歡迎改變的需求，即時是在專案後期。
　　8.在專案期間每天與專案團隊和業務所有者開會。
　　9.在定期修正期，讓團隊反映如何能高效，然後進行相應地行為調整。
　　10.通過完成的工作量計量工作進度。
　　11.不斷地追求完善。
　　12.利用調整獲得競爭優勢。

SCRUM適用於大中小型專案，在SCRUM中最核心的是團隊架構和軟體研發框架。

原文參考：http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html
什麼是Sprint？
Sprint是短距離賽跑的意思，這裡面指的是一次迭代，而一次迭代的週期是1個月時間（即4個星期），也就是我們要把一次迭代的開發內容以最快的速度完成它，這個過程我們稱它為Sprint。
Product backlog:產品需求列表，產品待開發項(Product Backlog)，產品需要完成的所有使用者故事的集合，使用者故事有大有小，有史詩級的也有小粒度級別的：根據初始需求分解出的任務列表，包括功能性的和非功能性的所有功能； 由Product Owner為Product Backlog中的任務確定優先級別；當開發團隊開始做某個任務的時候，再精確定義和分解這個任務。
Product Backlog是產品所要具備的所有功能的總綱。當一個專案剛剛開始時，沒人能夠事先預見到所有的任務和需求，併為之做一個充分、詳細而又包羅永珍的計劃。可行的方式是，先為一個專案寫下所有它應該具備的顯著特徵和功能，數量不必很多，最好夠讓團隊的第一個Sprint有活可幹。隨著Sprint的進行，生產出可釋出的產品增量，客戶對產品的直觀認識也隨之加深，他們可以據此建議更改或者新增產品Backlog中的任務。
在Sprint計劃會議上，產品負責人人為產品Backlog中的任務確定優先順序，並向Scrum團隊描述這些任務。Scrum團隊隨後根據團隊整體情況，確定他們能在這個即將到來的Sprint中完成哪些功能，並把它們挪到Sprint Backlog中去。如下圖：

迭代任務 Sprint backlog: sprint 待辦列表或衝刺待辦列表，sprint中需要完成的所有使用者故事的集合，sprint的使用者故事都應該在該sprint中完成，並且都有滿意條件。
迭代計劃會(Sprint Planning Meeting) ：在每個Sprint開始之前，需要召開Sprint計劃會議，一般為4至8個小時。參加人員有產品責任人、Scrum Master、Scrum團隊和其他感興趣的人，比如管理層人員和客戶代表。Product Owner從產品Backlog中挑選優先度高的任務，並與Scrum團隊一起決定在這個Sprint中需要完成多少功能；Scrum團隊將這些任務分解成小的功能模組； Scrum團隊成員詳細討論如何能按需求完成這些功能模組，並估計完成每個功能模組所需的大概時間。
Dally meeting:日會議，每日站立會議。如下圖：

上圖就是每日的站立會議了，既團隊每日例會，條件允許的話，每天都應該在同樣的時間和地點，所有成員站立著舉行。由於是站立的狀態開會，因此時間比較短，一般為15分鐘左右。這個會議最好是在每天的早晨開，有利於團隊成員們安排好當天的工作計劃。只有團隊成員可以在每日Scrum會議上發言，其他人員如果對專案進度有興趣也可以參加，但只能旁聽而不能發言。
會議由Scrum Master主持，Scrum團隊的所有成員輪流回答上圖中的三個問題，即：
- 昨天我完成了什麼工作；
- 今天我打算做什麼；
- 我遇到了什麼障礙；
通過這三個問題，團隊成員之間可以彼此相互熟悉工作內容，充分了解專案進度，相互幫助解決問題。Scrum Master除了傾聽團隊成員的發言外，他還有責任設法解決團隊成員在會上提出的困難，儘快掃除阻礙他們工作的障礙。即使有的問題Scrum Master沒有能力解決，例如某些技術細節問題等，他也應該找到團隊中或其他團隊的來幫助快速的解決問題。另外，還有兩點需要注意的地方：其一，這是團隊成員之間的交流，也是相互的承諾，並不是用來向老闆彙報工作進度的；其二，這也不是一個專門用於解決各種問題的會議，成員們遇到的問題可以在會上提出來，而有能力解決這些問題的人可以在會後幫助他們解決問題。
參會人員可以隨意姿勢站立，任務看板要保證讓每個人看到，當每個人發言完後，要走到任務版前更新自己的燃盡圖，如下圖：

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

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

Sprint burn down：sprint燃盡圖，也就是完成的sprint工作，
Sprint 4 weeks：指的是一個sprint執行的進度，可以根據具體的專案定義。這裡意思是1個月，怎麼估算理想的時間呢，可以通過計劃紙牌遊戲確定，如下圖：

上圖可不是撲克牌，它是計劃紙牌，它的作用是防止專案在開發過程中，被某些人所領導。
怎麼用的呢？比如A程式設計師開發一個功能，需要5個小時，B程式設計師認為只需要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，如果時間差距很大，那麼A和B就可以討論A為什麼要5個小時…
Sprint review meeting：sprint審查會議，就是要演示並稽核是否完成。Sprint結束時召開；由開發團隊展示這個Sprint中完成的功能；長度為兩個小時左右；不需要PPT；一般是已完成的功能的Demo； 誰都可以參加：客戶、管理層、Product Owner、其他開發人員等等。
在每個Sprint結束時，應該組織一個Sprint評審會議。Scrum開發團隊將在會上展示他們在這個Sprint中所做的工作。一般採用向大家演示產品新功能的方式來展示。
相對來說，Sprint評審會議不必很正式。通常不需要用到PPT幻燈片，而且長度最好控制在兩個小時之內。也就是說，不要讓Sprint評審會議成為Scrum團隊的負擔，他們不必花太多時間來準備這個會議。
Sprint評審會議的參與者，可以包括所有對該產品感興趣的人：產品責任人，Scrum團隊，利益相關者，管理層人員，客戶，甚至來自其他專案的開發人員等等。
在Sprint評審會議上，Scrum團隊用Demo的形式展示產品的新功能之後，與會人員依據在Sprint計劃會議上確定的本Sprint的目標來評審具備了這些新功能的產品。
為什麼一定要用Demo的形式來展示產品的新功能呢？因為這種方式有很多好處：
首先，參與會議的人都能直觀的看到Scrum團隊的工作成果；其次，利益相關者們可以據此提出更切合實際的反饋意見；第三，為了完成Demo，團隊會努力完成併發布那些功能，即使只是釋出在測試環境下，也比沒完成的好。如果不做Demo，也許不少功能會停留在“已完成99%”的階段。相比較起來，在有Demo的情況下，也許“已完成”的功能數量會相對少一些，但它們是確確實實完成了的，否則，那些“99%”的貌似完成的功能勢必還要拖到下個Sprint來解決。
假如有一個剛從傳統的開發模式轉而採用Scrum的團隊，由於不習慣這種自我約束、自組織的方式，在Sprint中並沒做多少工作，那麼在會上演示的時候，他們會覺得很尷尬。沒準老闆看到他們花了這麼多時間只做了這麼少的工作而感到很生氣。發生這種情況當然是大家都不想看到的，但良藥苦口，在下一個Sprint中，這個團隊肯定會吸取教訓，他們會明白無論什麼情況下都必須Demo，那麼他們必然會很好的完成這個Sprint並演示給大家看。
Release：可以執行的版本。
通過上圖可以構件SCRUM在實際開發工作中是怎樣執行的，如何通過Scrum指導開發？：

1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），專案開發過程中需求的改變也要寫進去，在每個迭代(Sprint)開始之前，要開一個迭代計劃會議(Sprint Planning Meetting)。在會上，產品責任人(Product Owner)為 Product Backlog中的各功能需求確定優先順序(或者是在會前完成)；
2、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story（使用者故事）作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個Story進行細化；
3、隨後Scrum開發團隊（“自組織的開發團隊”）按照優先順序，從Product Backlog中挑選出他們認為能在本次迭代中完成的任務，根據Product Backlog列表，做工作量的預估和安排,把它們從Product Backlog中挪到Sprint Backlog中來,形成一個Sprint Backlog；
4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成，最好是精確到小時）；
5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面彙報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）。剛開始由產品負責人或這SCRUM Master主持，熟悉幾天後可以每個人輪流組織站立會議，提高大家參與感，方式在實際工作中越開越失去意義，站立會議是根據實際情況而確定的，在專案開始之前或者專案釋出時候，問題多且複雜，可以半天開一次站立會議；
6、做到每日整合，也就是每天都要有一個可以成功編譯、並且可以演示的版本；很多人可能還沒有用過自動化的每日整合，其實TFS就有這個功能，它可以支援每次有成員進行簽入操作的時候，在伺服器上自動獲取最新版本，然後在伺服器中編譯，如果通過則馬上再執行單元測試程式碼，如果也全部通過，則將該版本釋出，這時一次正式的簽入操作才儲存到TFS中，中間有任何失敗，都會用郵件通知專案管理人員；
7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）；
8、最後就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；

SCRUM團隊架構

傳統的專案團隊架構模型，示例如下:

實際的專案團隊架構模型，示例如下:

虛線可能是專案經理兼職，灰色可能大部分沒有或者可有可無。

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

產品負責人（Product Owner）
主要負責確定產品的功能和達到要求的標準，指定軟體的釋出日期和交付的內容，同時有權力接受或拒絕開發團隊的工作成果。提供願景，提供邊界，提供User Story優先順序。特別注意：需要和開發團隊溝通需求，需要考慮研發團隊的研發能力，也就是不能壓榨技術團隊，不能強制或者強迫加班加點。
流程管理員（Scrum Master [ SM ]）
主要負責整個Scrum流程在專案中的順利實施和進行，以及清除擋在客戶和開發工作之間的溝通障礙，使得客戶可以直接驅動開發。沒有行政權利（也就是說無法解僱員工），訓練團隊正確的做事方法，遵循SCRUM流程和做事原則，不代替團隊做決定。特別注意：要忍住幫團隊做決定的衝動，產品負責人和SCRUM Master不建議是同一人。
“自組織”的開發團隊（Scrum Team）
主要負責軟體產品在Scrum規定流程下進行開發工作，人數控制在5~10人左右，每個成員可能負責不同的技術方面（基本角色包括：需求分析師，業務分析師，程式設計師，測試人員，軟體架構，DBA，使用者體驗師），但要求每成員必須要有很強的自我管理能力，同時具有一定的表達能力；主動與產品負責人，SM溝通，能夠從大局出發，自覺完成工作，成員可以採用任何工作方式，只要能達到Sprint的目標。開發團隊不是編碼完就完成了。而是完成後要和團隊一起溝通，演示並保證滿意條件，最後提交可交付的產品並整合。在這個過程中一定要主動積極。
SCRUM Team的特點包括：
一起討論需求。跨職能工作。自我管理，主動工作。團結合作，學習進步。注重團隊承諾。一榮俱榮，一損俱損。
團隊協作示例：

SCRUM最佳實踐

User Story

SCRUM在需求方面的核心理念

1. 需求是湧現的
   
   • 不要試圖在專案初期就明確所有需求。
   • 通過使用者故事來組織及細化需求
2. 將些需求轉變為討論需求
   
   • 使用使用者故事來討論需求
   • 所有人都參與討論需求，持續明確需求細節

使用者故事

示例：
作為網站所有者，我希望系統可以統計廣告點選率，以便我能清楚廣告收益。
標準格式及作用
- 作為—-角色（作用：可以通過使用者的角度來思考問題）
- 希望可以—-目標（作用：思考系統有什麼功能，達到什麼效果）
- 以便—-原因（作用：思考該功能對於該使用者有什麼實質的價值）

使用者故事的難點

需求是由大大小小的使用者故事組成，最開始的往往是個史詩級別的“大故事”，需要拆分成中故事，小故事。
難點：
1. 發現和提煉使用者故事。
2. 由粗到細的拆分使用者故事。
3. 安排使用者故事優先順序，安排到不同的sprint中去實現。

如何寫出第一個使用者故事

實戰：網上售票系統，寫出一個使用者故事。
參考答案：作為*XX局長，我希望做一套網上售票系統，以便*更高的為人民服務。

開始分解使用者故事

細分 “以便…”這部分
反向思考 “我希望..”這部分
進行系統涉眾（也就是干係人）分析，列出關鍵使用者
思考各使用者在本產品上的利益所在
思考“希望….”（目標）部分。
思考“以便…”（原因）部分，確認“希望…”這部分是否合適。也就是反向思考目標和原因是否匹配。

Sprint

一個sprint就是一個小版本，建議時長是1個月，也可以更短。
一個sprint不是一個小“瀑布”，很難區分需求、設計、編碼或測試階段。所有工作都基於對使用者故事的討論。測試先行，測試驅動，單元測試必不可少。設計也是“湧現”式的，不是一次性做好了就好，也是不斷改進的。
產品負責人和SCRUM自組織的團隊商量並確定每個sprint的使用者故事。
怎麼估算使用者故事呢？
- 精確估算有“滿意條件”的使用者故事。
- 精確估算在sprint中的使用者故事。
- 粗略估算或暫不估算大、中故事。
- 估算由SCRUM“自組織的團隊”負責。
- 精確估算時單位最好為小時，粗略估算時單位最好為天。

Burn Down Chart（燃盡圖）

用來跟蹤sprint中未完成工作的情況。每做完一個sprint的使用者故事就燒掉，最後燒完sprint也就完成了。如下圖，每一個點代表一個使用者故事，或者故事點，或者可度量的工作量。所有點組成sprint。我個人認為以使用者故事為一個點，因為sprint backlog中的使用者故事已經是一個很喜歡的使用者故事了，所以可以作為度量圖。有人也有根據故事點做度量圖，故事點就是拿出使用者故事中的一個點作為基準故事點（最好找出可以正好1天完成的點），然後將使用者故事中的所有點與這個基準點去比較，如果比基準點難就估算為1.x天，如果比基準點easy就估算0.x天等等。。。

其他

結對程式設計

這個就是兩個程式設計師用一臺電腦程式設計，
優點：
一個程式設計另一個同時評審及優化，輪流開發工作
同一段程式碼兩個人熟悉
兩個人互相切磋和互相學習。

持續整合

或者說Daily build每日整合
符合四大宣言之一可用的軟體比詳盡的需求更優。

測試驅動，測試自動化