Scrum是一個用于開發和維護復雜產品的框架，是一個增量的、迭代的開發過程。迭代是貫穿敏捷管理的一個特有概念，Sprint是沖刺跑的意思，在敏捷里指的是一次迭代，而一次迭代的周期一般是2~4周，也就是要把一次迭代的開發內容以最快的速度完成它，這個過程我們稱為迭代。Scrum團隊試圖在每一個迭代中都構建出一個潛在可交付、并且充分測試過的產品增量。

圖1. 敏捷流程人員構成

Scrum團隊，又叫Scrum Team，是Scrum的基本單位，一般都是小團隊，這個團隊雖小，但是麻雀雖小，五臟俱全，這是一個跨職能的團隊，這個團隊具有完成每個迭代所創造的價值的全部技能。 他們是自管理的，這意味著他們在團隊內部決定誰做什么、何時做以及如何做。

一般Scrum團隊都是10個人左右，這已經是最小單元，沒有子團隊或結構層次了，規模足夠小可以保持靈活，同時也足以完成一個迭代中重要的工作。小的團隊溝通更好，效率更高，如果有問題，站起來直接喊、然后開始討論把事情解決了。

Scrum團隊是具有凝聚力的專業團體，作為一個整體，每個成員都非常重要，大家互相配合一次專注于一個目標，即產品目標。在團隊中，三種角色有不同的分工，由一名流程管理員（Scrum Master），產品負責人（Product Owner），開發團隊（Dev Team）組成來完成每一次迭代，產出每一次增量，完成每一次目標。

圖2. 敏捷團隊角色

產品負責人：定義所有產品功能，決定產品發布的內容以及日期，對產品的投入產出負責，根據市場變化對需要開發的功能排列優先順序，合理地調整產品功能和迭代順序，認同或者拒絕迭代的交付。

ScrumMaster ：指導項目組的成員按照Scrum的原則、方法做事情，領導團隊完成Scrum的實踐以及體現其價值，排除團隊遇到的困難，確保團隊勝任其工作，并保持高效的生產率，使得團隊緊密合作，使得團隊個人具有多方面職能的工作能力，保護團隊不受到外來無端影響。

開發團隊：一般有 5-9 人，團隊成員包含程序員、測試員、用戶體驗設計等等，由一批跨職能的人組成，他們擁有完成每個產品增量所需的全部技能。開發團隊成員需要以自組織的方式實現Sprint目標，根據Sprint的計劃完成產品增量。產品負責人準備一個有序的代辦事項列表。開發團隊成員共同預測在一個Sprint里能完成的工作量，并決定如何實現。

在Scrum團隊中，有三種角色，Scrum Master作為主導者，驅動著團隊前進，而Product Owner作為業務方代表，提供需求，最終讓開發團隊把需求實現，作為一個Scrum團隊，大家一起配合完成任務，交付成果。

不同于瀑布模型將開發過程劃分為需求、設計、編碼、測試等階段，Scrum將整個開發過程分為多次迭代（稱為Sprint，沖刺），一般為期2～4周，最常見的為2周。Scrum并非以一段時間集中完成一個過程，而是將所有過程中必須的每一部分集中在這段時間內完成。需求、設計、編碼、測試、上線都必須在一個迭代中完成，每個迭代必須產生一個可以工作的軟件。

Scrum的整個過程主要分成五大會議，如下圖所示。這些會議均由在這些會議上不具備決策權的ScrumMaster來負責引導。

圖1. Scrum流程相關會議

待辦事項整理會議（Backlog Refinement Meeting）

大多數產品在規劃時都是切分為大且模糊的主題，也稱史詩級故事（epic）。經驗中發現，可以在每個迭代的執行過程中都拿出點時間召開待辦事項整理會議，用于為下一個迭代計劃會議做準備。在待辦事項修整會議上，圍繞著產品列表上的主題，產品負責人、Scrum Master和少部分關鍵開發者，先把功能清單理一理、拆一拆，需要把主題功能拆分為可代表產品特性的多個用戶故事。

由產品負責人將一批希望團隊在下次迭代時實現的用戶故事，按照實現順序描述給團隊成員，開發團隊分析用戶故事需要包含哪些技術任務，由Scrum Master建立子任務，方便迭代計劃會議的時候團隊可以更準確的預估任務故事點。

在會議結束時，產品負責人需要確認會議中提出的需要完善的問題在迭代計劃會議開始之前都能被解決，而不浪費迭代計劃會議的時間去做這件事情。

圖2. 需要大塊的史詩故事進行拆分

迭代計劃會議（Sprint Planning Meeting）

產品負責人建立產品功能清單（Product Backlog），是一組條目化的需求，它必須從客戶價值角度描述，并按優先級排序。每個迭代在剛開始的時候，Scrum Master召集相關人員和開發團隊一起召開迭代計劃會議，討論在這個迭代中想要把產品的哪些功能清單列為待辦事項，并估算本次迭代的工作量。

產品負責人需要講清楚對于業務來說哪些需求是最重要的，開發團隊則負責選定在不積累技術債務的情況下可完成的工作，估算Backlog所需工作量，將工作從“產品清單”中拉入Sprint列表，直到本迭代工作量達到飽和。

產品負責人參與討論并回答和需求相關的問題，但不干擾估算結果。由組長協商分發，或隊員自行認領任務，獨立或與其他成員一起完成任務。

會議時長盡量控制在1-2個小時之內。

圖3. Sprint計劃會議的交付物是產品功能清單和迭代任務清單

每日站會（Daily Scrum）

每天在相同時間相同地點讓團隊成員們花費15分鐘相互溝通進度，每位成員都要總結他昨天做了什么、今天將要做什么、以及是否遇到了阻礙。站著開日會，有利于保持會議簡短，如果有額外討論的話題可以等所有人報告完之后感興趣的人再繼續討論。Scrum開發團隊利用燃盡圖來展示整體進度，每天進行簡短會面來檢驗工作進程，并調整后續步驟以確保能如期完成剩余工作。

迭代評審會議（Sprint Review）

在Sprint的結尾，產品負責人、Scrum Master、開發團隊，可能還有客戶一起評審這個迭代的結果。小組向產品負責人展示迭代工作結果，產品負責人給出評價和反饋，以用戶故事是否能成功交付來評價任務完成情況。未完成的任務會被打回PBI，然后再根據產品負責人的最新優先級順序判斷是否放入后續迭代。任何參與者都可以問問題和提意見，時間控制在1-2個小時之內。

迭代回顧會議（Sprint Retrospective）

敏捷開發的一個原則是“可持續的步伐”，迭代之間沒有間歇期，團隊通常在迭代結束的某個下午召開回顧會議，第二天早上就直接進入下一個迭代計劃會議。這是一個簡短的反思會，總結哪些事情做得好，哪些事情做的不好。做得好的保留，不好的摒棄。團隊中的每個人將在會上反思自己的工作，并決定開始做什么、繼續做什么、停止做什么，采取措施以在下一個迭代中做得更好。時間一般控制在15-30分鐘。

Scrum是一套開發流程，強調的是自組織、自驅動的，團隊只有在實施中不斷地仔細體會，采取應對措施來適應自身團隊的流程。

總結

以上是生活随笔為你收集整理的敏捷基本概念——三大角色五大会议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。