敏捷開發（Scrum 指南）
2025-02-10 15:35:59 57 1 舉報 0
0
登錄查看完整內容
作者其他創作
大綱/內容
Scrum 定義
Scrum 是一個框架，在此框架中人們可以解決複雜的自適應難題，同時也能高效並創造性地交付可能最高價值的產品。
特點
輕量的
易於理解的
難以精通的
組成
Scrum 框架由 Scrum 团队以及與之相關的角色、事件、工件和規則組成。框架中的每個
部分都有其特定的目的，其對於 Scrum 的成功與使用是至關重要的。
部分都有其特定的目的，其對於 Scrum 的成功與使用是至關重要的。
規則
Scrum 的規則將角色、事件和工件組織在一起，管理它們之間的關係和互動。
Scrum 應用
1. 研究與識別出可行的市場、技術和產品能力；
2. 開發產品和增強功能；
3. 產品和增強功能，頻率高到一天發布多次；
4. 開發與支持雲（在線、安全、按需）和其他運行環境來提供給產品使用；
5. 支援及更新產品。
Scrum 理論
基於經驗主義－經驗性過程控制理論
三大支柱
透明
對於那些對產出負責的人來說，過程中的關鍵環節必須是顯而易見的。要擁有透明度，就必須為這些
關鍵環節制定統一的標準，這樣所有關注這些環節的人都會對觀察到的事物有統一的理解。
關鍵環節制定統一的標準，這樣所有關注這些環節的人都會對觀察到的事物有統一的理解。
檢視
Scrum 的使用者必須經常檢視 Scrum 的工件和完成 Sprint 目標的進展，以便發現不必要
的差異。檢視不應該過於頻繁而阻礙工作本身。當檢視是由技能嫻熟的檢視者在工作中勤
勉地執行時，效果最佳。
的差異。檢視不應該過於頻繁而阻礙工作本身。當檢視是由技能嫻熟的檢視者在工作中勤
勉地執行時，效果最佳。
適應
如果檢視者發現過程中的一個或多個方面偏離可接受範圍以外，並且將會導致產品不可接
受時，就必須對過程或過程化的內容加以調整。調整工作必須盡快執行如此才能最小化進
一步的偏離。
受時，就必須對過程或過程化的內容加以調整。調整工作必須盡快執行如此才能最小化進
一步的偏離。
四個事件
Sprint 計劃會議
每日 Scrum 站會
Sprint 評審會議
Sprint 回顧會議
Scrum 價值觀
承諾
勇氣
專注
開放
尊重
Scrum 團隊
PO（產品擁有者）
職責
將開發團隊開發的產品價值最大化
管理產品待辦清單的唯一負責人
清晰地表述產品待辦清單項目；
對產品待辦清單項目進行排序，使其最好地實現目標和使命；
優化開發團隊執行工作之價值；
確保產品待辦清單對所有人是可見、透明和清晰的，同時顯示 Scrum 團隊下一步要做的
工作；
工作；
確保開發團隊對產品待辦清單項目有足夠深入的了解。
產品開發小組（Product Development Team）
組成
開發團隊包含各種專業人員，負責在每個 Sprint 結束時交付潛在可發布並且“完成”的
產品增量。在 Sprint 評審會議上，一個“完成”增量是必需的。只有開發團隊成員才能
創建增量。
產品增量。在 Sprint 評審會議上，一個“完成”增量是必需的。只有開發團隊成員才能
創建增量。
特點
是自組織的
是跨職能的團隊
不認同開發團隊成員的任何頭銜
不認同開發團隊中所謂的「子團隊」
開發團隊中的每一個成員也許有專長和專注的領域，但是責任屬於整個開發團隊。
規模
（3，9]
SM（Scrum Master）
服務型領導
最大化 Scrum 團隊所創造的價值
服務於產品負責人
確保 Scrum 團隊中的每個人都盡可能地理解目標、範圍和產品領域
找到有效管理產品待辦清單的技巧
幫助 Scrum 團隊理解為何需要清晰且簡明的產品待辦列表項目
理解在經驗主義的環境中的產品規劃
確保產品負責人懂得如何來安排產品待辦清單使其達到最大化價值
理解並實踐敏捷性
當被請求或需要時，引導 Scrum 事件
服務於開發團隊
作為教練在自組織和跨職能方面給予開發團隊以指導
幫助開發團隊創造高價值的產品
移除開發團隊工作進展中的障礙
按被請求或需要時，引導 Scrum 事件
在 Scrum 尚未完全採納和理解的組織環境中，作為教練指導開發團隊
服務於組織
領導並作為教練指導組織採納 Scrum
在組織範圍內規劃 Scrum 的實施
幫助員工和利益相關者理解並實施 Scrum 和經驗導向的產品開發
引發能夠提升 Scrum 團隊生產力的改變
與其他 Scrum Master 一起工作，增強組織中 Scrum 應用的有效性
Scrum 事件
作用
使用固定的事件來產生規律性，以此來減少 Scrum 以外的其他會議的必要
在 Scrum 中的每個事件都是用來進行檢視和適應的正式機會
Sprint
Sprint 是 Scrum 的核心，[2週,4週]，長度保持一致
構成
Sprint 計劃會議
每日 Scrum 站會
開發工作
Sprint 評審會議
Sprint 回顧會議
要求
不能做出有害於 Sprint 目標的改變
不能降低質量的目標
隨著對資訊掌握的增加，產品負責人與開發團隊之間對範圍內要做的事可以加以澄清
和重新協商。
和重新協商。
每個 Sprint 都可以被視為一個項目
Sprint 的長度限制在一個月內
取消 Sprint
在 Sprint 時間盒結束之前取消
只有產品負責人才有取消 Sprint 的權力
某個 Sprint 對其所在環境來說失去了價值和意義，那麼它就應該被取消
由於Sprint的時間都很短，所以取消Sprint通常都是不太合理的。
評審重估
造成重創
Sprint 計劃會議
是由整個 Scrum 團隊共同協作完成的
是有時間盒限定的
作用（回答以下問題）
接下來的 Sprint 交付的增量中要包含什麼內容？
產品負責人講解 Sprint 的目標以及達成該目標所需完成的產品待辦列表項。整個 Scrum 團隊協同工作來理解 Sprint 的工作。
Sprint 會議的輸入
是產品待辦清單
最新的產品增量
開發團隊在這個 Sprint 中能力的預測
開發團隊的以往表現
草擬Sprint 目標
要如何完成交付增量所需的工作？
Sprint 待辦清單
選出的產品待辦清單項目
如何交付它們的計劃
預估工作量
規劃工作
自組織地領取
產品負責人能夠幫助解釋清楚所選定的產品待辦清單項目，並作出權衡。
解釋如何完成
Sprint 目標
在當前 Sprint 通過實現產品待辦列表要達到的目的
為開發團隊提供指引
為開發團隊在 Sprint 中所實現的功能留有一定的弹性
所選定的產品待辦清單項目將提供一個連貫一致的功能
如果所需工作與預期的不同，開發團隊需要與產品負責人溝通協商Sprint 待辦列表的範圍。
每日 Scrum 站會
期內每天15分鐘
檢視昨日成果
匯報今日計劃
提出遇到問題
作用
會議上不解決
Sprint 評審會議
在 Sprint 快結束時舉行
作用：用以檢視所交付的產品增量並按需調整產品待辦列表
示範增量
時長：≤4小時
包含內容
參會者包括 Scrum 團隊和產品負責人邀請的主要利益攸關者
產品負責人說明哪些產品待辦清單項目已經「完成」和哪些沒有「完成」
開發團隊在Sprint期間討論哪些工作做得好，遇到了什麼問題以及問題是如何解決的。
開發團隊展示「完成」的工作並解答有關所交付增量的問題
產品負責人討論當前的產品待辦清單的情況
所有出席會議的人就下一步的工作進行探討
評審市場或潛在產品使用方式所帶來的接下來要做的最有價值的東西的改變
為下個預期產品功能或產品能力版本的發佈評審時間表、預算、潛力和市場
輸出
修訂後的產品待辦清單
闡明很可能進入下一個 Sprint 的產品待辦清單項目
為了迎接新的機會而進行全局性的調整
Sprint 回顧會議
是 Scrum 團隊檢視自身並創建下一個 Sprint 改進計劃的機會
發生在Sprint評審會議結束之後，下個Sprint計劃會議之前
時長：≤3小時
目的
檢視前一個 Sprint 中關於人、關係、過程和工具的情況如何
找出並加以排序做得好的和潛在需要改進的主要方面
制定改進 Scrum 團隊工作方式的計劃
Scrum 工件
以不同的方式表現工作任務和價值，可以用來提供透明以及檢視和適應的機會。
產品待辦清單
是一份包含產品中已知所需每項內容的有序列表
永遠是不完整的
列出所有特性、功能、需求、增強及修復等對未來將發佈的產品進行的更新：描述、次序、估算及價值
將會成長為更大和更詳細的清單
可能需要使用能夠對產品待辦清單項進行分組的屬性
產品待辦清單精化指的是為產品待辦清單項增添細節、估算和排序的動作
排序越高的產品待辦清單項目通常比排序低的更清晰，同時包含更多細節。
開發團隊負責所有估算工作
作用：監控目標實現的進度
Sprint 待辦清單
是一組為當前 Sprint 選出的產品待辦列表項，同時加上交付產品增量和實現 Sprint 目標的計劃
至少包括一項在前次回顧會議中確定下來的高優先級的過程改進
擁有足夠細節的計劃
在 Sprint 期間，只有開發團隊可以改變 Sprint 待辦列表
作用：監控 Sprint 進度
增量
是一個Sprint完成的所有產品待辦清單項的總和，以及之前所有Sprint所產生的增量的價值總和。
在Sprint的最後，新的增量必須是「完成」的，這意味著它必須可用並且達到了Scrum團隊「完成」的定義的標準。
增量是在Sprint結束時支持經驗主義的、可檢視的和已完成的產品組成部分
增量是邁向願景或目標的一步。無論產品負責人是否決定發布它，增量必須可用。
0 條評論
下一頁
