00.Scrum 指南的目的

　　Scrum是用於開發、交付和持續支援複雜產品的一個框架。本指南包括了Scrum的定義，其中包括Scrum的角色、事件、工件，以及把它們組織在一起的規則。Ken Schwaber和Jeff Sutherland創造了Scrum。

01.Scrum的定義

　　Scrum:Scrum是一個框架，在此框架中人們可以解決複雜的自適應的難題，同時也能高校並創造性地交付可能最高價值的產品。

　　Scrum特點：輕量的、易於理解的、難以精通的

　　Scrum並不是一種過程、技術活決定性的方法。

　　Scrum框架由Scrum團隊以及之相關的角色、事件、工件和規則組成。框架中的每個部分都有其特定的目的，其對於Scrum的成功與使用是至關重要。

　　Scrum的規則吧角色、事件和攻訐組織在一起，管理他們之間的關係和互動。

02.Scrum的應用

　　應用範圍：

　　　　　　*研究與識別可行的市場、技術和產品能力

　　　　　　*開發產品和增強功能

　　　　　　*產品和增強功能，頻率高到一天釋出多次

　　　　　　*開發與支援雲(線上、安全、按需)和其他執行環境來提供給產品使用

　　　　　　*支援和更新產品

　　Scrum的精髓在於小團隊。個體團隊具有高度靈活性與適應型。當單個團隊、幾個團隊、多個團隊和網路團隊在開發、釋出、運營和維護成千上萬的工作和工作產品時，這些優勢得以持續執行。他們通過精妙的開發架構和目標釋出環境來協作和互操作。

03.Scrum理論

　　Scrum基於經驗過程控制理論，或稱之為經驗主義。經驗主義主張知識源自實際經驗以及當前已知情況下做出的決定所獲得。Scrum採納一種迭代和增量的方式來優化對未來的預測和控制風險。透明、檢視和適應是經驗過程控制的三大支柱，支撐起每一個經驗過程的實施。

　　透明：過程中的關鍵環節對於那些產出負責的人必須是顯而易見的。要擁有透明，就要為這些關鍵環節制定統一標準，這樣所有留意這些緩解的人都會對觀察到的事物有統一的理解。

　　檢視：Scrum的使用者必須經常檢視Scrum的工件和完成Sprint目標的進展，以便發現不必要的差異。檢視不應該過於頻繁而阻礙工作本身。當監視是由技能嫻熟的檢視者在工作中勤勉地執行時，效果最佳。

　　適應：如果檢視者發現過程中的一個或多個方面偏離可接受範圍以外，並且將會導致產品不可接受時，就必須對過程或過程化的內容加以調整。調整工作必須儘快執行如此才能最小化進一步的偏離。

　　事件章節：Sprint計劃會議、每日Scrum站會、Sprint評審會議和Sprint回顧會議

04.Scrum價值觀

　　當承諾、勇氣、專注、開發和尊重五大價值觀為Scrum團隊所踐行與內化時，Scrum的透明、檢視和適應三大支柱成為現實，並且在每個人之間構建信任。Scrum團隊成員通過Scrum的角色、事件和工件來學習和探索這些價值觀。

　　Scrum的成功應用取決於人們變得更為精通踐行五項價值觀。人們致力於實現Scrum團隊的目標。Scrum團隊成員有勇氣去做正確的事件並不處理那些棘手的問題。每個人專注於Sprint工作和Scrum團隊目標。Scrum團隊及其利益攸關者同一將所有工作和執行工作上的挑戰進行公開。Scrum團隊成員相互尊重，彼此是有能力和獨立的人。

05.Scrum團隊

　　Scrum團隊由一名產品負責人、開發團隊和一名Scrum Master組成。Scrum團隊是跨職能的自組織團隊。字組織團隊自己選擇如何以最好的方式完成工作，而不是由團隊之外的人來知道。跨職能團隊擁有完成工作所需的全部技能，不需要依賴團隊之外的人。Scrum團隊模式仍是設計用來提供最佳的靈活性、創造力和生產力。Scrum團隊(自身)已經證明，對於所有之前所述Scrum的應用以及任何複雜工作來說，它都是越來越有效。

06.產品負責人

　　產品負責人的職責是將開發團隊開發的產品價值最大化。如何實現這一點的方式會隨著跨組織、Scrum團隊和團隊成員個體不同而有所不同。

　　產品負責人是負責管理產品待辦列表的唯一負責人。

　　　　*清晰地表述產品待辦列表項

　　　　*對產品待辦列表項進行排序，使其最好地是心啊目標和使命

　　　　*優化開發團隊所執行工作的價值

　　　　*確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示Scrum團隊下一步要做的工作

　　　　*確保開發團隊對產品待辦列表專案有足夠深的瞭解

　　產品負責人可以親自完成上述工作，或者也可以讓開發團隊來完成。然而無論何者，產品負責人是負最終責任的人。產品負責人是一個人，而不是一個委員會。為了保證產品負責人的工作取得成功，組織中的所有人員都必須尊重他/她的決定。產品負責人對產品待辦列表的內容和排序的決定必須是可見的。沒有人可以強迫開發團隊按照另一套需求開展工作。

07.開發團隊

　　開發團隊由組織組建並得到授權，團隊自己組織和管理他們的工作。由此產生的正面效應能最大化開發團隊的整體效率和效用。

　　特點：

　　　　*他們是自組織的。沒有人(即使是Scrum Master)有權告訴開發應該如何把產品待辦列表變成潛在可釋出的功能增量。

　　　　*開發團隊是跨職能的團隊，團隊作為一個整體，擁有建立產品增量所需的全部技能；

　　　　*Scrum不認可開發團隊成員的任何頭銜，不管其承擔何種工作(他們都叫開發人員)。

　　　　*Scrum不認可開發團隊中所謂的“子團隊”，無論其需要處理的領域是諸如測試、架構、運維或業務分析；

　　　　*開發團隊中每個成員也許有特長和專注的領域，但是責任屬於整個開發團隊

08.開發團隊的規模

　　開發團隊最佳規模是足夠小以保持敏捷性，同時足夠大可以在Sprint內完成重要的工作。對經驗過程而言，大型開發團隊會產生太多的複雜性而變得無用。產品負責人和Scrum Master角色不包含在開發團隊人數中，除非他們同時也參與執行Sprint待辦列表中的工作。

09.Scrum Master

　　Scrum Master負責根據Scrum指南中的定義來促進和支援Scrum。Scrum Master通過幫助每個人理解Scrum理論、實踐、規則和價值來做到這一點。

　　Scrum Master對Scrum團隊而言，他/她是一位服務型領導。Scrum Master幫助Scrum團隊之外的人瞭解他/她如何與Scrum團隊互動是有益的，通過改變他/她們與Scrum團隊的互動方式來最大化Scrum團隊所創造的價值。

　　a.Scrum Master 服務於產品負責人

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

　　　　　　*確保Scrum團隊中的每個人都儘可能地理解目標、範圍和產品域

　　　　　　*找到有效管理產品待辦列表的技巧

　　　　　　*幫助Scrum團隊理解為和需要清晰且鍵名的產品待辦列表項

　　　　　　*理解在經驗主義的環境中的產品規劃

　　　　　　*確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；

　　　　　　*理解並時間敏捷性

　　　　　　*當被請求或需要時，引導Scrum事件

　　b.Scrum Master服務於開發團隊

　　　　　　*作為教練在自組織和跨職能方面給予開發團隊以指導

　　　　　　*幫助開發團隊創造高價值的產品

　　　　　　*移除開發團隊工作進展中的障礙

　　　　　　*按被請求或需要時，引導Scurm事件　

　　　　　　*在Scrum還未完成採納和理解的組織環境中，作為教練指導開發團隊

　　c.Scrum Master服務於組織

　　　　　　*帶領並作為教練指導組織採納Scrum;

　　　　　　*在組織範圍內規劃Scrum的實施

　　　　　　*幫助員工和利益攸關者理解並實施Scrum和經驗導向的產品開發

　　　　　　*引發能夠提升Scrum團隊生產率的改變

　　　　　　*與其他Scrum Master一起工作，增強組織中Scrum應用的有效性。

10.Scrum事件

　　Scrum使用固定的事件來產生規律性，以此減少Scrum之外的其他會議的必要。所有時間都是有時間盒限定的，也基於是說每一個事件限制在最長的事件範圍內。Sprint除了本身作為一個事件以外，他還是其他所有事件的容器，在Scrum中每個事件都是用來進行檢視和適應的正式機會。這些時間都是被特別設計用來確保達成透明和檢視。如果Sprint不能成功地包含這些時間中的任何一個事件，導致透明化的降低，同時也會喪失進行檢視與適應的機會。

11.Sprint

　　Sprint是Scrum的核心，其長度(持續時間)為一個月或更短的限時，這段時間構建一個“完成”、可用的和潛在可釋出的產品增量。在整個開發過程期間，Sprint的長度保持一致。前一個Sprint結束後，下一個新的Sprint緊接著立即開始。

　　Sprint由Sprint計劃會議、每日Scrum站會、開發工作、Sprint評審會議和Sprint回顧會議構成

　　在Sprint期間：不能做出有害於Sprint目標的改變；不能降低質量的目標；隨著對資訊掌握的增加，產品負責人與開發團隊之間對範圍內要做到的事可以加以澄清和重新協商。

　　每個Sprint都會有一個要構建什麼目標，還有一份設計過和靈活的用來指導如何做這些事、工作內容和最終產品增量。

12.取消Sprint

　　Sprint可以在Sprint時間和結束之前取消。只有產品負責人才有取消Sprint的權力，雖然他或她做這樣的決定也可能受到來自利益攸關者、開發團隊或是Scrum Master的影響。

　　總的來說，如果某個Sprint對其所在環境來說失去了價值和意義，那麼他就應該被取消。然而，由於Sprint的時間都很短，所以取消Sprint通常是不太合理的。

13.Sprint計劃會議

　　　Sprint中要做的工作在Sprint計劃會議中做計劃。這份工作計劃由整個Scrum團隊共同協作完成的。

　　　Sprint計劃會議是有時間盒限定的，以一個月的Sprint來說最長為8小時。對於較短的Sprint，會議時間通常會縮短。Scrum Master要確保會議順利舉行，並且每個參會都理解會議的目的。Scrum Master要教導Scrum團隊遵守時間和的規則。

14.開發Sprint能做什麼？

　　開發團隊預測這次Sprint中藥開發的功能。產品負責人講解Sprint的目標以及達成該目標所需完成產品待辦列表項。整個Scrum團隊協同工作理解Sprint的工作。

　　Sprint會議的輸入是產品待辦列表、最新的產品增量、開發團隊在這個Sprint中能力的預測以及開發團隊的以往表現。開發團隊自己決定選擇產品待辦列表項的數量。只有開發團隊可以評估接下來的Sprint可以完成什麼工作。

　　在Sprint計劃會議中，Scrum團隊還草擬一個Sprint目標。Sprint目標是在這個Sprint通過實現產品待辦列表要達到的目的，同時它也為開發團隊提供指引，使得開發團隊明確開發增量的目的。

15.如何完成所選的工作？

　　開發團隊通常從設計整個系統開始，到如何將產品待辦列表轉換成可工作的產品增量所需要的工作。工作有不同的大小，或者不同的預估工作量。然而，在Sprint計劃會議中，開發團隊已經挑選足夠量的工作，以此來預估他們在即將來到的Sprint中能夠完成。

　　產品負責人嫩鞏固幫助解釋清楚所選定的產品待辦列表項，兵做出權衡。

16.Sprint目標

　　Sprint目標是在當前Sprint通過實現產品待辦列表要達到的目的。它為開發團隊提供指引，使得團隊明確為什麼構建增量。