--- tags: agile --- # The Scrum Guide ## URL ### PDF (en)https://reurl.cc/2oErbr (ch)https://reurl.cc/WXv3qx ### Teddy對於Scrum的解釋系列 https://reurl.cc/NZyRWm ## What is Scrum? Scrum is a lightweight framework ,幫助人們產出價值 Scrum需要一位 "Scrum Master" 來指導(營造)環境: 1. 由一位產品負責人Product Owner(OP)將需求整理成一份代辦清單(Backlog) 2. Scrum team 在一個Sprint中將於Backlog挑選的job轉化成value increment 3. Scrum team 和利害關係人(stakeholder)檢視成果,並為下一個Sprint進行調整 4. Repeat Scrum淺顯易懂,在Scrum framework中刻意留白,只定義理論所需要的部分, Scrum Guide只提供使用者的關係與互動指引,不給詳細的使用說明。 在framework中可以使用各種不一樣的流程、技術、方法。 Scrum適合用來解決複雜但輕量化的問題 ## 理論 Scrum建立在"經驗主義"和"精實思維"之上 經驗主義->堅信知識來自經驗,根據觀察到的事物做出決策 精實思維->減少浪費,專注於根本 以迭代(iterative)和增量(incremental)得方法來優化對於未來的預測性及風險 Scrum有以下特性 * 透明性(Transparency) 流程和工作必須令執行工作和接受工作的人可見 * 檢視性(Inspection) 必須要經常檢視Scrum的工作及當前的進度,以便發現偏差/問題 Scrum中提供了五個事件來維持Inspection的節奏 * 調適性(Adaptation) 若出現偏差時要及時修正 ## Scrum的價值觀 Scrum包含以下五種價值觀 1. 承諾(Commitment)->致力於達成目標 2. 專注(Focus) ->專注在Sprint的Job 3. 開放(Openness) ->面對stakeholder及挑戰時 4. 尊重(Respect) ->成員互相尊重 5. 勇氣(Courage) ->面對問題 ## Scrum團隊 * Scrum Master(SM) 1名 * Product Owner(PO) 1名 * Developer #### 補充: 團隊中沒有階級之分、成員跨職能、自我管理 團隊成員人數通常為10人以下 ### 成員說明 ### Developers: 開發人員指在每個Sprint中可打造任何增量(Incremental)的成員 責任如下: * 打造一份Sprint代辦清單(Backlog) * 遵循"Complete"的定義,以提升品質 * 每天調整邁向Sprint目的的企劃 * 對彼此負責 ### Product Owner(PO) PO是一個人,不是一個委員會 負責將團隊打造出來的產品價值最大化 同時也負責Backlog的管理,包含: * 明確的描述Product之目的 * 創造清楚的Backlog * 對待辦事項進行排序 * 確保Backlog是透明、可見、可理解的 ### Scrum Master(SM) SM負責按照Scrum Guide來建立團隊的Scrum 幫助團隊內的每個人瞭解其理論以及如何時做 SM以多種方式服務Scrum團隊,包含以下幾種: * 以教練的方式管理團隊 * 協助團隊專注於打造出滿足"Complete"定義的"Incremental" * 促使團隊移除障礙 * 確保Scrum Event都舉行,並保持在其timebox內進行 SM以多種方式服務PO,包含以下幾種: * 協助找到有效定義Product目的和管理Backlog的技巧 * 令團隊理解為何需要簡單明瞭的Backlog * 在"Complex"的環境下建立以"經驗導向"為主的 Product Plan * 必要時引導stakeholder進行合作 SM以多種方式服務組織,包含以下幾種: * 在組織採用Scrum的時候以教練的方式帶領 * 規劃並指導Scrum的執行 * 幫助員工和Stakeholder制定"經驗導向"的方法處理"Complex"的工作 * 移除Stakeholder和Scrum team之間的障礙 ## Scrum Events ### Sprint 一個Sprint為期1~4周,一個Sprint結束下一個就緊接著開始 每個Sprint中皆包含了 * Sprint Planning * Daily Scrum * Sprint Review * Sprint Retrospective 在Sprint期間 * 不得做出危及Sprint目的之改變 * 不得降低品質 * Backlog根據需要Refined * 隨著瞭解的越多,範疇可能會和PO做進一步的重新協商 Sprint期間不可過長,將導致複雜度上升,令Sprint目的失效,風險增高 偏好較短的Sprint,成本與風險控制較為可控,可預測性也將會提高 **若Sprint目的已經不合時宜,可由PO取消Sprint** ### Sprint Planning 會議中安排將要在Sprint中執行的工作來啟動Sprint 由整個Scrum團隊一起產出 PO確保會議參與者準備好最重要的Backlog以及如何應對到產品的目的 同時團隊也可邀請其他人參與會議以提供建議 會議中會處理以下主題: 1. 為何這次Sprint會有價值? PO提議產品如何在Sprint中增加其價值,之後整個團隊一起在會議結束前定義出Sprint的目的 並和stakeholder說明此Sprint的價值 2. 這次Sprint能完成什麼? 和PO討論,Developer由Backlog中挑選一些Item放入Sprint中 3. 如何完成挑選的工作項目? 由Developer將挑選到的Iteam拆解成一天能完成的子工作項目,拆解方式由Developer決定 ### 補充 Spirnt Planning有timebox限定,以一個月的Sprint來說最多8HR Sprint越短會議越短 ### Daily Scrum 每日的Scrum會議屬於Developer的 用於檢視目前Sprint之進度及其障礙,並根據所需調整待辦清單 會議只進行15min,每日在同時同地舉行 ### Sprint Review 檢視此Sprint的成果及未來的調整方向 團隊同時也向stakeholder Demo此Sprint的成果 以及環境發生了什麼變化 基於這些資訊,調整合作方式及Backlog 以一個月的Sprint為例,此會議最多4HR ### Sprint Retrospective ###### tags: `Agile`
×
Sign in
Email
Password
Forgot password
or
By clicking below, you agree to our
terms of service
.
Sign in via Facebook
Sign in via Twitter
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
New to HackMD?
Sign up