更多請關注微信公眾號 SystemEngineeringLab
Scrum Guide: https://www.scrumguides.org/scrum-guide.html
Scrum是一種敏捷過程框架，不同於其他敏捷開發方法，Scrum不僅僅適用於軟件開發領域。
1. Srum 的目標
Deliver the highest business value in the shorttest time
Scrum的目標是“交付最高的商業價值，通過盡量短的時間”。用英文表達可能更准確一些，中文的語義比較容易混淆。Scrum的目標並不是“在最短的時間內交付最高的商業價值”，它強調的不是最短的時間，而是價值。我們關注的是如何在交付最高價值的前提下花費更少的時間。
2. 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
2.1 價值觀
勇氣：面對難題團隊成員都有勇氣做正確的事情和工作
專注: 團隊成員要專注於沖刺要完成的工作以及團隊目標
承諾: 團隊成員對完成Sprint目標做出承諾
尊重：團隊成員之間都尊重對方是有能力的、獨立的人
開放：Scrum團隊以及利益相關者對所有的工作以及完成工作所面臨的挑戰的開放性一致認同。
2.2 角色
Scrum核心框架包含三個角色，即PO、SM、DevTeam。與傳統的開發方法不同，Scrum的研發團隊不再有細分的例如系統架構師、后端工程師、前端工程師、UI工程師等角色，而是將整個開發團隊統一在了“Development Team”這一Scrum角色下。以上三個角色構成了 "Scrum Team"。
Product Owner
關鍵職責
- 為Product Backlog負責
- 為投資回報率負責
關鍵屬性: - 是利益相關者和客戶的代表
- 只能由一個人擔任
- 有絕對的決策權
- 隨時能夠被團隊找到
- 決定產品發布日期和內容
- 不能兼任Scrum Master
- 根據業務價值和重要性為PBI排序
- 能夠決定Sprint是否取消
Scrum Master
職責
- 促進Scrum的進行，為開發團隊移除障礙
特征： - 沒有權利
- 服務型領導
Development Team
職責
DevTeam的職責就是實現Sprint目標，在每個Sprint結束交付可潛在發布的產品增量。
特征：
- 自組織
- 跨職能：團隊是跨職能的，具備交付產品所需要的所有能力
- 同地協作
- T型人才，成員具備“一專多通”的特點
- 沒有頭銜，大家都是平等的團隊成員
- 開發團隊的成員必須是全職參與
- 人數范圍3-9人：人數不宜過多或過少。過少的團隊無法具備跨職能的要求，過多的團隊降低溝通效率
- 沒有子團隊：團隊是平級團隊，子團隊增加了溝通的成本
2.3 工件
產品清單 - Product Backlog
Product Backlog是已排序的產品需求列表，它定義了最終要交付什么(What)。
Product Owner 對Product Backlog負責，其有權決定產品清單的內容，例如哪些需要納入產品清單、哪些需要修改、哪些需要刪除、哪些PBI(Product Backlog Item)優先級需要調整。大多數的PBI對客戶有實際的業務價值，有些可能針對客戶來說沒有直接的業務價值。原則上PO認為PBI對整個產品的交付是有價值的，那么它也可以放入PBL.
PBI最常見的表述形式是用戶故事，但這不是絕對的。用戶故事本身不是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的總和，在沖刺結束時作為產品增量交付。增量是穩定的、可工作的產品組成部分。沖刺中沒有完成的部分不納入增量。
2.4 事件
沖刺 - Sprint
Spring的目標是完成可潛在可交付的產品增量
- Scrum的核心，也是Scrum開發方法中的基本單元
- 固定的時間盒
- Sprint是一個容器，以沖刺計划開始，以沖刺評審和沖刺回顧結束
沖刺計划 - Sprint Planning
- 確定當前沖刺所要完成的工作范圍
- 從Product Backlog中選擇當前沖刺需要完成的PBI
- 確定Sprint Backlog，以支撐所選的PBIs
- 以兩周的沖刺為例，建議會議時間為4小時
每日站會 - Daily Scrum
- 開發團隊成員必須到場，PO 和SM可選參加
- 歡迎其他人參加每日站會，但只允許開發團隊成員發言
- 每天同一時間、同一地點
- 准時開始，即使有開發團隊成員缺席
- 控制在15分鍾以內
- 會議模式基於三個問題：
- 昨天完成了什么
- 今天准備完成什么
- 遇到了什么障礙阻礙了自己或團隊達成沖刺目標
沖刺評審 - Sprint Review
評審的目的並不在於評價已完成產品增量的好壞，更不是在沒有達到既定要求時的批判和追責。評審的本質在於通過現場的交流和演示，獲得利益相關者對產品增量的反饋！反饋！反饋！
主要內容：
- 審視已經完成的工作以及已經計划但是沒有完成的工作
- 向利益相關者展示已經完成的工作（Demo）
- 與利益相關者協作，進一步明確后續要做的工作
沖刺回顧 - Sprint Retrospective
回顧會議的精髓在於檢視和調整，以期持續改進：
- 回顧已經過去的沖刺
- 識別持續改進的行動項並達成一致
典型的會議內容： - 三個主要問題：
- 在當前沖刺中，哪些做的好？
- 在當前沖刺中，哪些做的不好？
- 為了提高生產力，在下一個沖刺中哪些需要改進？
- 以兩周的沖刺為例，建議時間為一個半小時
- 回顧會議由SM負責推進
Scrum工作流
Scrum的工作流以Sprint為核心，通過迭代和增量的方式逐步完成最終產品的交付。
- 產品需求被匯總到Product Backlog，PO依據業務價值、重要性等對PBI進行排序。
- 沖刺會議標志着Sprint的正式開始，團隊對輸入的PBL進行選擇，確定本次沖刺所需要完成的PBI。DevTeam基於所確定的PBI進行任務拆分，形成Sprint Backlog。
- DevTeam執行開發過程，交付潛在可發布的產品增量。
討論
Scrum不是具體的敏捷方法，它通過價值觀、角色、工件和事件等要為我們搭建了一個骨架，但骨架內填充的內容就需要具體情況具體分析了。
同其他敏捷開發方法不同的是Scrum更具有普適性，它不僅僅適用於軟件開發領域。
本文主要是對Scrum框架的核心元素進行了總結和記錄，理論看戲去簡單，但落地Scrum卻不容易，尤其是結合不同行業的工程實踐更加導致Scrum落地的復雜性，而這也恰恰是Scrum實踐者所需要攻堅的問題。
寫在最后
這已經是關於敏捷的第二篇博文了，基本上對敏捷和Scrum做了基本的介紹，后續的博文我們更關注如何在汽車行業中實施敏捷。