Scrum是一種<strong>敏捷框架，不同於其他敏捷開發方法，<strong>Scrum不僅僅適用於軟件開發領域
。
Scrum敏捷框架
Srum 的目標
<code>Deliver the highest business value in the shorttest time/<code>
Scrum的目標是“交付最高的商業價值，通過儘量短的時間”。用英文表達可能更準確一些，中文的語義比較容易混淆。Scrum強調的不是最短的時間，而是價值。我們關注的是如何在交付最高價值的前提下花費更少的時間。
Scrum價值觀
勇氣：面對難題團隊成員都有勇氣做正確的事情和工作
專注: 團隊成員要專注於衝刺要完成的工作以及團隊目標
承諾: 團隊成員對完成Sprint目標做出承諾
尊重：團隊成員之間都尊重對方是有能力的、獨立的人
開放 ：Scrum團隊以及利益相關者對所有的工作以及完成工作所面臨的挑戰的開放性一致認同。
Scrum 框架的組成（3-3-5-5 模型）
3 個工件：Product Backlog、Sprint Backlog：Product Increment
3 個角色：Product Owner、Scrum Master、Development Team
5 個價值觀：勇氣 專注 承諾 尊重 開放
5 個事件：Sprint、Sprint Planning、Daily Scrum、Sprint Review、Spring Retrospective
Scrum角色
Scrum核心框架包含三個角色，即PO、SM、DevTeam。與傳統的開發方法不同，Scrum的研發團隊不再有細分的例如系統架構師、後端工程師、前端工程師、UI工程師等角色，而是將整個開發團隊統一在了“Development Team”這一Scrum角色下。
PO關鍵職責
- 為Product Backlog負責
- 為投資回報率負責
PO關鍵屬性
- 是利益相關者和客戶的代表
- 只能由一個人擔任
- 有絕對的決策權
- 隨時能夠被團隊找到
- 決定產品發佈日期和內容
- 不能兼任Scrum Master
- 根據業務價值和重要性為PBI排序
- 能夠決定Sprint是否取消
Scrum Master職責:
促進Scrum的進行，為開發團隊移除障礙
Scrum Master特徵
- 沒有權利
- 服務型領導
DevTeam的職責
實現Sprint目標，在每個Sprint結束交付可潛在發佈的產品增量。
DevTeam關鍵特徵：
- 自組織
- 跨職能：團隊是跨職能的，具備交付產品所需要的所有能力
- 同地協作
- T型人才，成員具備“一專多通”的特點
- 沒有頭銜，大家都是平等的團隊成員
- 開發團隊的成員必須是全職參與
- 人數範圍3-9人：人數不宜過多或過少。過少的團隊無法具備跨職能的要求，過多的團隊降低溝通效率
- 沒有子團隊：團隊是平級團隊，子團隊增加了溝通的成本
Scrum工件
產品清單 - Product Backlog
<strong>Product Backlog是已排序的產品需求列表，它定義了最終要交付什麼(What)
PO對Product Backlog負責，其有權決定產品清單的內容，例如哪些需要納入產品清單、哪些需要修改、哪些需要刪除、哪些PBI(Product Backlog Item)優先級需要調整。大多數的PBI對客戶有實際的業務價值，有些可能針對客戶來說沒有直接的業務價值。原則上PO認為PBI對整個產品的交付是有價值的，那麼它也可以放入PBL。
PBI最常見的表述形式是<strong>用戶故事，但這不是絕對的。用戶故事本身不是Scrum框架的一部分，Scrum並沒有要求PBI的表現形式，用戶可以使用用戶故事、用例或其他有意義的格式均可。
優秀的Product Backlog設計遵循DEEP原則
Detailed appropriately - 詳略得當
- PBI的表述要詳略得當，近期要做的PBI要足夠詳細，以便團隊能夠清晰的認識需求。同時，PBI的粒度要足夠小，能夠放到一個衝刺中執行。
- 越靠近PBL頂端的PBI要越詳細且粒度越小，越靠近底部的PBI粒度越大。
Emergent - 湧現式的
產品清單是動態的，隨著對產品認識的深入，以及產品內外部環境的變化，已有的PBI可能會被修改、廢棄，新的PBI會被加入到產品清單，因此，PBL是一個會被持續更新動態需求池。
Estimated：進行有效估算
Prioritized ：優先級排序
Sprint Backlog
SBL是在當前衝刺中開發團隊需要完成的工作任務列表，有點像傳統開發方法中的WBS，這是DevTeam對實現PBI所做出的承諾。在衝刺計劃會議中，DevTeam要對當前迭代所選擇的PBI進行任務拆解，細化為具體的工作任務，足以支撐實現這些PBIs。
Spring Backlog的形式有多樣，可以採用看板、電子表格或專門的在線系統進行記錄和追蹤。同時，拆分後的任務和PBI的對應關係也要一同記錄
產品增量 - Product Increment
Potentially Shippable Increment，PSI，潛在可交付增量
衝刺中所完成的所有的PBI的總和，在衝刺結束時作為產品增量交付。增量是穩定的、可工作的產品組成部分。衝刺中沒有完成的部分不納入增量。
Scrum事件
衝刺 - Sprint
Spring的目標是<strong>完成可潛在可交付的產品增量
- Scrum的核心，也是Scrum開發方法中的基本單元
- 固定的時間盒
- Sprint是一個容器，以衝刺計劃開始，以衝刺評審和衝刺回顧結束
衝刺計劃 - Sprint Planning
- 確定當前衝刺所要完成的工作範圍
- 從Product Backlog中選擇當前衝刺需要完成的PBI
- 確定Sprint Backlog，以支撐所選的PBIs
- 以兩週的衝刺為例，建議會議時間為4小時
每日站會 - Daily Scrum
1.開發團隊成員必須到場，PO 和SM可選參加
2.歡迎其他人參加每日站會，但只允許開發團隊成員發言
- 每天同一時間、同一地點
- 準時開始，即使有開發團隊成員缺席
- 控制在15分鐘以內
3.會議模式基於三個問題：
- 昨天完成了什麼
- 今天準備完成什麼
- 遇到了什麼障礙阻礙了 自己或團隊達成衝刺目標
衝刺評審 - Sprint Review
評審的目的並不在於評價已完成產品增量的好壞，更不是在沒有達到既定要求時的批判和追責。評審的本質在於通過現場的交流和演示，獲得利益相關者對產品增量的反饋！反饋！反饋！
衝刺評審的主要內容：
- 審視已經完成的工作以及已經計劃但是沒有完成的工作
- 向利益相關者展示已經完成的工作（Demo）
- 與利益相關者協作，進一步明確後續要做的工作
衝刺回顧 - Sprint Retrospective
1.<strong>回顧會議的精髓在於檢視和調整，以期持續改進：
- 回顧已經過去的衝刺
- 識別持續改進的行動項並達成一致
2.典型的會議內容三個主要問題：
- 在當前衝刺中，哪些做的好？
- 在當前衝刺中，哪些做的不好？
- 為了提高生產力，在下一個衝刺中哪些需要改進？
3. 以兩週的衝刺為例，建議時間為一個半小時
4. 回顧會議由SM負責推進
Scrum工作流
Scrum的工作流以Sprint為核心，通過迭代和增量的方式逐步完成最終產品的交付。
- 產品需求被彙總到Product Backlog，PO依據業務價值、重要性等對PBI進行排序。
- 衝刺會議標誌著Sprint的正式開始，團隊對輸入的PBL進行選擇，確定本次衝刺所需要完成的PBI。DevTeam基於所確定的PBI進行任務拆分，形成Sprint Backlog。
- DevTeam執行開發過程，交付潛在可發佈的產品增量。
寫在最後
Scrum不是具體的敏捷方法，它通過價值觀、角色、工件和事件等要為我們搭建了一個骨架，但骨架內填充的內容就需要具體情況具體分析了。
參考：Scrum Guide: https://www.scrumguides.org/scrum-guide.html
閱讀更多 瘋狂架構 的文章
