Scrum 指南 TM Scrum 的終級指南 : 遊戲規則 2016 年 7 月 本指南由 Ken Schwaber 和 Jeff Sutherland 所開發與持續支援
目錄 Scrum 指南的目的... 3 Scrum 的定義... 3 Scrum 的理論... 3 Scrum 的核心價值... 4 Scrum 的團隊... 5 產品負責人... 5 開發團隊... 6 Scrum 隊長... 6 Scrum 事件... 7 短程衝刺 ( 短衝 )... 8 短衝計劃會議... 9 每日 Scrum 匯報... 10 短衝展示會議... 11 短衝回顧檢討會議... 12 Scrum 文物件... 13 産品待辦... 13 短衝待辦... 14 遞增成品... 15 文物件透明化... 15 " 完成 " 的定義... 15 附注... 16 感謝... 16 人員... 16 歷史... 16 繁體中文翻譯... 17 2016 年版本更新說明... 17 共享的條約 頁數 2
Scrum 指南的目的 Scrum 是用在複雜性產品的開發與持續支援的一個架構 這本指南包括 Scrum 的定義 而這個定義涵蓋聯結了 Scrum 的角色, 事件, 文物件, 以及規則在一起 Scrum 是由 Ken Schwaber 和 Jeff Sutherland 所開發, 這本指南是由他們兩位一起撰寫, 提供, 與支持 Scrum 的定義 Scrum (n) 名詞 : 是一個架構, 在這個架構中的人員可以專注地處理複雜的適應性問題, 同時經由高效能與創造力來產出最高價值的產品 Scrum 是 : 輕量的 淺顯易懂的 很難精通 Scrum 是一個流程的架構, 自從 90 年代初期, 它就被使用在管理複雜的產品開發上 Scrum 並不是用來建造產品的一個工作流程或者技術, 倒不如説, 它是一個架構, 在其中您可以使用各種不同的工作流程或者技術 Scrum 讓您的產品管理與開發作業的相對成效更加清楚, 因此您可以去改善它們 Scrum 架構包含了 Scrum 團隊和他 / 她們相關的角色, 事件, 文物件, 以及規則 在這架構中的每個部份都有特定的目的, 其對於 Scrum 的成功和使用是很重要的 Scrum 的規則將事件, 角色, 以及文物件聯結在一起, 以及管理相互間的關係 本文章的主體是用來描述 Scrum 的規則 使用 Scrum 架構的其它不同特定技巧將不再本文章內描述 Scrum 的理論 Scrum 是建立在經驗工作流程控制理論, 或經驗主義 經驗主義主張知識是來自實際體驗以及從目前己知情況下來做決定所獲得 Scrum 使用一種重複和逐步遞增的方式對未來的預測與風險控管更加完善 共享的條約 頁數 3
三個支柱支撐著每一個經驗工作流程控制的實施 : 它們分別是 : 透明化, 檢驗, 與調適性 透明化工作流程內的重大要件對於那些對產出負責的人必須是顯而易見的 透明化要求這些方面被一套共同標準所定義, 所以觀測者能夠對所看見的事物有一個共同的認知 舉例來説 : 所有參與人員對於工作流程必須使用一套共同辭彙 同時 這些做事的人員以及簽收成品的人員必須對於 " 完成 " 的定義, 有一個共同的認知 檢驗 Scrum 的成員必須經常地檢驗 Scrum 的文物件和進度以便來偵測變異 成員的檢驗也不應該太頻繁以至於阻礙到實際工作 當檢驗是被精通的檢查人員在工作當中來小心翼翼地執行的話將會得到最大的好處 調適性當檢查人員發現工作流程中一個或多個項目偏離可接受範圍以外時, 以至於該產品成為無法接受, 那麼這個工作流程或者處理中的資料就必須要加以調整 這個調整必須盡快如此才能減低未來更多的偏差 Scrum 規定四個在短衝內的正式事件, 可用在檢驗與調整性上, 這四個事件在 Scrum 事件章節會加以描述 : 短衝計劃會議每日 Scrum 滙報短衝展示會議短衝回顧檢討會議 Scrum 的核心價值 當 Scrum 的核心價值 : 承擔, 勇氣, 專注, 開放, 和尊重, 被 Scrum 團隊所體現與實踐時,Scrum 的三個支柱 ( 透明化, 檢驗, 與調適性 ) 將成真並且幫助團隊建立互信 Scrum 的團隊成員經由執行 Scrum 的事件, 角色, 和文物件的過程來學習和探索這些核心價值 成功的執行 Scrum 取決於成員能否更熟練的融入這五個核心價值 成員親自致力於實現 Scrum 團隊的目標 Scrum 團隊成員有勇氣來做正確的事以及解決棘手的問題 每個人都 共享的條約 頁數 4
專注在短程衝刺的工作以及 Scrum 團隊的目標 Scrum 團隊和其利益相關者同意對所有工 作和執行上的挑戰完全開放 Scrum 團隊成員相互尊重彼此是有能力與獨立的人員 Scrum 的團隊 Scrum 的團隊包含一名産品負責人, 開發團隊, 以及一名 Scrum 隊長 Scrum 的團隊成員們是自我管理以及跨職能的團隊 自我管理的團隊選擇如何以最好的方式來完成工作, 而不是由團隊外的人員來指導 跨職能的團隊擁有需要的所有能力來完成工作, 而並不需要依靠外部人員的協助 Scrum 的團隊模式乃是設計用來提供最佳的機動性, 創造力, 以及生產力 Scrum 的團隊以重複和逐步遞增的方式來發表產品, 籍此提供回饋的最佳機會 以遞增的 方式來發表 " 完成 " 的產品可以確保一直提供一個潛在有用可以運作的產品 產品負責人 產品負責人對於產品的價值以及開發團隊的工作, 負責使其達到最大值 如何做好這件事 隨著跨公司組織,Scrum 團隊, 和成員們而有所不同 產品負責人是負責管理產品待辦的唯一人員 產品待辦管理包含 : 清晰的表達產品待辦項目 ; 排序所有產品待辦的項目, 使其最佳來達成目標與任務 ; 對開發團隊所做的工作之價值來最佳化 ; 確保產品待辦是可以看的到的, 是透明化, 以及清晰表達的, 同時顯示 Scrum 團隊接 下來要做的事 ; 以及 確保開發團隊有足夠深入了解產品待辦項目 以上工作也許是產品負責人來做, 或者由開發團隊來做 無論何者, 產品負責人都要對其 負責 產品負責人是一個人, 而不是一個委員會 產品負責人可以代表一個委員會對於產品待辦 的期望要求, 但是所有人想要更改產品待辦項目的優先順序都必須經過產品負責人 共享的條約 頁數 5
整個公司組織必須尊重他 / 她的決定, 如此才能確保產品負責人的成功 產品負責人對於產品待辦的內容和順序之決定必須是透明化的 沒有人允許來告訴開發團隊去做不同的需求項目 另一方面開發團隊也不允許去做其它人説的 開發團隊 開發團隊包含專業人員們, 這些人員們的工作在於短衝的最後能夠發表一個具有逐步遞增潛力可發行的 " 完成 " 版本 只有開發團隊中的成員能夠發表遞增成品 公司組織成立開發團隊並且授予權力, 讓他們自我管理他們的工作 開發團隊的效率和效 用將得到最佳的協作 開發團隊具有下列特性 : 自我管理的 沒有人 ( 甚至 Scrum 隊長 ) 有權力去告訴開發團隊應該如何將產品待辦轉 換成具有逐步遞增的有潛力可發行之功能 開發團隊是跨職能的團隊, 擁有開發逐步遞增產品的所有技能 ; Scrum 的開發團隊內只有開發者這個頭銜, 不管工作的內容性質為何 ; 這條規定沒有任何例外 ; Scrum 的開發團隊內並沒有小團隊, 無論是否有特別的專業領域, 例如測試或者商業分析 ; 這條規定沒有任何例外 ; 同時開發團隊內人員也許有專業的技能和專注的領域, 然而責任追究歸屬於整個開發團隊 開發團隊的大小最理想的開發團隊的大小應該是小而且可以保持快捷, 同時大的可以在短衝內來完成重大的工作 少於三個人的開發團隊會減低互動以至於只能達到較少的工作成果 太小的開發團隊在短衝期間可能會遭遇技能上的限制, 進而導致開發團隊無法發表一個具有逐步遞增潛力的版本 超過九個人則需要太多的協調 對於經驗工作流程的管理來説, 大型的開發團隊會產生太多的複雜性 產品負責人與 Scrum 隊長這兩個角色並不包括在開發團隊的人員數目上, 除非他 / 她們同時參與執行短衝待辦上的工作 Scrum 隊長 Scrum 隊長對於確認 Scrum 是被理解與制訂來負責 Scrum 隊長確認 Scrum 的團隊堅持遵守 Scrum 理論, 實際作業, 和規則 共享的條約 頁數 6
Scrum 隊長對於 Scrum 團隊來説, 他 / 她是一位服務領導人 Scrum 隊長幫助那些 Scrum 團 隊以外的人了解他 / 她們與 Scrum 團隊的互動中, 那些是有幫助的與那些是沒有幫助的 Scrum 隊長幫助所有人改變他 / 她們的互動, 以此來提升 Scrum 團隊所能産生的最大價值 Scrum 隊長對產品負責人所提供的服務 Scrum 隊長對產品負責人提供多方面服務, 其中包含 : 找尋有效管理產品待辦的各種技巧 ; 幫助 Scrum 團隊了解為何需要清晰而且簡明的產品待辦項目 ; 了解在一個經驗工作的環境中之產品的規劃 ; 確認產品負責人知道如何來排序產品待辦使其達到最大的價值 ; 了解以及實際奉行敏捷性 ; 以及, 必要時, 幫忙 Scrum 事件的進行 Scrum 隊長對開發團隊所提供的服務 Scrum 隊長對開發團隊提供多方面服務, 其中包含 : 指導開發團隊在自我管理以及跨職能方面 ; 幫助開發團隊創造高價值的產品 ; 移除開發團隊進展中的路障 ; 必要時, 幫忙 Scrum 事件的進行 ; 以及, 當組織的整體環境並沒有完全採用或者了解 Scrum 的情況下, 能夠指導開發團隊 Scrum 隊長對公司組織所提供的服務 Scrum 隊長對公司組織提供多方面服務, 其中包含 : 帶領跟指導公司組織在 Scrum 的採用 ; 在公司組織內計劃 Scrum 的實施 ; 幫助員工們以及利益相關者了解以及制定 Scrum 和經驗工作的產品開發 ; 引發 Scrum 團隊增加生産力的改變 ; 以及, 在同一個公司組織內, 與其它 Scrum 隊長共同來增加 Scrum 的應用以及其效能 Scrum 事件 Scrum 使用固定的事件來產生規律性, 以此來減少其它會議的必要 所有事件都是限時事 件, 這樣使的每一個事件限制在最長的時間範圍內 一但短衝開始, 它的期間是固定的, 共享的條約 頁數 7
因此不能被減短或者加長 當事件的目標己達成, 剩下的事件可以提早結束 ; 如此可以確定時間被適當地使用而不會造成流程中的浪費 短衝本身涵蓋了其它的所有事件, 除了短衝, 其它每一個事件都是用來執行檢驗與調適的正式機會 這些事件都是特別設計用來達成透明化與檢驗 跳過這些任何一個事件會導致透明化的降低以及執行檢驗與調適的機會 短程衝刺 ( 短衝 ) Scrum 的核心在於短衝, 它是固定一個月或更短時間的限時, 在這段時間內創造出一個 " 完成 ", 可使用, 以及具有逐步遞增潛力可發行的產品 在努力開發過程的從頭到尾之間, 短衝通常具有一致不變的期限 前一個短衝結束後, 新的下一個短衝緊接馬上開始 短衝由以下事件所組成 : 短衝計劃會議, 每日 Scrum 匯報, 開發工作, 短衝展示會議, 以及短衝回顧檢討會議 在短衝期間 : 任何的改變都不能危害到短衝的目標 ; 對品質的目標不能降低 ; 以及, 當發現更多細節時, 產品負責人與開發團隊之間對範圍內要做的事可能會要更明確來 磋商 每一個短衝都可以被當成是一個專案, 期限是一個月內 就如同專案一般, 短衝被用在完成某些事情 每一個短衝都有要做那些事情的計劃, 一個設計過以及具有彈性的計劃用來指導如何做這些事, 工作內容, 以及結果產品 短衝期限在一個月內 當短衝期限太長的話, 要做那些事情的計劃也許會改變, 複雜性也許會增加, 同時風險也許會增加 短衝們能達成可預測性, 可以用來確認至少在每一個月內進度的檢驗與調適性 短衝同時將成本的風險限制在一個月內 取消短衝短衝可以在期限內被取消 只有產品負責人有權力來取消短衝, 雖然他 / 她的這個決定可能受到來自利益相關者, 開發團隊, 或者 Scrum 隊長的影響 如果短衝目標變成荒廢不重要, 那麼短衝就會被取消 通常這會發生在公司改變方針或者市場上或科技上的狀況改變 一般而言, 如果情況己經不合理可行的話, 短衝是應該被取消的 然而, 由於短衝的期限很短, 實際上是很少被取消的 共享的條約 頁數 8
當短衝被取消, 任何 " 完成 " 的產品待辦項目都會被展示 如果成果的任何部份是具有潛力發表的話, 產品負責人通常會接受這個成果 所有沒做完的產品待辦項目都會被放回去產品待辦中, 然後重新評估 花在它們身上的工作會很快地貶值, 因此必須經常地重新評估 取消短衝損耗資源, 因為每個人都必須重新集合在另外一個短衝計劃會議來開始另一個短衝 取消短衝對 Scrum 團隊會造成重大創傷, 因此是非常不尋常的 短衝計劃會議 短衝內要做的工作會在短衝計劃會議中來訂定 工作計劃是由整個 Scrum 團隊協同來制定的 短衝計劃會議是限時的, 以一個月的短衝來説最多八小時爲上限 對於少於一個月的短衝, 這個會議時間通常會縮短 Scrum 隊長確定會議會召開以及參與人員了解會議的目的 Scrum 隊長教導 Scrum 團隊在時間內完成 短衝計劃會議回答以下問題 : 這次短衝可以發表什麼樣的遞增成品? 什麼樣的工作是必須的才能夠達成遞增成品的發表? 第一個討論題目 : 這次短衝能做什麼? 開發團隊努力來預測在這次短衝內能開發出什麼功能 產品負責人討論這次短衝所應該達成的具體事項, 以及如果完成那些產品待辦項目可以達成這個目標 整個 Scrum 團隊協同工作來了解短衝的工作項目 這個會議的輸入項目包含 : 産品待辦, 最近的遞增成品, 開發團隊在短衝內能力的預測, 以及開發團隊的過去績效 從產品待辦之中要選出那些多少的項目完全取決於開發團隊 只有開發團隊可以評估下一個短衝所能達成的項目 首先開發團隊預測短衝內能夠達成那些產品待辦項目之後, 接著 Scrum 團隊草擬本次的短 衝目標 短衝目標經由短衝內產品待辦的完成來達到, 同時提供開發團隊方向指引出為何 要造這次的遞增成品 共享的條約 頁數 9
第二個討論題目 : 如何完成所選的工作? 在設定短衝目標與選出產品待辦項目之後, 開發團隊決定如何在這次短衝內, 建造這個功能來做出一個 " 完成 " 的遞增成品 短衝待辦指的是 : 這次短衝所選的產品待辦項目加上如何完成它們的計劃 開發團隊通常從設計整個系統開始, 到如何將產品待辦轉換成一個可運作的遞增成品 工作有不同的多寡, 或不同的預估工作量 然而, 在短衝計劃會議中, 應該計劃足夠的工作給開發團隊, 已此來預估本次短衝所能完成的工作 在短衝計劃會議的最後, 開發團隊規劃出在短衝前幾天內所要做的工作, 通常以一天或更少為一個單位 自我管理的開發團隊在短衝計劃會議中以及必要時在整個短衝期間內, 接受執行短衝待辦中的工作 產品負責人能夠幫助解釋清楚所選定的產品待辦項目們以及折衷這些項目 如果開發團隊 發現工作項目太多或太少, 他們可以與產品負責人重新商討所選的產品待辦項目們 開發 團隊也可以邀請在技術性上面或者其它領域的專家一起來參加會議提供建議 在短衝計劃會議最後, 開發團隊應該能夠解釋給產品負責人以及 Scrum 隊長, 他們要如何 地自我管理來達成短衝目標以及開發出預定的遞增成品 短衝目標 短衝目標是一個在執行產品待辦過程中所必須達到的方向目標 它提供開發團隊一個指 引, 用來解釋爲什麼團隊要來做這個遞增成品 短衝目標是在短衝計劃會議中來產生的 短衝目標提供開發團隊在短衝期間內要達成的功能的一些彈性 所選定的產品待辦項目會 提供一個連貫的功能, 亦即是短衝目標 短衝目標可以是任何其它的連貫性來促使開發團 隊一起合作而不是分開獨自做 當開發團隊開始工作, 他 / 她們會牢記短衝目標 開發團隊做出要的功能和科技來滿足短 衝目標 如果開發出來的作品和開發團隊預期的不同, 他 / 她們會跟產品負責人溝通商量 本次短衝待辦之範圍 每日 Scrum 匯報 每日 Scrum 匯報是一個 15 分鐘時限的時間盒事件, 它讓開發團隊能夠同步他 / 她們的開發 活動以及對接下來的 24 小時定一個計劃 要達成的話必須檢驗上次每日 Scrum 匯報後的 工作內容, 以及預估下一次每日 Scrum 匯報前所能完成的工作內容 每日 Scrum 匯報在同一時間與地點每天舉行, 以減低其複雜性 在匯報會議中, 開發團隊 成員們解釋 : 共享的條約 頁數 10
我昨天做了什麼事來幫助開發團隊達到短衝目標? 我今天要做什麼事來幫助開發團隊達到短衝目標? 是否有任何阻礙物在防止我或者開發團隊達到短衝目標? 開發團隊借由每日 Scrum 匯報來檢驗達到短衝目標的進度, 以及檢驗能否完成短衝待辦內的工作進度趨勢 每日 Scrum 匯報提升了開發團隊達到短衝目標的可能性 每天開發團隊應該了解如何打算以一個自我管理的團隊來共同達成短衝目標以及在短衝最後來開發出預定的遞增成品 開發團隊或者成員們通常會在每日 Scrum 匯報後馬上討論細節或調整或重新計劃短衝的其餘工作 Scrum 隊長確認開發團隊有每日 Scrum 匯報, 然而開發團隊對於帶領指導每日 Scrum 匯報必須要負責 Scrum 隊長教導開發團隊要將每日 Scrum 匯報保持在 15 分鐘時限的時間盒內 Scrum 隊長強制規定只有開發團隊成員們才能參與每日 Scrum 匯報 每日 Scrum 匯報強化團隊溝通, 減少其它會議, 發現並設法移除開發上障礙物, 突顯並促進快速地做決定, 以及加強提升開發團隊整體的知識水平 這是一個用來做檢驗與調適的重要關鍵會議 短衝展示會議 短衝展示會議在短衝期間的最後舉行, 用來檢驗遞增成品和必要時調整產品待辦 在短衝展示會議中,Scrum 團隊和利益相關者協同討論在這次短衝所完成的工作 根據上述再加上這次短衝中任何產品待辦的改變, 所有參與會議的人協同討論接下來能做完那些最有價值的事情 這是一個非正式的會議, 並不是一個進度會議, 遞增成品的展示是為了讓所有人反應意見和鼓勵所有人協同討論 對一個月的短衝來説, 這是一個 4 小時時限的時間盒的會議 對於較短地短衝來説, 這個會議則通常比較短 Scrum 隊長確認會議的召開以及出席人員了解這次短衝展示會議的目的 Scrum 隊長指導所有人在時間內完成會議 短衝展示會議包含以下的部份 : 產品負責人邀請 Scrum 團隊和主要的利益相關者來出席 ; 產品負責人解釋那些產品待辦項目已經 " 完成 " 以及那些 " 沒完成 "; 開發團隊討論在短衝期間那些做的很好, 遭遇什麼問題, 以及如何解決這些問題 ; 開發團隊展示他們 " 完成 " 的工作以及回答關於遞增成品的問題 ; 產品負責人討論現階段的產品待辦 他 / 她 ( 視情況而定 ) 根據到目前為止的進度來規 劃可能的完成日期 ; 共享的條約 頁數 11
經由短衝展示會議所提供地寶貴意見, 整個團隊協同討論接下來的短衝計劃會議要做什麼 ; 重新評估產品在市場上或者潛在使用性是否改變了原本接下來所要做最重要的事 ; 同時, 重新評估下一個預期發表產品的時間表, 預算, 潛力, 和市場 短衝展示會議的成果是一個修正後的產品待辦, 本身具有下次短衝內最可能達成的產品待 辦項目 產品待辦亦可以因應新的機會來做調整 短衝回顧檢討會議 短衝回顧檢討會議提供 Scrum 團隊一個自我檢驗的機會以及做出一個可制定的改進計劃用來使用在下次短衝 短衝回顧檢討會議緊接在短衝展示會議之後, 在下次短衝計劃會議之前 對一個月的短衝來説, 這是一個 3 小時時限的時間盒的會議 對於較短的短衝來説, 這個會議則通常比較短 Scrum 隊長確認會議的召開以及出席人員了解這次短衝回顧檢討會議的目的 Scrum 隊長指導所有人在時間內完成會議 Scrum 隊長以同事成員的身分來參與這個會議, 在 Scrum 流程上負責任 短衝回顧檢討會議的目的在於 : 檢驗上次短衝內關於人員, 工作關係, 流程, 和工具的情況如何 ; 找出並加以排列做的很好的主要項目們和具有潛力改善的項目們 ; 同時, 制定一個計劃讓 Scrum 團隊的最佳工作方式得以改善 Scrum 隊長在 Scrum 的流程架構中, 鼓勵 Scrum 團隊來改善開發的流程與操作, 讓下一個短衝更加有效能和工作更加愉快 在每個短衝回顧檢討會議,Scrum 團隊計劃不同的方式經由適當地調整 " 完成 " 的定義來增加產品的品質 在短衝回顧檢討會議的最後,Scrum 團隊應該判斷改善的地方, 然後在下一個短衝來執 行 在下一個短衝內來執行這些改善, 即是 Scrum 團隊自我檢驗的調適 雖然改善可以在 任何時間來執行, 短衝回顧檢討會議提供了一個正式的機會來專注在檢驗與調適性 共享的條約 頁數 12
Scrum 文物件 Scrum 的文物件代表工作或者價值來提供透明化以及檢驗和調適的機會 Scrum 所定義地文物件們是特別地設計在給重要資訊提供最大透明化, 如此每個人對文物件才有相同的了解與認知 産品待辦 產品待辦是一份排好順序的項目表, 產品所需的所有東西都在此 產品待辦也是唯一一份記錄對產品有任何的改變的必備要件表 產品負責人對於產品待辦必須負責, 包含其內容, 可使用性, 和它的順序 一個產品待辦永遠沒有完成 在早期的開發僅規劃了最初知道和了解的必備要件們 當產 品和環境發展後, 產品待辦也跟著發展 產品待辦是動態的 ; 它隨著產品的適用性, 競爭 力, 和用途來不斷地改變 只要產品存在, 產品待辦也同樣存在 產品待辦列出所有的特性, 功能, 必備要件, 加強項目, 以及疑難排除, 這些構成了未來 要發表的產品的所有不同項目 產品待辦項目們具有這些屬性 : 項目敘述, 順序, 預估, 和價值 當產品被使用而有了價值, 市場提供的市調, 產品待辦會成長為更多更詳盡的表格 必備 要件不斷地更改, 因此產品待辦就如同一個活的文物件 商業必備要件的改變, 市場狀況 的改變, 或者科技的改變可能都會造成產品待辦的改變 通常數個 Scrum 團隊們會一起參與對同一個產品的開發 一個產品只有一個產品待辦用來 記錄接下來要做的事 一個產品待辦可以將其中項目們來分組給 Scrum 團隊們 產品待辦細部化是一種將產品待辦增加細節, 更詳細的預估, 和項目的重要排列的動作 細部化是一個持續的流程, 在這流程中產品負責人和開發團隊協同工作在產品待辦項目的細節上 在產品待辦細部化過程中, 項目們被重新檢討和修訂 Scrum 團隊決定如何來完成細部化以及何時來完成 細部化通常以不超過開發團隊百分之十的產能為上限 然而, 產品負責人或者其它人在產品負責人的斟酌下, 產品待辦項目可以在任何時間來更新 排列在較高順序的產品待辦項目比起較低的項目, 通常比較清楚同時包含更多細節 因為 比較明確以及更多細節, 因此更精準的預估可以被達成 ; 同樣地排列較低者, 則細節較 共享的條約 頁數 13
少 産品待辦項目中那些即將會佔用開發團隊下一個短衝大部份時間的項目們會被加以分析, 如此任何一個項目才能在短衝時間盒期限內適當地來完成 產品待辦項目中能夠被開發團隊在一個短衝內來完成的被稱為是 " 備妥項目 ", 可以在短衝計劃會議中被挑選出來加以執行 產品待辦項目的透明化程度通常要經過上述地細部化活動來獲得 開發團隊對於所有的預估必須負責 產品負責人也許可以經由幫助開發團隊了解以及選擇折衷方案來影響他們, 然而最後實際做事的人有權力來決定最終的預估 監督進度來達成目標在任何時間, 用來達成開發目標的所有剩下工作量都能夠被總計出來 產品負責人至少在每次的短衝展示會議中都必須追蹤剩下工作量 產品負責人比較這次的剩下工作量與之前的量來評估預定的工作進度是否能在期望時間內達成目標 這個資訊對於所有的利益關於人是透明化的 各種不同關於趨勢走向的實際操作已經被使用在預測進度方面, 譬如 : 燃盡圖或者燃成圖 這些工具都被證實是有用的 然而它們不能用來取代經驗主義的重要性 在複雜的環境中, 未來要發生的事是無法預知的 只有已經發生的事才能用來當做前瞻性的決策 短衝待辦 短衝待辦是從產品待辦項目中所選出來在這次短衝中要做的, 同時加上發表遞增產品和達到短衝目標的計劃 短衝待辦是開發團隊對於下一個遞增成品所需要的功能以及將這功能轉換成 " 完成 " 品所需的工作之預測 短衝待辦將開發團隊用來達到短衝目標的所有工作變的顯而易見 短衝待辦是一個有足夠細節的計劃, 任何進度的改變可以在每日 Scrum 匯報中很清楚地看 到 開發團隊在整個短衝期間修正短衝待辦, 使得短衝待辦慢慢顯現成形 這個顯現成形 發生在開發團隊根據計劃來工作的期間, 了解到那些工作是必須的才能達成短衝目標 當有新工作的需要時, 開發團隊將它們加到短衝待辦內 當工作有進展或完成時, 預估剩 餘工作量會被更新 當計劃內的某些部份被認定是不需要的, 這些會被移除 在短衝期間 內, 只有開發團隊能夠改變短衝待辦 短衝待辦是非常顯而易見而且即時的工作畫面, 代 表開發團隊在短衝期間所計劃要達成的工作 短衝待辦只屬於開發團隊所擁有 監督短衝的進度 在短衝的任何時間點內, 所有在短衝待辦內的剩餘工作都可以被加總起來 開發團隊至少 在每日 Scrum 匯報追蹤這個剩餘工作的總和, 用來預測達成本次短衝目標的可能性 經由 在短衝過程本追蹤剩餘工作量, 開發團隊可以來管理本身的進度 共享的條約 頁數 14
遞增成品 遞增成品是指在短衝內所有完成的產品待辦項目們的總和, 以及所有之前短衝的遞增成品的價值總和 在短衝的最後, 新的遞增成品必須是 " 完成的 ", 所謂完成的意思是指新的遞增成品必須是可以使用的狀態並且達到 Scrum 團隊對 " 完成 " 的定義 它們必須是可以使用的狀態, 辜且不論產品負責人是否決定要實際發表 文物件透明化 Scrum 建立在透明化上 價值最佳化和風險控管的決定乃是基於對文物件的理解上 當透明化是完整時, 這些決定才有合理可靠的基礎 當文物件的透明化不完整時, 這些決定會有瑕疵, 價值會減低同時風險將會增加 Scrum 隊長必須與產品負責人, 開發團隊, 和其它相關人員一起努力來了解文物件是否完全透明化 對不完整的透明化有其相應對的作法 ; 當完整的透明化不存在時,Scrum 隊長必須幫助所有人應用最合適的作法 Scrum 隊長能夠經由檢驗文物件, 對模式的偵測, 傾聽周圍的聲音, 以及查出預期和實際結果的不同處 Scrum 隊長與 Scrum 團隊和企業組織一同合作來增加文物件的透明化 這個工作通常包括學習, 使人信服, 和改變 透明化不會在一夜之前發生, 然而它是一條道路 " 完成 " 的定義 當一個產品待辦項目或者遞增成品被說是 " 完成 " 時, 每個人都必須了解這個 " 完成 " 是什麼意思 雖然每組 Scrum 團隊都有很大的不同, 然而成員們都必須對什麼叫做工作完成有共識, 如此才能確認透明化 這就是 Scrum 團隊 " 完成 " 的定義, 用來評估遞增產品是否完成 同樣地定義用來指引開發團隊來了解在一個短衝計劃會議中, 可以選擇多少個產品待辦項 目 每一個短衝的目標在於發表逐步遞增有潛力可發行之功能, 這些功能符合 Scrum 團隊 目前對 " 完成 " 的定義 開發團隊們在每一個短衝都發表逐步遞增的產品功能 這個逐步遞增是可以運作的, 也就是說產品負責人可以選擇馬上發行 如果 " 完成 " 的定義對遞增成品來說是開發組織企業的慣例, 標準, 或者準則, 那麼所有的 Scrum 團隊都至少必須要遵守 如果 " 完成 " 對遞增成品不是開發組織企業的慣例, 那麼 Scrum 中的開發團隊就必須對這個產品下一個合適 共享的條約 頁數 15
地 " 完成 " 的定義 如果一個系統或產品發行有好幾個 Scrum 團隊一起在做, 那麼所有 Scrum 的開發團隊們就必須一起互相來下 " 完成 " 的定義 每一個遞增成品都是所有之前遞增成品們的新增, 並且徹底地測試過以確保所有遞增成品都能運作 隨著 Scrum 團隊的成長, 它們對 " 完成 " 的定義會擴大來包含更多更嚴謹的標準以達到更高的品質 任何一個產品或系統都應該有一個 " 完成 " 的定義, 做為任何有關的工作的標準 附注 Scrum 是免費的, 由本指南提供 Scrum 的角色, 文物件, 事件, 和規則是不能改變的 雖然採用一部份的 Scrum 是可能的, 然而結果就不是 Scrum 了 Scrum 只能完整的存在, 本身才能成為其他技巧, 方法和運作的容器 如此才可以確保 Scrum 的良好運行 感謝人員 在對 Scrum 有所貢獻的無數人當中, 我們應該指出那些在前十年中提供幫助的人們 首先,Jeff Sutherland 以及與他一起工作的 Jeff McKenna, 還有 Ken Schwaber 和 Mike Smith 以及 Chris Martin 更多的其它人在隨後的許多年的貢獻, 如果沒有這些人的幫助,Scrum 將不會如同今天這般詳盡 歷史 Ken Schwaber 和 Jeff Sutherland 在 1995 首先在 OOPSLA 研討會議上一起提出 Scrum 那次的演說基本上是 Ken 和 Jeff 在之前過去的數年之間運用 Scrum 所學到的記錄 Scrum 已經被認為是具有長的歷史 對於那些首先試用 Scrum 以及讓 Scrum 更詳盡的公司們 :Individual, Inc., Fidelity Investments, 和 IDX( 現為 GE Medical), 在此向它們致敬 本 Scrum 指南記錄了 Jeff Sutherland 和 Ken Schwaber 在 Scrum 二十多年的開發與持續支援 其它來源所為你 / 妳提供的模式, 流程, 和見解, 來補充 Scrum 的架構 這些提供了最佳化的生產力, 價值, 創造力, 和自我滿足 共享的條約 頁數 16
繁體中文翻譯 本繁體中文指南 ( 版本 1.0.5) 是從 Ken Schwaber 和 Jeff Sutherland 的英文原版翻譯而來 繁體中文翻譯團隊包含 :Andrew Lin, PMP, PMI-ACP, CSM, CSPO, CSP, SPC4 (andrewlin@01uni.com) 2016 年版本更新說明 包含所有 2013 的內容不變, 並新增 Scrum 的核心價值 ( 第四頁 ) 當 Scrum 的核心價值 : 承擔, 勇氣, 專注, 開放, 和尊重, 被 Scrum 團隊所體現與實踐 時,Scrum 的三個支柱 ( 透明化, 檢驗, 與調適性 ) 將成真並且幫助團隊建立互信 Scrum 的團隊成員經由執行 Scrum 的事件, 角色, 和文物件的過程來學習和探索這些核心價值 成功的執行 Scrum 取決於成員能否更熟練的融入這五個核心價值 成員親自致力於實現 Scrum 團隊的目標 Scrum 團隊成員有勇氣來做正確的事以及解決棘手的問題 每個人都專注在短程衝刺的工作以及 Scrum 團隊的目標 Scrum 團隊和其利益相關者同意對所有工作和執行上的挑戰完全開放 Scrum 團隊成員相互尊重彼此是有能力與獨立的人員 共享的條約 頁數 17