通過上圖我們可以看到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聯盟。