一 什么是Scrum?
Scrum (英式橄欖球爭球隊), 軟件開發模型是敏捷開發的一種，在最近的一兩年內逐漸流行起來。
Scrum的基本假設是：
開
發軟件就像開發新產品，無法一開始就能定義軟件產品最終的規程，過程中需要研發、創意、嘗試錯誤，所以沒有一種固定的流程可以保證專案成功。Scrum
將軟件開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典范與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰，
確保每天、每個階段都朝向目標有明確的推進。
Scrum 開發流程通常以 30
天(或者更短的一段時間)為一個階段，由客戶提供新產品的需求規格開始，開發團隊與客戶于每一個階段開始時挑選該完成的規格部分，開發團隊必須盡力于
30 天后交付成果，團隊每天用 15 分鐘開會檢查每個成員的進度與計劃，了解所遭遇的困難并設法排除。
二 Scrum較傳統開發模型的優點
Scrum模型的一個顯著特點就是響應變化，它能夠盡快地響應變化。下面的圖片使用傳統的軟件開發模型(瀑布模型、螺旋模型或迭代模型)。隨著系統因素（內部和外部因素）的復雜度增加，項目成功的可能性就迅速降低。
下圖是Scrum模型和傳統模型的對比：
三 Scrum模型
一) 有關Scrum的幾個名詞
backlog: 可以預知的所有任務， 包括功能性的和非功能性的所有任務。
sprint:一次跌代開發的時間周期，一般最多以30天為一個周期.在這段時間內，開發團隊需要完成一個制定的backlog,并且最終成果是一個增量的，可以交付的產品。
sprint backlog:一個sprint周期內所需要完成的任務。
scrumMaster: 負責監督整個Scrum進程，修訂計劃的一個團隊成員。
time-box: 一個用于開會時間段。比如每個daily scrum meeting的time-box為15分鐘。
sprint
planning meeting:
在啟動每個sprint前召開。一般為一天時間（8小時）。該會議需要制定的任務是：產品Owner和團隊成員將backlog分解成小的功能模塊,
決定在即將進行的sprint里需要完成多少小功能模塊，確定好這個Product
Backlog的任務優先級。另外，該會議還需詳細地討論如何能夠按照需求完成這些小功能模塊。制定的這些模塊的工作量以小時計算。
Daily Scrum meeting：開發團隊成員召開，一般為15分鐘。每個開發成員需要向ScrumMaster匯報三個項目：今天完成了什么？ 是否遇到了障礙？ 即將要做什么？通過該會議，團隊成員可以相互了解項目進度。
Sprint review meeting：在每個Sprint結束后，這個Team將這個Sprint的工作成果演示給Product Owner和其他相關的人員。一般該會議為４小時。
Sprint retrospective meeting：對剛結束的Sprint進行總結。會議的參與人員為團隊開發的內部人員。一般該會議為３小時。
二）實施Scrum的過程簡單介紹
1) 將整個產品的backlog分解成Sprint Backlog,這個Sprint Backlog是按照目前的人力物力條件可以完成的。
2) 召開sprint planning meeting，劃分，確定這個Sprint內需要完成的任務，標注任務的優先級并分配給每個成員。注意這里的任務是以小時計算的，并不是按人天計算。
3) 進入sprint開發周期，在這個周期內，每天需要召開Daily Scrum meeting。
4) 整個sprint周期結束，召開Sprint review meeting，將成果演示給Product Owner.
5) 團隊成員最后召開Sprint retrospective meeting，總結問題和經驗。
6) 這樣周而復始，按照同樣的步驟進行下一次Sprint.
整個過程如下圖所示：
The diagrams in this article are all from web site:
http://www.controlchaos.com. Thanks very much!
參考：
http://www.controlchaos.com/about/
http://www.microsoft.com/Taiwan/msdn/columns/200311softdev.htm
另外一篇：
Scrum是一種靈活的軟件管理過程，它可以幫助你駕馭迭代，遞增的軟件開發過程。這個輕量的過程可以作為包裝器，也就是說你可以把Scrum與其它靈活的過程框架組合起來，比如說RUP。
RUP（Rational Unified Process，Rational 統一過程），是一種被廣泛使用的軟件過程框架。它可以很好地迎合你的軟件開發過程的需要，還可以容納其他技術。Scrum是一系列有趣的，用來包裝靈活軟件項目的項目管理模式。
Scrum
提供了一種經驗方法，它使得團隊成員能夠獨立地，集中地在創造性的環境下工作。它發現了軟件工程的社會意義。這一過程是迅速，有適應性，自組織的，它代表
了從順序開發過程以來的重大變化。Scrum認為軟件的開發不應使用和一般制造業相同的方法，也就是不應采用一種反復的模式。這種重復使得輸入和輸出參數
更加容易預測和描述，但這并不是當今軟件工程的有益目標。現代軟件工程的主要挑戰包括上市時間，投資回報，以及影響顧客的需要等。RUP和其他敏捷軟件工
程過程能夠很好地迎接這些挑戰。
Scrum區別于其他開發過程之處是什么？最顯而易見的不同將是每天的短會，通常在每天的同一時間在同一個房間內舉行。這個會議也叫Scrum，在會議中每個團隊成員僅就以下三點發言：
自上次Scrum會議后你做了什么？
從現在到下次Scrum會議的時間里你準備做什么？
你在工作中遇到了哪些困難？
Scrum團隊的組成
由
于一個Scrum團隊最多由7人組成，會議應當不超過15分鐘。Scrum管理者*主持會議，并且對整個項目的成敗負責。他傾聽每個成員的發言并設法解決
會議中提到的各種障礙。Scrum管理者在會上對障礙提出即時的解決方案或指導，使團隊不斷向著目標前進。Scrum會議不同于項目會議，對團隊來說，它
起到了快速簡報的作用。如果問題得不到解決，團隊成員應向Scrum管理者或大項目成員提出質疑。
只有團隊成員可以在Scrum會議上發言，但是允許有旁聽者。對于人數多于7人的項目團隊，Scrum建議與其擴大團隊規模不如將團隊分組。分組可
依據功能，結構主體，或者應用，包括子應用等進行。分組后各個子團隊就可以并行工作了，而且Scrum管理者可以通過Scrum會議對各個子團隊的工作進
行同步。Scrum甚至可以兼顧在其他地方工作的團隊成員。
Scrum團隊不止是一個程序員隊伍，它由各種背景下的不同角色組合而成，包括商業分析者，設計師，程序員和測試者等等。更多時候，成員可以身兼多職；正確的組合決定了團隊的能力和效率。
項目規劃
Scrum的迭代過程被稱為“疾跑”，時間為30天。在RUP中，迭代過程通常在2至6周之間，每次“疾跑”都以獲得可執行可測試的代碼為結束。
產品擁有者持有產品訂單，他控制并區分功能的開發次序，但是工作量的評估是由Scrum團隊來完成的。產品風險的所有承擔者，包括Scrum團隊和產品所有者，共同檢視訂單，然后根據優先級次序決定先開發哪一功能。除去優先級，RUP的迭代規劃過程也是基于風險的。
現在團隊定義的“疾跑”目標已經成為了進展控制的指導。“疾跑”過程一旦開始，團隊全部與外界的交流都必須經由Scrum管理者進行。Scrum管理者務必保證團隊能夠專心于既定目標而不受外界干擾。
Scrum團隊持有自己的“疾跑”訂單，上面記錄了更多關于待實現目標的具體任務的細節。在團隊對“疾跑”的作用有更多了解以后，團隊成員就可以調整原始的產品評估，并將“疾跑”過程中獲得的信息加入到產品訂單中。這些做法對Scrum進度回溯都是有益的。
Scrum團隊由每天的Scrum會議，每月的“疾跑”計劃和“疾跑”審查會議緊密相連，鑒于此，整個組織必然存在一種縱向的透明度。這就使得組織
上的問題和挑戰清晰明顯。由于團隊成員都親自觀察整個項目，交流也就變得簡短，迅速和有效。團隊是自組織的，著眼于“疾跑”的目標，這樣就最大限度發揮了
每一個團隊成員的作用。Scrum管理者充當一個問題和交流的“票據交換所”，而不是一個控制整個團隊的老板。
“疾跑”審查會議持續半天。在會上，團隊向項目的風險承擔者展示完成的功能模塊。團隊按照既定的“疾跑”目標來演示完成的內容。
訂單，“疾跑”計劃和回顧，管理承諾，每日Scrum會議，進度回溯，以及其他Scrum技術都是基于主要用于軟件項目管理的進程模式的。這些模式在過去的大小項目和不同商業領域中都獲得了成功。