Scrum敏捷開發流程主要包擴三個角色、四個會議和三個物件。

三個角色

Scrum團隊中包括三個角色，他們分別是產品負責人、開發團隊和 專案的直接管理者（Scrum Master）。

Scrum 團隊是自組織、跨職能的完整團隊。自組織團隊決定如何最好地完成他們的工作,而不是由團隊外的其他人來指揮他 們。

跨職能的團隊擁有完成工作所需要的全部技能,不需要依賴團隊外部的人。Scrum 團隊模式的目的是最大限度地優化適應性、創造性和生產力。

Scrum 團隊通過迭代和增量交付產品功能的方法最大化反饋的機會。增量交付潛在可交付的產品增量保證了 每個迭代都有潛在可釋出的版本。

Scrum角色之：產品負責人

產品負責人負責最大化產品以及開發團隊工作的價值。實現這一點的方式會隨著組 織、Scrum 團隊以及單個團隊成員的不同而不同。

產品負責人是管理產品待辦事項列表的唯一責任人。產品待辦事項列表的管理包括:

● 清晰地表達產品代辦事項列表條目

● 對產品代辦事項列表中的條目進行排序,最好地實現目標和使命

● 確保開發團隊所執行工作的價值

● 確保產品代辦事項列表對所有人可見、透明、清晰,並且顯示 Scrum 團隊的下一步工作

● 確保開發團隊對產品代辦事項列表中的條目達到一定程度的理解

產品負責人可以親自完成上述工作,也可以讓開發團隊來完成。然而,產品負責人是 負責任者。

產品負責人是一個人,而不是一個委員會。產品負責人可能會在產品代辦事項列表中 體現一個委員會的需求,但要想改變某條目的優先順序必須先說服產品負責人。

為保證產品負責人的工作取得成功,組織中的所有人員都必須尊重他的決定。產品負 責人所作的決定在產品待辦事項列表的內容和排序中要清晰可見。任何人都不得要求開發 團隊按照另一套需求開展工作,開發團隊也不允許聽從任何其他人的指令。

Scrum角色之：開發團隊

開發團隊包含了專業人員,負責在每個 Sprint 的結尾交付潛在可釋出的“完成”產 品增量。只有開發團隊的成員才能創造增量。

開發團隊由組織構建並授權,來組織和管理他們的工作。所產生的協同工作能最大化 開發團隊的整體效率和效力。開發團隊有以下幾個特點:

他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發團隊如何把產品 代辦事項列表變成潛在可釋出的功能。

開發團隊是跨職能的,團隊作為一個整體擁有創造產品增量所需要的全部技能。

Scrum 不認可開發團隊成員的頭銜,無論承擔哪種工作他們都是開發者。此規則無一例外。

開發團隊中的每個成員可以有特長和專注領域,但是責任歸屬於整個開發團隊

開發團隊不包含如測試或業務分析等負責特定領域的子團隊。

Scrum角色之：Scrum Master

Scrum Master 負責確保 Scrum 被理解並實施。為了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規則。Scrum Master是Scrum團隊中的服務式領導。

Scrum Master 幫助 Scrum 團隊外的人員瞭解他們如何與 Scrum 團隊互動是有益的。 Scrum Master 通過改變這些互動來最大化 Scrum 團隊所創造的價值。

Scrum Master 服務於產品負責人

Scrum Master 以各種方式服務於產品負責人,包括:

● 找到有效管理產品代辦事項列表的技巧

● 清晰地和開發團隊溝通願景、目標和產品代表事項列表條目

● 教導開發團隊建立清晰簡明的產品代表事項列表條目

● 在經驗主義環境中理解長期的產品規劃

● 理解並實踐敏捷

● 按需推動Scrum活動

Scrum Master 服務於開發團隊

Scrum Master 以各種方式服務於開發團隊,包括:

● 指導開發團隊自組織和跨職能

● 教導並領導開發團隊創造高價值的產品

● 移除開發團隊進展過程中的障礙

● 按需推動Scrum活動

● 在 Scrum 還未完全被採納和理解的組織環境下指導開發團隊

Scrum Master 服務於組織

Scrum Master 以各種方式服務於組織,包括:

● 領導並指導組織採用 Scrum

● 在組織範圍內計劃 Scrum 的實施

● 幫助員工及干係人理解並實施 Scrum 和經驗性產品開發

● 發起能提升Scrum 團隊生產力的變革

● 與其他 Scrum Master 一起工作,幫助組織更有效的應用Scrum

四個會議

四個會議指的是Sprint計劃會議、每日例會、Sprint評審會議和Sprint回顧會議。

Sprint計劃會議（Sprint Planning）

在Scrum中，Sprint計劃會議有兩部分：

1. 決定需要完成哪些工作？

2. 決定這些工作如何完成？

第一部分：需要完成哪些工作？

參會人員：團隊、專案負責人（Scrum Master）、產品負責人（Product Owner）

第一部分的會議，產品負責人向開發團隊介紹排好序的產品待辦事項，由整個Scrum團隊共同理解這些工作。

Sprint中需要完成的產品待辦事項數目完全由開發團隊決定。做多少工作只能由開發團隊決定，產品負責人或任何其它人都不能給開發團隊強加更多的工作量。

第二部分：如何完成工作？

參會人員：Team 、Scrum Master

第二部分的會議，開發團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增量。他們進行足夠的設計和計劃，從而有信心可以在Sprint中完成所有工作。

決定如何完成工作是開發團隊的職責，決定做什麼則是產品負責人的職責。

Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數量和複雜度達成共識，最終產生的待辦事項列表就是“Sprint待辦事項列表（Sprint Backlog）”。

Sprint待辦事項列表是一個需要在當前Sprint完成的且梳理過的產品待辦事項，幷包括了一個團隊完成這些工作的計劃。

每日站會（Daily Scrum）

開發團隊是自組織的，通過每日站會來確認他們仍然可以實現Sprint的目標。

每一個開發團隊成員需要提供以下三點資訊：

● 從昨天的站立會到現在，我完成了什麼；

●  從現在到明天的站立會，我計劃完成什麼；

● 有什麼阻礙了我的進展。

每日Scrum通常不超過15分鐘。

每日Scrum中可能有簡要的問題澄清和回答，但是不應該有任何話題的討論。

每日Scrum既不是向管理層彙報，也不是向產品負責人或者ScrumMaster彙報。它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的瞭解。

只有Scrum團隊的成員，包括ScrumMaster和產品負責人，可以在會議中發言。其他感興趣的人可以來旁聽。

Sprint評審會議（Sprint Review）

Sprint結束時，Scrum團隊和相關人員一起評審Sprint的產出。所有Scrum會議都是限定時長的，Sprint評審會議的推薦時長是Sprint中的每一週對應一個小時（比如，一個Sprint包含2個星期，則Sprint評審會議時長為2個小時）。

每個人都可以在Sprint評審會議上發表意見。產品負責人會對未來做出最終的決定，並適當地調整產品待辦事項列表（Product Backlog）。

Sprint評審會議向每個人展示了當前產品增量的概況。通常都會在Sprint評審會議中調整產品待辦事項列表。

Sprint回頊會議（Sprint Retrospective）

在每個Sprint結束後，Scrum團隊會聚在一起開Sprint回顧會議，目的是回顧一下團隊在流程、人際關係以及工具方面做得如何。團隊識別出哪些做得好，哪些做得不好，並找出潛在的改進事項，為將來的改進制定計劃。所有的Scrum會議都是限定時長的，Sprint回顧會議的推薦時長是Sprint中的每一週對應一個小時（譯者注：比如，一個Sprint包含2個星期，則Sprint回顧會議時長為2個小時）。

Scrum團隊總是在Scrum的框架內，改進他們自己的流程。

SCRUM的三個物件

三個物件指的是產品待辦事項列表（Product Backlog）、Sprint Backlog和燃盡圖

Product Backlog – 產品待辦事項列表

產品待辦事項列表是一個排序的列表,包含所有產品需要的東西,也是產品需求變動的唯一來源。產品負責人負責產品待辦事項列表的內容、可用性和優先順序。

產品待辦事項列表是一個持續完善的清單, 最初的版本只列出最初始的和眾所周知的需求。 產品待辦事項列表根據產品和開發環境的變化而演進。待辦事項列表是動態的,它經常發生變化以識別使產品合理、有競爭力和有用所必需的東西。只要產品存在,產品待辦事項列表就存在。

產品待辦事項列表列出了所有的特性、功能、需求、改進方法和缺陷修復等對未來發布產品進行的改變。產品待辦事項列表條目包含描述、次序和估算的特徵。

產品待辦事項列表通常以價值、風險、優先順序和必須性排序。它是一個按照優先順序由高到低排列的一個序列，每個條目有唯一的順序。排在頂部的產品待辦事項列表條目需要立即進行開發。排序越高,產品待辦事項列表條目越緊急,就越需要仔細斟酌,並且對其價值的意見越一致。

排序越高的產品待辦事項列表條目比排序低的更清晰、更具體。根據更清晰的內容和 更詳盡的資訊就能做出更準確的估算。優先順序越低,細節資訊越少。開發團隊在接下來的 Sprint 中將要進行開發的產品待辦事項列表條目是細粒度的,已經被分解過,因此,任何 一個條目在 Sprint 的時間盒內都可以被“完成”。開發團隊在一個 Sprint 中可以“完 成”的產品待辦事項列表條目被認為是“準備好的”或者“可執行的”,能在 Sprint 計 劃會議中被選擇。

隨著產品的使用、價值的獲取以及市場的反饋,產品待辦事項列表變成了更大、更詳 盡的列表。因為需求永遠不會停止改變,所以產品待辦事項列表是個不斷更新的工件。業 務需求、市場形勢和技術的變化都會引起產品待辦事項列表的變化。

若干個 Scrum 團隊常常會一起開發某個產品。但描述下一步產品開發工作的產品待辦事項列表只能有一個。那麼這就需要使用對產品待辦事項列表條目進行分組的屬性。

通過產品Backlog地梳理來增添細節、估算和排序。這是一個持續不斷 的過程,產品負責人和開發團隊協作討論產品代表事項列表條目的細節。在產品待辦事項列表梳理的時候,條目會被評審和修改。然而, 產品負責人可以隨時更新產品代辦事項列表條目或酌情決定。

梳理在 Sprint 中是一項兼職活動,在產品負責人和開發團隊之間展開。通常,開發 團隊有自行優化的領域知識。然而,何時如何完成優化是 Scrum 團隊的決定。優化通常佔用不超過開發團隊 10%的時間。

開發團隊負責所有的估算工作。產品負責人可以通過協助團隊權衡取捨來影響他們的 決定。但是,最後的估算是由執行工作的人來決定的。

SPRINT BACKLOG

Sprint 代辦事項列表是一組為當前 Sprint 選出的產品代辦事項列表條目,外加交付 產品增量和實現 Sprint 目標的計劃。Sprint 代辦事項列表是開發團隊對於哪些功能要包 含在下個增量中,以及交付那些功能所需工作的預計。

Sprint 代辦事項列表定義了開發團隊把產品代辦事項列表條目轉換成“完成”的增量 所需要執行的工作。Sprint 代辦事項列表使開發團隊確定的、達到 Sprint 目標所需的工 作清晰可見。

Sprint 代辦事項列表是一份足夠具體的計劃,使得進度上的改變能在每日例會中得到 理解。開發團隊在整個 Sprint 中都會修改 Sprint 代辦事項列表,Sprint 代辦事項列表也 會在 Sprint 的程序中慢慢顯現,比如開發團隊按照計劃工作並對完成 Sprint 目標所需的 工作有更多的瞭解。

當出現新工作時,開發團隊需要將其追加到 Sprint 待辦事項列表中去。隨著任務進 行或者被完成,需要更新每項任務的估算剩餘工作量。如果計劃中某個部分失去開發的意 義,就可以將其除去。在 Sprint 內只有開發團隊可以對 Sprint 待辦事項列表進行修改。 Sprint 待辦事項列表是高度可見的,是對團隊計劃在當前 Sprint 內完成工作的實時反 映,並且,該列表只屬於開發團隊。

Product Backlog 功能點被放到Sprint的固定週期中，Sprint Backlog 會因為如下原因發生變化:

❶隨著時間的變化，開發團隊對於需求有了更好的理解，有可能發現需要增加一些新的任務到Sprint Backlog中。

❷程式缺陷做為新的任務加進來，這個都做為承諾提交任務中未完成的工作。

Product Owner也許會和Scrum team一起工作，以幫助team更好的理解Sprint的目標，ScrumMaster和team也許會覺得小的調整不會影響sprint的進度，但會給客戶帶來更多商業價值。

燃盡圖（BURN-DOWN CHART)

Sprint燃盡圖（Sprint Burn-down Chart)

Sprint Burndown Chart 顯示了Sprint中累積剩餘的工作量，它是一個反映工作量完成狀況的趨勢圖。 圖中Y軸代表的是剩餘工作量，X軸代表的是Sprint的工作日。

在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，團隊會根據進展情況每天更新累積工作量，如果在Sprint結束時，累積工作量降低到0，Sprint就成功結束。

由於在Sprint的剛開始的時候，增加的任務工作量可能大於完成的任務工作量，所以燃盡圖有可能略微呈上升趨勢。

釋出燃盡圖（Release Burn-down Chart）

在Scrum專案中，團隊通過每個Sprint結束時更新的釋出燃盡圖來跟蹤整個釋出計劃的進展。釋出燃盡圖記錄了在一段時間內產品Backlog的總剩餘估算工作量的變化趨勢。X軸代表的專案週期，以Sprint為單位， Y軸代表的是剩餘工作量，通常以使用者故事點、理想人天或者team-days為單位。