這是The Scrum Guide英文原版，由Scrum的創(chuàng)始人Jeff Sutherland和Ken Schwaber開發(fā)并維護，建議所有Scrum團隊熟讀。
我們公司不僅要求熟讀，而且讀完以后還會考試。??
雖然這個要求有點變態(tài)，但是從另一個角度來看：團隊中的每個人都對Scrum的基礎(chǔ)知識能有較深入的理解，也是符合透明——Scrum三大支柱之一——的要求的。
以下是The Scrum Guide的中文翻譯，翻譯工作由周建成完成，雖然不認識他，但是還是非常感謝！
Scrum指南的目的
Scrum是用于開發(fā)和持續(xù)支持復(fù)雜產(chǎn)品的一個框架。本指南包含了Scrum的定義，其中包括Scrum的角色、事件、工件，以及把它們組織在一起的規(guī)則。KenSchwaber和JeffSutherland創(chuàng)造了Scrum，Scrum指南也由他們撰寫與提供?？傊麄兪荢crum指南的后盾。
Scrum的定義
Scrum(名詞)；Scrum是一個框架，在此框架中人們可以解決復(fù)雜的自適應(yīng)難題，同時也能高效并創(chuàng)造性地交付盡可能高價值的產(chǎn)品。Scrum是：
- 輕量級的
- 易于理解的
- 難以精通的
Scrum是一個過程框架，自上世紀90年代初以來，它就已經(jīng)被應(yīng)用于管理復(fù)雜產(chǎn)品的開發(fā)上。Scrum并不是構(gòu)建產(chǎn)品的一種過程或一項技術(shù)，倒不如說，它是一個框架，在此框架中您可以使用各種不同的過程和技術(shù)。Scrum讓您的產(chǎn)品管理和開發(fā)實踐的相對成效更加清楚地顯現(xiàn)出來，因此您可以去改進它們。
Scrum框架由Scrum團隊以及與之相關(guān)的角色、事件、工件和規(guī)則組成?？蚣苤械拿總€部分都有其特定的目的，其對于Scrum的成功與使用是至關(guān)重要的。
Scrum的規(guī)則把事件、角色和工件組織在一起，管理它們之間的關(guān)系和交互。對于Scrum的規(guī)則描述將會貫穿全文。
使用Scrum框架的其它不同特定技巧將不在本文中描述。
Scrum的應(yīng)用
Scrum最初是為了管理和開發(fā)產(chǎn)品而開發(fā)的。從上世紀90年代初開始，Scrum在全球范圍內(nèi)已得到了廣泛應(yīng)用：
- 研究與確定可行的市場、技術(shù)和產(chǎn)品能力；
- 開發(fā)產(chǎn)品和增強功能；
- 每天頻繁多次發(fā)布產(chǎn)品和增強功能；
- 為產(chǎn)品使用開發(fā)與支持云（在線、安全、按需）和其他運行環(huán)境；以及，
- 支持和更新產(chǎn)品。
Scrum已被用于開發(fā)軟件、硬件、嵌入式軟件、交互功能網(wǎng)絡(luò)、自動駕駛汽車、學(xué)校、政府、市場、管理組織運營，以及幾乎我們（作為個體和群體）日常生活中所使用的一切。
隨著技術(shù)、市場和環(huán)境的復(fù)雜性及其它們之間相互作用的快速增長，Scrum在處理復(fù)雜性方面的效用日益得到證實。
在迭代與增量的知識遷移中，Scrum被證明特別有效。Scrum現(xiàn)廣泛用于產(chǎn)品、服務(wù)和母公司管理。
Scrum的精髓在于小團隊。個體團隊具有高度靈活性和適應(yīng)性。當單個、幾個、多個和團隊網(wǎng)絡(luò)在開發(fā)、發(fā)布、運營和維護成千上萬人的工作和工作產(chǎn)品時，這些優(yōu)勢得以持續(xù)運作（并發(fā)揮價值）。他們通過精良的開發(fā)架構(gòu)和目標發(fā)布環(huán)境來協(xié)作和互操作。
當Scrum指南使用“開發(fā)（動詞）”和“開發(fā)（名詞）”這兩個詞時，它們指的是復(fù)雜的工作，正如上述所確定的這些類型。
Scrum理論
Scrum基于經(jīng)驗過程控制理論，或稱之為經(jīng)驗主義。經(jīng)驗主義主張知識源自實際經(jīng)驗以及從當前已知情況下做出決定所獲得。Scrum采用一種迭代、增量式的方法來優(yōu)化對未來的預(yù)測和管理風險。透明、檢視和適應(yīng)是經(jīng)驗過程控制的三大支柱，支撐起每一個經(jīng)驗過程控制的實施。
透明
過程中的關(guān)鍵環(huán)節(jié)對于那些對產(chǎn)出負責的人必須是顯而易見的。要擁有透明，就要為這些關(guān)鍵環(huán)節(jié)制定統(tǒng)一的標準，這樣所有留意這些環(huán)節(jié)的人都會對觀察到的事物有統(tǒng)一的理解。
例如：
- 所有參與者談及過程時都必須使用統(tǒng)一的術(shù)語。同時，
- 負責完成工作和驗收工作的人必須對“完成”的定義，有一致的理解。
檢視
Scrum的使用者必須經(jīng)常檢視Scrum的工件和完成Sprint目標的進展，以便發(fā)現(xiàn)不必要的差異。檢視不應(yīng)該過于頻繁而阻礙工作本身。當檢視是由技能嫻熟的檢視者在工作中勤勉地執(zhí)行時，效果最佳。
適應(yīng)
如果檢視者發(fā)現(xiàn)過程中的一個或多個方面偏離于可接受范圍以外，并且將會導(dǎo)致產(chǎn)品不可接受時，就必須對過程或過程化的內(nèi)容加以調(diào)整。調(diào)整工作必須盡快執(zhí)行如此才能最小化進一步的偏離。
Scrum規(guī)定了4個正式事件，用于檢視與適應(yīng)上，這4個事件在Scrum事件章節(jié)中會加以描述：
- Sprint計劃會議
- 每日Scrum站會
- Sprint評審會議
- Sprint回顧會議
Scrum價值觀
當承諾、勇氣、專注、開放和尊重五大價值觀為Scrum團隊所踐行與內(nèi)化時，Scrum的透明、檢視和適應(yīng)三大支柱成為現(xiàn)實，并且在每個人之間構(gòu)建信任。Scrum團隊成員通過Scrum事件、角色和工件來學(xué)習(xí)和探索這些價值觀。
Scrum的成功應(yīng)用取決于人們變得更為精通踐行五項價值觀。人們致力于實現(xiàn)Scrum團隊的目標。Scrum團隊成員有勇氣去做正確的事并處理那些棘手的問題。每個人專注于Sprint和Scrum團隊目標的工作。Scrum團隊及其利益攸關(guān)者同意將所有工作和執(zhí)行工作的挑戰(zhàn)進行公開。Scrum團隊成員相互敬重，彼此成為更有能力和獨立的人。
Scrum團隊
Scrum團隊由一名產(chǎn)品負責人、開發(fā)團隊和一名ScrumMaster組成。Scrum團隊是跨職能的自組織團隊。自組織團隊自己選擇如何以最好的方式來完成工作，而不是由團隊之外的人來指導(dǎo)?？缏毮軋F隊擁有完成工作所需的全部技能，不需要依賴團隊之外的人。Scrum的團隊模式乃是設(shè)計用來提供最佳的靈活性、創(chuàng)造力和生產(chǎn)力。
Scrum團隊迭代增量式地交付產(chǎn)品，籍此最大化獲得反饋的機會。增量式交付“完成”的產(chǎn)品保證了一個可工作產(chǎn)品的潛在可用版本總是存在。
產(chǎn)品負責人
產(chǎn)品負責人負責最大化產(chǎn)品和開發(fā)團隊工作的價值。如何實現(xiàn)這一點的方式會隨著組織、Scrum團隊和單個團隊成員的不同而不同。
產(chǎn)品負責人是負責管理產(chǎn)品待辦列表的唯一責任人。產(chǎn)品待辦列表的管理包括：
- 清晰地表述產(chǎn)品待辦列表項；
- 對產(chǎn)品待辦列表項進行排序，使其最好地實現(xiàn)目標和使命；
- 優(yōu)化開發(fā)團隊所執(zhí)行工作的價值；
- 確保產(chǎn)品待辦列表對所有人是可見、透明和清晰的，同時顯示Scrum團隊下一步要做的工作；以及，
- 確保開發(fā)團隊對產(chǎn)品待辦列表項有足夠深的了解。
產(chǎn)品負責人可以親自完成上述工作，或者也可以讓開發(fā)團隊來完成。然而無論何者，產(chǎn)品負責人是負最終責任的人。
產(chǎn)品負責是一個人，而不是一個委員會。產(chǎn)品負責人可能會通過產(chǎn)品待辦列表展現(xiàn)一個委員會的期望要求，但是想要改變產(chǎn)品待辦列表項的優(yōu)先級必須經(jīng)過產(chǎn)品負責人。
為保證產(chǎn)品負責人的工作取得成功，組織中的所有人員都必須尊重他/她的決定。產(chǎn)品負責人對產(chǎn)品待辦列表的內(nèi)容和排序的決定必須是可見的。任何人都不得要求開發(fā)團隊按照另一套需求開展工作，另一方面開發(fā)團隊也不允許去做任何其他人所說的。
開發(fā)團隊
開發(fā)團隊包含了各種專業(yè)人員，負責在每個Sprint結(jié)束時交付潛在可發(fā)布并且“完成”的產(chǎn)品增量。只有開發(fā)團隊成員才能創(chuàng)建增量。
開發(fā)團隊由組織組建并得到授權(quán)，團隊自己組織和管理他們的工作。由此產(chǎn)生的正面效應(yīng)能最大化開發(fā)團隊的整體效率和效用。
開發(fā)團隊具有下列特點：
- 他們是自組織的。
沒有人(即使是ScrumMaster)有權(quán)告訴開發(fā)團隊應(yīng)該如何把產(chǎn)品待辦列表變成潛在可發(fā)布的功能增量；- 開發(fā)團隊是跨職能的，團隊作為一個整體，擁有創(chuàng)建產(chǎn)品增量所需的全部技能；
- Scrum不認可開發(fā)團隊成員的頭銜，不管承擔哪種工作他們都叫開發(fā)人員，即只有開發(fā)人員這一頭銜。此規(guī)則無一例外；
- Scrum不認可開發(fā)團隊中所謂的“子團隊”，無論是否有特別的專業(yè)領(lǐng)域，例如無論是測試還是業(yè)務(wù)分析的成員都不能劃分為“子團隊”。此規(guī)則無一例外；同時，
- 開發(fā)團隊中的每個成員也許有特長和專注的領(lǐng)域，但是責任屬于整個開發(fā)團隊。
開發(fā)團隊的規(guī)模
開發(fā)團隊最佳規(guī)模是足夠小以保持敏捷性，同時足夠大可以在Sprint內(nèi)完成重要的工作。少于3個人的開發(fā)團隊，成員之間沒有足夠的互動，因而生產(chǎn)力的增長不會很大。過小的團隊在Sprint中可能會遭遇到技能上的約束，進而導(dǎo)致開發(fā)團隊無法交付潛在可發(fā)布的產(chǎn)品增量。超過9人的團隊則需要過多的協(xié)調(diào)溝通工作。過大的開發(fā)團隊會產(chǎn)生太多的復(fù)雜性，不便于經(jīng)驗過程管理。產(chǎn)品負責人和ScrumMaster角色不包含在此數(shù)字中，除非他們同時也參與執(zhí)行Sprint待辦列表中的工作。
ScrumMaster
ScrumMaster負責根據(jù)Scrum指南中的定義來促進和支持Scrum。ScrumMaster通過幫助每個人理解Scrum理論、實踐、規(guī)則和價值來做到這一點。
ScrumMaster對Scrum團隊而言，他/她是一位服務(wù)型領(lǐng)導(dǎo)。ScrumMaster幫助Scrum團隊之外的人了解他/她如何與Scrum團隊交互是有益的，通過改變他/她們與Scrum團隊的互動方式來最大化Scrum團隊所創(chuàng)造的價值。
ScrumMaster服務(wù)于產(chǎn)品負責人
ScrumMaster以各種方式服務(wù)于產(chǎn)品負責人，包括：
- 盡可能確保Scrum團隊中的每個人都能理解目標、范圍和產(chǎn)品域；
- 找到有效管理產(chǎn)品待辦列表的技巧；
- 幫助Scrum團隊理解為何需要清晰且簡明的產(chǎn)品待辦列表項；
- 理解在經(jīng)驗主義的環(huán)境中的產(chǎn)品規(guī)劃；
- 確保產(chǎn)品負責人懂得如何來安排產(chǎn)品待辦列表使其達到最大化價值；?理解并實踐敏捷性；以及，
- 按要求或需要引導(dǎo)Scrum事件。
ScrumMaster服務(wù)于開發(fā)團隊
ScrumMaster以各種方式服務(wù)于開發(fā)團隊，包括：
- 在自組織和跨職能方面給予開發(fā)團隊指導(dǎo)；
- 幫助開發(fā)團隊創(chuàng)造高價值的產(chǎn)品；
- 移除開發(fā)團隊工作進展中的障礙；
- 按要求或需要引導(dǎo)Scrum事件；以及，
- 在Scrum還未完全采納和理解的組織環(huán)境中指導(dǎo)開發(fā)團隊。
ScrumMaster服務(wù)于組織
ScrumMaster以各種方式服務(wù)于組織，包括：
- 帶領(lǐng)并指導(dǎo)組織采納Scrum；
- 在組織范圍內(nèi)規(guī)劃Scrum的實施；
- 幫助員工和利益攸關(guān)者理解并實施Scrum和經(jīng)驗產(chǎn)品開發(fā)；
- 引發(fā)能夠提升Scrum團隊生產(chǎn)效率的改變；以及，
- 與其他ScrumMaster一起工作，增加組織中Scrum應(yīng)用的有效性。
Scrum事件
Scrum使用固定的事件來產(chǎn)生規(guī)律性，以此來減少Scrum之外的其他會議的必要。所有事件都是有時間盒限定的事件，也就是說每一個事件限制在最長的時間范圍內(nèi)。一旦Sprint開始，它的持續(xù)時間是規(guī)定的，不能縮短或延長。而其他事件則可以在該事件的目標達成之后可以立即終止，如此確保時間被適當?shù)厥褂枚粫斐蛇^程中的浪費。
Sprint除了本身作為一個事件以外，它還是其他所有事件的容器，在Scrum中的每個事件都是用來進行檢視和適應(yīng)的正式機會。這些事件都是被特別設(shè)計用來確保達成透明和檢視。如果Sprint不能成功地包含這些事件中的任何一個事件，導(dǎo)致透明化的降低，同時也會喪失進行檢視與適應(yīng)的機會。
Sprint
Sprint是Scrum的核心，其長度(持續(xù)時間)為一個月或更短時間的限時，在這段時間內(nèi)構(gòu)建一個“完成的”、可用的和潛在可發(fā)布的產(chǎn)品增量。在整個開發(fā)過程期間，Sprint的長度通常保持一致。前一個Sprint結(jié)束后，新的下一個Sprint緊接著立即開始。
Sprint由Sprint計劃會議、每日Scrum站會、開發(fā)工作、Sprint評審會議和Sprint回顧會議構(gòu)成。
在Sprint期間：
- 不能做出有害于Sprint目標的改變；
- 不能降低質(zhì)量的目標；以及，
- 隨著對信息掌握的增加，產(chǎn)品負責人與開發(fā)團隊之間對范圍內(nèi)要做的事可能會要澄清和重新協(xié)商。
每個Sprint都可以被視為一個項目，為期不超過一個月。就如同項目一樣，Sprint被用于完成某些事情。每個Sprint都會定義要開發(fā)什么，還有一份設(shè)計過和靈活的計劃用來指導(dǎo)如何做這些事、工作內(nèi)容和最終產(chǎn)品。
Sprint的長度限制在一個月內(nèi)。當Sprint的長度太長的話，對要構(gòu)建什么的定義就有可能會改變，復(fù)雜性也有可能會增加，同時風險也有可能會增加。Sprint通過確保至少每月一次對達成目標的進度進行檢視和適應(yīng)，來實現(xiàn)可預(yù)測性。Sprint同時也把風險限制在一個月的成本上。
取消Sprint
Sprint可以在Sprint時間盒結(jié)束之前取消。只有產(chǎn)品負責人才有取消Sprint的權(quán)力，雖然他或她做這樣的決定也可能受到來自利益攸關(guān)者、開發(fā)團隊或是ScrumMaster的影響。
如果Sprint目標過時，那么Sprint就會被取消。比如公司的發(fā)展方向或者市場上或技術(shù)上的狀況發(fā)生改變，這些變化都可能導(dǎo)致Sprint被取消?？偟膩碚f，如果某個Sprint對其所在環(huán)境來說失去了價值和意義，那么它就應(yīng)該被取消。然而，由于Sprint的時間都很短，所以取消Sprint的意義不大。
當取消某個Sprint時，任何做完和“完成”的產(chǎn)品待辦列表項都需要評審。假如成果的任何部分具有潛在可發(fā)布的話，產(chǎn)品負責人通常會接受這個成果。所有未完成的產(chǎn)品待辦列表項都會被放回到產(chǎn)品待辦列表中，并重新估算?；ㄔ谒鼈兩砩系墓ぷ鲿芸斓刭H值，所以必須經(jīng)常性地重估。
取消Sprint會消耗資源，因為每個人都必須重新集合在另一個Sprint計劃會議來開始另一個Sprint。取消Sprint通常會對Scrum團隊造成重創(chuàng)，這種情況非常罕見。
Sprint計劃會議
Sprint中要做的工作在Sprint計劃會議中來做計劃。這份工作計劃是由整個Scrum團隊共同協(xié)作完成的。
Sprint計劃會議是限時的，以一個月的Sprint來說最長8小時為上限。對于較短的Sprint，會議時間通常會縮短。ScrumMaster要確保會議順利舉行，并且每個參會者都理解會議的目的。ScrumMaster要教導(dǎo)Scrum團隊遵守時間盒的規(guī)則。
Sprint計劃會議回答以下問題：
- 接下來的Sprint交付的增量中要包含什么內(nèi)容?
- 要如何完成交付增量所需的工作?
話題一：這次Sprint能做什么?
開發(fā)團隊預(yù)測在這次Sprint中要開發(fā)的功能。產(chǎn)品負責人講解Sprint的目標以及達成該目標所需完成的產(chǎn)品待辦列表項。整個Scrum團隊協(xié)同工作來理解Sprint的工作。
Sprint會議的輸入是產(chǎn)品待辦列表、最新的產(chǎn)品增量、開發(fā)團隊在這個Sprint中能力的預(yù)測以及開發(fā)團隊的以往表現(xiàn)。開發(fā)團隊自己決定選擇產(chǎn)品待辦列表項的數(shù)量。只有開發(fā)團隊可以評估接下來的Sprint可以完成什么工作。
在開發(fā)團隊預(yù)測完這個Sprint中可交付的產(chǎn)品待辦列表項之后，Scrum團隊草擬一個Sprint目標。Sprint目標是在這個Sprint通過實現(xiàn)產(chǎn)品待辦列表要達到的目的，同時它也為開發(fā)團隊提供指引，使得開發(fā)團隊明確開發(fā)增量的目的。
話題二：如何完成所選的工作?
在設(shè)定了Sprint目標并選出這個Sprint要完成的產(chǎn)品待辦列表項之后，開發(fā)團隊將決定如何在Sprint中把這些功能構(gòu)建成“完成”的產(chǎn)品增量。這個Sprint中所選出的產(chǎn)品待辦列表項加上交付它們的計劃稱之為Sprint待辦列表。
開發(fā)團隊通常從設(shè)計整個系統(tǒng)開始，到如何將產(chǎn)品待辦列表轉(zhuǎn)換成可工作的產(chǎn)品增量所需要的工作。工作有不同的大小，或者不同的預(yù)估工作量。然而，在Sprint計劃會議中，開發(fā)團隊已經(jīng)挑選出足夠量的工作，以此來預(yù)估他們在即將到來的Sprint中能夠完成。在Sprint計劃會議的最后，開發(fā)團隊規(guī)劃出在Sprint最初幾天內(nèi)所要做的工作，通常以一天或更少為一個單位。開發(fā)團隊自組織地領(lǐng)取Sprint待辦產(chǎn)品列表中的工作，領(lǐng)取工作在Sprint計劃會議和Sprint期間按需進行。
產(chǎn)品負責人能夠幫助解釋清楚所選定的產(chǎn)品待辦列表項，并作出權(quán)衡。如果開發(fā)團隊認為工作過多或過少，他們可以與產(chǎn)品負責人重新協(xié)商所選的產(chǎn)品待辦列表項。開發(fā)團隊也可以邀請其他人員參加會議，以獲得技術(shù)或領(lǐng)域知識方面的建議。
在Sprint計劃會議結(jié)束時，開發(fā)團隊應(yīng)該能夠向產(chǎn)品負責人和ScrumMaster解釋他們將如何以自組織團隊的形式完成Sprint目標并開發(fā)出預(yù)期的產(chǎn)品增量。
Sprint目標
Sprint目標是在當前Sprint通過實現(xiàn)產(chǎn)品待辦列表要達到的目的。它為開發(fā)團隊提供指引，使得團隊明確為什么要構(gòu)建增量。Sprint目標在Sprint計劃會議中確定。Sprint目標為開發(fā)團隊在Sprint中所實現(xiàn)的功能留有一定的彈性。所選定的產(chǎn)品待辦列表項會提供一個連貫一致的功能，也即是Sprint目標。Sprint目標可以是任何其他的連貫性來促使開發(fā)團隊一起工作而不是分開獨自做。
開發(fā)團隊必須在工作中時刻謹記Sprint目標。為了達成Sprint目標，需要實現(xiàn)相應(yīng)的功能和實施所需的技術(shù)。如果所需工作和預(yù)期的不同，開發(fā)團隊需要與產(chǎn)品負責人溝通協(xié)商Sprint待辦列表的范圍。
每日Scrum站會
每日Scrum站會是開發(fā)團隊的一個以15分鐘為限的事件。每日Scrum站會在Sprint的每一天都舉行。在每日Scrum站會上，開發(fā)團隊為接下來的24小時的工作制定計劃。通過檢視上次每日Scrum站會以來的工作和預(yù)測即將到來的Sprint工作來優(yōu)化團隊協(xié)作和性能。每日Scrum站會在同一時間同一地點舉行，以便降低復(fù)雜性。
開發(fā)團隊借由每日Scrum站會來檢視完成Sprint目標的進度，并檢視完成Sprint待辦列表的工作進度趨勢。每日Scrum站會優(yōu)化了開發(fā)團隊達成Sprint目標的可能性。每天，開發(fā)團隊應(yīng)該知道如何以自組織團隊來協(xié)同工作以達成Sprint目標，并在Sprint結(jié)束時開發(fā)出預(yù)期中的增量。
會議的結(jié)構(gòu)由開發(fā)團隊設(shè)定。如果會議專注于達成Sprint目標的進展，開發(fā)團隊可以采用不同的方式進行。一些開發(fā)團隊會以問題為導(dǎo)向來開會，有些開發(fā)團隊會基于更多的討論來開會。以下為示例：
- 昨天，我為幫助開發(fā)團隊達成Sprint目標做了什么？
- 今天，我為幫助開發(fā)團隊達成Sprint目標準備做什么？
- 是否有任何障礙在阻礙我或開發(fā)團隊達成Sprint目標？
開發(fā)團隊或者開發(fā)團隊成員通常會在每日Scrum站會后立即聚到一起進行更詳細的討論，或者為Sprint中剩余的工作進行調(diào)整或重新計劃。
ScrumMaster確保開發(fā)團隊每日站會如期舉行，但開發(fā)團隊自己負責召開會議。ScrumMaster教導(dǎo)開發(fā)團隊將每日Scrum會議時間控制在15分鐘內(nèi)。
每日Scrum站會是開發(fā)團隊的內(nèi)部會議。如果有開發(fā)團隊之外的人出席會議，ScrumMaster必須確保他們不會干擾會議進行。
每日Scrum站會增進交流溝通、減少其他會議、發(fā)現(xiàn)開發(fā)過程中需要移除的障礙、突顯并促進快速地做決策、提高開發(fā)團隊的認知程度。這是一個進行檢視與適應(yīng)的關(guān)鍵會議。
Sprint評審會議
Sprint評審會議在Sprint快結(jié)束時舉行，用以檢視所交付的產(chǎn)品增量并按需調(diào)整產(chǎn)品待辦列表。在Sprint評審會議中，Scrum團隊和利益攸關(guān)者協(xié)同討論在這次Sprint中所完成的工作。根據(jù)完成情況和Sprint期間產(chǎn)品待辦列表的變化，所有參會人員協(xié)同討論接下來可能要做的事情來優(yōu)化價值。這是一個非正式會議，并不是一個進度匯報會議，演示增量的目的是為了獲取反饋并促進合作。
對于長度為一個月的Sprint來說，評審會議時間最長不超過4小時。對于較短的Sprint來說，會議時間通常會縮短。ScrumMaster要確保會議舉行，并且每個參會者都明白會議的目的。ScrumMaster教導(dǎo)每位參會者遵守時間盒的規(guī)則。
Sprint評審會議包含以下內(nèi)容：
- 產(chǎn)品負責人邀請Scrum團隊和主要的利益攸關(guān)者參加會議；
- 產(chǎn)品負責人說明哪些產(chǎn)品待辦列表項已經(jīng)“完成”和哪些沒有“完成”；
- 開發(fā)團隊討論在Sprint期間哪些工作做的很好，遭遇到什么問題以及問題是如何解決的；
- 開發(fā)團隊演示“完成”的工作并解答關(guān)于所交付增量的問題；
- 產(chǎn)品負責人討論當前的產(chǎn)品待辦列表的情況。他/她根據(jù)到目前為止的進度來預(yù)測可能的完成日期(如果有需要的話)；
- 參會的所有人就下一步的工作進行探討，這樣，Sprint評審會議就能夠為接下了的Sprint計劃會議提供有價值的輸入信息；
- 評審市場或潛在的產(chǎn)品使用方式所帶來的接下來要做的最有價值的東西的改變；同時，
- 為下個預(yù)期產(chǎn)品版本的發(fā)布評審時間表、預(yù)算、潛力和市場。
Sprint評審會議的結(jié)果是一份修訂后的產(chǎn)品待辦列表，闡明很可能進入下個Sprint的產(chǎn)品待辦列表項。產(chǎn)品待辦列表也有可能為了迎接新的機會而進行全局性地調(diào)整。
Sprint回顧會議
Sprint回顧會議是Scrum團隊檢視自身并創(chuàng)建下一個Sprint改進計劃的機會。
Sprint回顧會議發(fā)生在Sprint評審會議結(jié)束之后，下個Sprint計劃會議之前。對于長度為一個月的Sprint來說，回顧會議時間最長不超過3小時。對于較短的Sprint來說，會議時間通常會縮短。
ScrumMaster要確保會議舉行，并且每個參會者都明白會議的目的。ScrumMaster教導(dǎo)大家遵守時間盒的規(guī)則。ScrumMaster作為Scrum過程的責任者，作為團隊的一員參加該會議。
Sprint回顧會議的目的在于：
- 檢視前一個Sprint中關(guān)于人、關(guān)系、過程和工具的情況如何；
- 找出并加以排序做得好的和潛在需要改進的主要方面；同時，
- 制定改進Scrum團隊工作方式的計劃。
ScrumMaster鼓勵Scrum團隊在Scrum的過程框架內(nèi)改進開發(fā)過程和實踐，使得他們能在下個Sprint中更高效更愉快。在每個Sprint回顧會議中，Scrum團隊通過適當?shù)卣{(diào)整“完成”的定義的方式來計劃提高產(chǎn)品質(zhì)量。
在Sprint回顧會議結(jié)束時，Scrum團隊應(yīng)該明確接下來的Sprint中需要實施的改進。在下一個Sprint中實施這些改進是基于Scrum團隊對自身的檢視而做出的適當調(diào)整。雖然改進可以在任何時間執(zhí)行，Sprint回顧會議提供了一個專注于檢視和適應(yīng)的正式機會。
Scrum工件
Scrum的工件以不同的方式表現(xiàn)工作任務(wù)和價值，可以用來提供透明以及檢視和適應(yīng)的機會。Scrum所定義的工件是特別地設(shè)計的，是為了給關(guān)鍵信息提供最大透明化，因此每個人對工件都需要有相同的理解。
產(chǎn)品待辦列表
產(chǎn)品待辦列表是一份有序列表，其中包含產(chǎn)品需要的一切可能的東西，也是產(chǎn)品需求變動的唯一來源。產(chǎn)品負責人負責管理產(chǎn)品待辦列表的內(nèi)容、可用性和排序。
產(chǎn)品待辦列表永遠是不完整的。最早開發(fā)的產(chǎn)品待辦列表只列舉最初所知的以及理解最透徹的需求。產(chǎn)品待辦列表會隨著產(chǎn)品及其應(yīng)用環(huán)境的改變而演進。產(chǎn)品待辦列表是動態(tài)的，需要持續(xù)更新以反映出產(chǎn)品需要什么來保持其適用性、競爭力和有用。只要產(chǎn)品存在，產(chǎn)品待辦列表也就同樣存在。
產(chǎn)品待辦列表列出所有的特性、功能、需求、增強和修復(fù)等對未來要發(fā)布的產(chǎn)品進行的改變。產(chǎn)品待辦列表項具有這些屬性；描述、次序、估算和價值。
隨著產(chǎn)品的使用、價值的獲取和獲得市場的反饋，產(chǎn)品待辦列表會成長為更大和更詳盡的列表。因為需求永不停止改變，所以產(chǎn)品待辦列表就如一份活的工件。業(yè)務(wù)需求、市場形勢或者技術(shù)的變化都會引起產(chǎn)品待辦列表的改變。
多個Scrum團隊常常會一起參與對同一產(chǎn)品的開發(fā)。一個產(chǎn)品只有一個產(chǎn)品待辦列表用于描述下一步產(chǎn)品開發(fā)工作。那么這就可能需要使用能夠?qū)Ξa(chǎn)品待辦列表項進行分組的屬性。
產(chǎn)品待辦列表精化指的是為產(chǎn)品待辦列表項增添細節(jié)、估算和排序的動作。這是一個持續(xù)的過程，產(chǎn)品負責人和開發(fā)團隊協(xié)同工作在產(chǎn)品待辦列表項的細節(jié)上。在產(chǎn)品待辦列表精化過程中，產(chǎn)品待辦列表項被重新評審和修改。Scrum團隊決定如何來完成精化以及何時來完成。精化的工作通常占用開發(fā)團隊不超過10%的產(chǎn)能。然而，產(chǎn)品負責人或者其他人在產(chǎn)品負責人的斟酌下，產(chǎn)品待辦列表項可以在任何時間來更新。
排序越高的產(chǎn)品待辦列表項通常比排序低的更清晰同時包含更多細節(jié)。根據(jù)更清晰的內(nèi)容和更詳盡的細節(jié)信息就能做出更為準確的估算；同樣，排序越低，則細節(jié)信息越少。產(chǎn)品待辦列表項中那些即將會占用開發(fā)團隊下一個Sprint大部分時間的項會被加以精化，因此，任一產(chǎn)品待辦列表項都能夠在Sprint的時間盒期限內(nèi)適當?shù)亍巴瓿伞?。這些能夠被開發(fā)團隊在一個Sprint中“完成”的產(chǎn)品待辦列表項稱為“準備就緒”，它們將作為Sprint計劃會議中的待選產(chǎn)品列表項。產(chǎn)品待辦列表項的足夠透明程度通常要經(jīng)過上述的精化活動來獲得。
開發(fā)團隊負責所有估算工作。產(chǎn)品負責人可以通過幫助開發(fā)團隊更好地理解需求，并根據(jù)情況權(quán)衡取舍來影響他們，但是最終估算是由開發(fā)團隊決定的。
監(jiān)控目標實現(xiàn)的進度
在任何時刻，達成目標的剩余工作是可以累計的。產(chǎn)品負責人至少在每個Sprint評審會議中都必須跟蹤剩余工作總量。產(chǎn)品負責人比較這次的剩余工作量與之前Sprint評審會議時的剩余工作量，來評估在期望的時間點達成目標的進度。這個信息對所有的利益攸關(guān)者都是透明的。
各種不同趨勢走向的實踐已經(jīng)被使用在預(yù)測進度方面，例如，燃盡圖(burn-downs)、燃燒圖(burn-ups)或者累積流圖(cumulativeflows)。這些工具都被證實是有用的。然而，它們并不能用來取代經(jīng)驗主義的重要性。在復(fù)雜的環(huán)境中，未來將要發(fā)生的事是無法預(yù)知的。只有已經(jīng)發(fā)生的事才能用來做前瞻性的決策。
Sprint待辦列表
Sprint待辦列表是一組為當前Sprint選出的產(chǎn)品待辦列表項，同時加上交付產(chǎn)品增量和實現(xiàn)Sprint目標的計劃。Sprint待辦列表是開發(fā)團隊對于下一個產(chǎn)品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的預(yù)測。
Sprint產(chǎn)品待辦列表將開發(fā)團隊用來達成Sprint目標的所有工作變得清晰可見。為了確保持續(xù)改進，它至少包括一項在先前回顧會議中確定下來的高優(yōu)先級過程改進。
Sprint產(chǎn)品待辦列表是擁有足夠細節(jié)的計劃，任何進度的變化可以在每日Scrum站會中清晰地看到。開發(fā)團隊在Sprint期間修改Sprint待辦列表，使得Sprint待辦列表在Sprint期間涌現(xiàn)。涌現(xiàn)發(fā)生在開發(fā)團隊按計劃開展工作并學(xué)習(xí)到更多的關(guān)于哪些工作是達成Sprint目標所必需的工作時。
當新工作出現(xiàn)時，開發(fā)團隊需要將其加入到Sprint待辦列表中去。隨著工作的執(zhí)行或完成，剩余的工作量被估算并更新。當計劃中的某個部分失去開發(fā)意義，就可以將其移除。在Sprint期間，只有開發(fā)團隊可以改變Sprint待辦列表。Sprint待辦列表是高度可見的，是對開發(fā)團隊計劃在當前Sprint內(nèi)工作完成情況的實時反映，該列表由開發(fā)團隊全權(quán)負責。
監(jiān)控Sprint進度
在Sprint的任何時間點都可以計算Sprint待辦列表中所有剩余工作的總和。開發(fā)團隊至少在每日Scrum站會時跟蹤剩余的工作量，預(yù)測達成Sprint目標的可能性。通過在Sprint中不斷跟蹤剩余的工作量，開發(fā)團隊可以管理自己的進度。
增量
增量是一個Sprint完成的所有產(chǎn)品待辦列表項的總和，以及之前所有Sprint所產(chǎn)生的增量的價值總和。在Sprint的最后，新的增量必須是“完成”的，這意味著它必須可用并且達到了Scrum團隊“完成”的定義的標準。增量是在Sprint結(jié)束時支持經(jīng)驗主義的可檢視的和已完成的產(chǎn)品組成部分。增量是邁向愿景或目標的一步。無論產(chǎn)品負責人是否決定發(fā)布它，增量必須可用。
工件透明
Scrum依賴于透明。優(yōu)化價值和控制風險的決定都是基于所獲知的工件狀態(tài)。當工件的狀態(tài)是完全透明時，這些做出的決定才有一個堅實的基礎(chǔ)；當工件的狀態(tài)是不完全透明時，這些做出的決定就會有瑕疵，而價值也可能因此遭受損失，同時風險也可能會因此而增加。
ScrumMaster必須和產(chǎn)品負責人、開發(fā)團隊和其他相關(guān)人員一起合作，以確保所有工件都是完全透明的。有些實踐就是為應(yīng)對不完全透明的狀態(tài)而生的，Scrum Master必須幫助每個人，讓他們能夠在遇到不透明的情況下采取最合適的實踐。Scrum Master能夠通過檢視工件、嗅探模式、傾聽周圍的聲音以及觀察預(yù)期和實際結(jié)果的差異來發(fā)現(xiàn)不完全透明。
Scrum Master的職責就是和Scrum團隊以及組織一起合作增加工件的透明化。這一工作通常包括學(xué)習(xí)、說服和改變。透明化不會在一夜之間發(fā)生，但是這是一條必經(jīng)之路。
“完成”的定義
當產(chǎn)品待辦列表項或增量被描述為“完成”時，每個人都必須理解“完成”意味著什么。雖然在不同Scrum團隊之間會存在巨大的差別，但是每個團隊成員必須對完成工作意味著什么有相同的理解以便確保透明化。這就是Scrum團隊的“完成”定義，用來評估產(chǎn)品增量是否完成。
這一定義也同時被用來指導(dǎo)開發(fā)團隊了解在Sprint計劃會議時能夠選擇多少產(chǎn)品待辦列表項。每個Sprint的目標在于交付符合Scrum團隊當前“完成”的定義的潛在可交付功能增量。
開發(fā)團隊在每個Sprint都交付產(chǎn)品功能增量。這一增量是可用的，所以產(chǎn)品負責人可以選擇立即發(fā)布它。如果“完成”的定義對增量來說是開發(fā)組織的慣例、標準或指南，那么所有Scrum團隊都必須遵守它，以此為最低標準。如果增量“完成”的定義不是開發(fā)組織的慣例，那么Scrum團隊中的開發(fā)團隊就必須制定適合于產(chǎn)品的“完成”的定義。如果系統(tǒng)或產(chǎn)品發(fā)布由多個Scrum團隊一起開發(fā)，那么所有Scrum團隊中的開發(fā)團隊必須一起參與制定“完成”的定義。
每個增量都添加至之前的所有增量上，并且經(jīng)過徹底地測試，以此確保整合在一起的所有增量都能工作。
隨著團隊的成熟，“完成”的定義會擴大，包含更為嚴格的標準來保證更高的質(zhì)量。任何產(chǎn)品或系統(tǒng)都應(yīng)該對其上面開發(fā)的工作有“完成”的定義。
結(jié)束語
Scrum是免費的，在本指南中提供。Scrum的角色、工件、事件和規(guī)則是不可改變的。雖然只實施部分的Scrum是可能的，但這樣就不是Scrum了。Scrum只以整體的形式而存在，唯其如此才能作為其他技術(shù)、方法和實踐的容器運作良好。
致謝
人們
在千千萬萬對Scrum作出貢獻的人中，我們要特別感謝那些在其最初十年提供幫助的人們。首先，要提到Jeff Sutherland以及與他一道工作的Jeff McKenna，還有Ken Schwaber及與其一道工作的Mike Smith與Chris Martin。在隨后的幾年中，許多人都作出了貢獻，沒有他們的幫助，Scrum不會被提煉至如今這般。
歷史
Ken Schwaber和Jeff Sutherland在1995年舉行的OOPSLA大會上首次聯(lián)合公開演講Scrum。那次演講本質(zhì)上記錄了ken和Jeff在之前幾年間使用Scrum時所學(xué)到的經(jīng)驗。
在軟件開發(fā)的世界中，Scrum的歷史已經(jīng)算是很長了。我們對首批嘗試和提煉Scrum的公司：Individual，Inc.、FidelityInvestments和IDX(現(xiàn)在的GE醫(yī)療)表示致敬。
Scrum指南記錄Jeff Sutherland和Ken Schwaber開發(fā)和培育Scrum已經(jīng)超過20多年了。其他的一些資源從模式、流程和見解方面為Scrum框架提供了補充，從而優(yōu)化生產(chǎn)效率、價值、創(chuàng)造力及提升自豪感。
