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
注：以上內容來網絡，本人不承擔任何連帶責任
文章轉自：http://www.cnblogs.com/Ring1981/archive/2006/09/07/496591.html