通過上圖我們可以看到Scrum作為各種敏捷實踐方法中最為常用的一種，今天我們也來聊一聊Scrum。

Scrum的歷史可以追溯到1986年《哈佛商業評論》中的一篇文章《新型的新產品開發策略》（The New New Product Development Game，竹內弘高、野中鬱次郎，1986）。這篇文章描述了像本田、佳能、富士施樂這樣的公司是如何通過可伸縮、基於團隊的並行產品開發方式開發出了世界一流的產品。文章同時強調了授權、自組織團隊的重要性，並概要描述了管理在開發過程中發揮的作用。

當然，SCRUM這個詞沒有什麼標準的中文解釋，它是來源於橄欖球中的一個爭球的動作，如下圖。

竹內弘高和野中鬱次郎在New New Product Development Game文章首次提到將Scrum應用與產品開發，他們指出：傳統的“接力式”的開發模式已經不能滿足快速靈活的市場需求，而整體或“橄欖球式”的方法——團隊作為一個整體前進，在團隊的內部傳球並保持前進，這也許可以更好的滿足當前激烈的市場競爭。

上圖是SCRUM的一個典型架構圖，我們可以看到裡面有很多要素，下面我們一一介紹這些要素。

Scrum的3355

3個角色

Product Owner：產品負責人，清楚的知道產品的願景，需要對產品待辦列表的梳理，優化，優先順序排序等負責。決定團隊每個衝刺要完成哪些任務。對於團隊非常重要，決定Why和What。一般可以對應為現有的產品經理和BA的角色。

Scrum Master：Scrum Master是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙。

Team：可以認為是開發團隊，但是一個跨職能的團隊，能夠交付一個端到端的真正對客戶有價值的產品。

3個工件

Product Backlog：是指產品待辦事項的集合，其中事務有優先順序判斷，先處理優先順序高的事項。產品待辦列表源自於Scrum方法。在Scrum中，產品主管（Product Owner）收集來自於各方的需要、期望、訴求等等到產品待辦列表中，給定優先順序；當衝刺計劃會議上，團隊從產品待辦列表中挑選其中事項組成衝刺待辦列表。常見的待辦事項表達形式是使用者故事。

Sprint Backlog：每個迭代的功能開發列表，PO會根據團隊的能力並按照產品待辦列表中的優先順序來選取每個衝刺要做的事情。團隊可以專注在每個迭衝刺要走的事情上而不被打斷。

Burndown chart:燃盡圖，在每個迭代顯示剩餘工作時間和任務完成情況。

5個價值觀

專注：每個迭代只專注於迭代要完成的事情，團隊和個人的能力和精力是有限的，在有限的時間內專注於最有價值的事情，以取得好的結果。

勇氣：要有勇氣去面對各種挑戰。

公開：團隊所有的進展，問題，阻礙都是對所有人視覺化，透明的。這樣的團隊才是彼此尊重。同時也能暴露問題。

承諾：作為一個自組織團隊，在迭代開始的時候做出承諾，並在迭代中全力完成。

尊重：團隊是長期坐到一起，並且穩定的，有助於加深彼此的瞭解和溝通。

5種工件

Sprint:衝刺,一個固定的時間週期（通常為2w-4w）,團隊要儘可能在這個週期內交付可以工作的軟體給客戶

sprint planning meeting:衝刺開始的時候，PO會和團隊一起從PB中選擇本次要做的任務/故事，並且會對團隊提出的疑問進行解釋和澄清。同時團隊會估算故事並分解成任務，最後會形成本次的Sprint Backlog.

daily standupo meeting:每日站會，scrum為了加強團隊溝通，每天團隊都要選擇一個時間站在一起，互相交流彼此的進展和問題,以便及時解決出現的問題，同時也能讓團隊隨時瞭解我們離衝刺目標還有多遠。

sprint review:在sprint週期最後，需要進行一次評審會議，讓團隊向產品負責人和利益相關者展示已完成的功能。sprint稽核的大部分實踐用於團隊成員展示功能、回答利益相關者對展示的疑問並記錄所期望的更改。評審會議可以吸引相關利益者的關注，讓其他人瞭解團隊在做些什麼，並得到重要反饋。做演示也會迫使開發團隊真正完成一些工作。

retrospective meeting:回顧會議，通常在reivew會議之後開始，有團隊成員在衝刺結束之後對上個迭代進行總結，同時提出一些改進方案，這是一個持續改進的過程。

SCRUM的其他一些要素：

user story:使用者故事，因為敏捷要求每個特性都是對客戶有價值的，所以以使用者故事的方式來設計特性，通常是作為客戶，我要實現A功能，以至於我可以達到什麼目的的結構。

task:每個迭代中為了開發一個user story,將其分解為一些task,比如說我要開發一個協議，其中需要幾個task,包括搭建伺服器，找一些開原始碼，搭建自動化測試框架，編碼，測試任務，便於更小粒度的track每個迭代的進展。

release planning:在某些大型組織，可能更關注release級別的產品交付，所以每個release之前要進行整個release的plan,決定這個release的PB。

points:故事點數，代表使用者故事的大小，要記住，這裡的大小不代表開發時間，只是一個相對的使用者故事的複雜度，工作量大小。因為很難理解，所以scrum team要建立一個基準的user story，作為一個points，然後其他的user story和它進行相對比較。這個points大部分時間用來作為評估team的交付能力。

SCRUM開發流程：

Scrum 是一個用於開發和維持複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱為一個Sprint，每個Sprint的建議長度是2到4周(網際網路產 品研發可以使用1周的Sprint)。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。Scrum團隊總是先開發對客戶具有較高價值的需求 。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先順序的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將遞交 潛在可交付的產品增量。

SCRUM各個角色之間的關係和作用：

PO和team的關係：一個人拿到了客戶的一個專案，開發一個產品，他就是ＰＯ，他想找一個團隊開做這個產品，但是現在有Ａ團隊和Ｂ團隊，Ａ團隊跟PO說，ok,交給我吧，3個月後你過來，我們把產品給你.而B團隊說，我們每個月都可以讓你看一下我們的產品，但是可能一開始功能不完善，但是可以工作的，然後你可以把我們的產品給客戶看，如果運氣好的話客戶可能先給你點錢呢。

如果你作為PO，你會選擇哪個團隊呢？對了，A就是傳統的開發團隊，而B則是我們的scrum team.

scrum master和team還有PO的關係：

個人給SM有以下幾個定義：

Team Coach: 不僅在在流程上輔導團隊，還要幫助大家接受敏捷開發理念，推動團隊按照敏捷價值觀和原則所倡導的方法來做出決策。

Servant Leader：Scrum Master服務於團隊，幫助團隊解決工作中的困難，引導團隊自組織的高效完成每日工作，但是並不是團隊的管理者。

Team Protector: 作為團隊保護者，SM7要敢於說不，儘量保證團隊在每個衝刺中不被打擾，如果發現有影響團隊工作的臨時任務，一定要站出來保護團隊。

SCRUM大事表：

Jeff Sutherland在 1993年首次在Easel公司定義了用於了軟體開發行業的Scrum流程，並開始實施

1995年Jeff Sutherland和Ken Schwaber規範化了Scrum框架，並在OOPSLA 95上公開發布。

2001年 敏捷宣言及原則釋出、敏捷聯盟成立，Scrum是其中一種敏捷方法。

2001年，Ken Schwaber和Mike Beedle推出第一本Scrum書籍《Scrum敏捷軟體開發》。

2002年Ken Schwaber 和Mike Cohn共同創辦了Scrum聯盟。