Scrum概論
本文並非Scrum的教學文章，而是對PMI-ACP中與Scrum相關的主要考點，進行結構化輸出和知識點整理。
Scrum入門可以參閱Scrum創始人Ken Schwaber和Jeff Sutherland撰寫的《Scrum指南》。
什麼是Scrum？
1995年，Ken Schwaber和Jeff Sutherland提出了Scrum方法並且在OOPSLA工作坊中進行了初步的實踐。
Scrum 是一個框架，在此框架中人們可以解決複雜的自適應難題，同時也能高效並創造性地交付可能最高價值的產品。
Scrum
實施Scrum對組織和項目的好處：
- 更高的生產力和更低的成本。
- 員工的參與度與工作滿意度增強。
- 更快的產品上市時間。
- 更高的質量。
- 項目干係人的滿意度提升。
Scrum框架
從整體來說，SCRUM這個框架裏面包含了這幾個核心的要素，就是我們說的3355。
三種角色：
- Product Owner
- Scrum Master
- Dev Team
三種工件：
- 產品待辦列表 Product Backlog
- Sprint待辦列表 Sprint Backlog
- 產品增量 Product Increment
五種事件：
- 迭代 Sprint
- 迭代計劃 Sprint Plan
- 每日站會 Daily standup meeting
- 評審會議 Sprint Review
- 迭代回顧 Retrospective
五種價值觀：
- 勇氣 Courage – 勇於承諾，履行承諾，敢於說不
- 開放 Open – 團隊內所有信息對所有人開放
- 專注 Focus – 全身心都用到你承諾的工作上去
- 承諾 Commitment - 願意對目標做出承諾
- 尊重 Respect – 每個人都有他獨特的價值和經驗
Scrum三大支柱
透明性 Transparency
-
過程或者項目的各個方面必須對結果負責人的透明的。
-
運用信息發射源，讓這些關鍵信息，如產品待辦事項列表，衝刺代辦事項、障礙、風險和項目進展對所有的利益相關者是透明的。
檢視 Inspection
-
團隊根據項目目標定期檢查他們的績效和進展。
-
他們不斷尋找問題和計劃的偏離。
適應 Adaptation
- 基於觀察期間的檢查，採取必要的變更流程，以避免問題再次發生，提供項目交付成功率。
三種角色
Scrum團隊由5~9個團隊成員組成。有三種類型角色：
- 產品負責人 Product Owner
- Scrum Master
- 開發團隊 Dev Team
Scrum 團隊角色
Product Owner
產品負責人的職責是將開發團隊開發的產品價值最大化。（產品負責人是一個人，而不是一個委員會。）
- 清晰地表述產品待辦列表項；
- 對產品待辦列表項進行排序，使其最好地實現目標和使命；
- 優化開發團隊所執行工作的價值；
- 確保產品待辦列表對所有人是可見、透明和清晰的，同時顯示 Scrum 團隊下一步要做的工作。
- 確保開發團隊對產品待辦列表項有足夠深的瞭解。
Scrum Master
Scrum Master負責確保所有人都能正確地理解並實施Scrum。因此Scrum Master要確保Scrum團隊遵循Scrum的理論、實踐和規則。
- 促進團隊的工作
- 幫助團隊熟悉與掌握 Scrum 價值觀與框架
- 幫助團隊排除影響生產力的障礙
- 保護團隊不受打擾
Scrum Master 服務於產品負責人
Scrum Master 以各種方式服務於產品負責人，包括：
- 確保 Scrum 團隊中的每個人都儘可能地理解目標、範圍和產品域；
- 找到有效管理產品待辦列表的技巧；
- 幫助 Scrum 團隊理解爲何需要清晰且簡明的產品待辦列表項；
- 理解在經驗主義的環境中的產品規劃；
- 確保產品負責人懂得如何來安排產品待辦列表使其達到最大化價值；
- 理解並實踐敏捷性；
- 當被請求或需要時，引導 Scrum 事件。
Scrum Master 服務於開發團隊
Scrum Master 以各種方式服務於開發團隊，包括：
- 作爲教練在自組織和跨職能方面給予開發團隊以指導；
- 幫助開發團隊創造高價值的產品；
- 移除開發團隊工作進展中的障礙；
- 按被請求或需要時， 引導 Scrum 事件；
- 在 Scrum 還未完全採納和理解的組織環境中，作爲教練指導開發團隊。
Scrum Master 服務於組織
Scrum Master 以各種方式服務於組織，包括：
- 帶領並作爲教練指導組織採納 Scrum；
- 在組織範圍內規劃 Scrum 的實施；
- 幫助員工和利益攸關者理解並實施 Scrum 和經驗導向的產品開發；
- 引發能夠提升 Scrum 團隊生產率的改變；
- 與其他 Scrum Master 一起工作，增強組織中 Scrum 應用的有效性。
Dev Team
開發團隊包含各種專業人員，負責在每個 Sprint 結束時交付潛在可發佈並且“完成”的產品增量。 在 Sprint 評審會議上，一個“完成”增量是必需的。只有開發團隊成員才能創建增量。
開發團隊具有下列特點：
- 他們是自組織的。沒有人（即使是 Scrum Master）有權告訴開發團隊應該如何把產品
待辦列表變成潛在可發佈的功能增量； - 開發團隊是跨職能的團隊，團隊作爲一個整體， 擁有創建產品增量所需的全部技能；
- Scrum 不認可開發團隊成員的任何頭銜，不管其承擔何種工作（他們都叫開發人員）。
- Scrum 不認可開發團隊中所謂的“子團隊”，無論其需要處理的領域是諸如測試、架構、運維或業務分析；
- 開發團隊中的每個成員也許有特長和專注的領域，但是責任屬於整個開發團隊。
“豬”與“雞”的寓言
豬與雞在散步，
雞：“我們一起開家餐館吧？”
豬：“好的，餐館起個什麼名字呢？”
雞：“火腿和蛋！”
豬：“我不和你一起開餐館了。因爲我得全身心付出，而你僅僅是牽涉入內。”
區分兩類人：對承擔項目的人賦予權力，使其完成必要工作，確保項目成功；無責任人員則無權對項目施加不必要的干涉。
敏捷項目的運作中，敏捷教練要保護團隊不受外部干擾。如果項目中的伸手過界的“雞”太多，則項目很難走向成功。
三種工件
Scrum 的工件以不同的方式表現工作任務和價值，可以用來提供透明以及檢視和適應的機會。 Scrum 所定義的工件是特別地設計的，是爲了給關鍵信息提供最大透明化，因此每個人對工件都需要有相同的理解。
- 產品待辦列表 Product Backlog
- Sprint待辦列表 Sprint Backlog
- 產品增量 Product Increment
Product Backlog
產品待辦列表Product Backlog即產品視角的需求清單。
- 由 Product Owner 負責維護，包括增刪及優先級。
- 用戶故事是其中一種最佳實踐。
- 每項需求都需要描述其外部價值。
Sprint Backlog
Sprint 待辦事項 Sprint Backlog即此次衝刺週期內規劃要完成的內容。
- 來源於Product Backlog。
- 由團隊評估和選擇Product Backlog中哪些放入Sprint Backlog。
- 團隊需要一起定義“完成”的標準。
Product Increment
可交付產品增量Increment即衝刺結束後可對外發布的產品功能增量部分。
- 需要關注其是可工作的軟件功能增量。
- 需要要在Scrum Review會議上進行演示。
五種事件
迭代 Sprint
Sprint（衝刺、迭代）是一個特殊的事件，或者說其一個容器事件。後續四個事件包含在其中。
- 2-4周
- 固定週期，固定時間開始，固定時間結束
- 時間盒是其一個重要的概念
迭代計劃 Sprint Plan
Sprint規劃會的核心議題是下一次衝刺要實現的目標和範圍。
- 確定 Sprint 的目標
- 對產品backlog 中 item 進行估算，以作爲是否放入下期的參考。
- 對於需求不清楚的 item，請 Product Owner 說明。
- 輸入是 Product backlog
- 輸出是 Sprint backlog
每日站會 Daily standup meeting
站會的目標是促進信息在團隊內共享與透明。
- 回答3個問題
- 本次會議之前，我做了哪些事情？
- 本次會議之後，我準備做什麼事情？
- 目前我是否碰到障礙，阻礙我達成目標？
- 每天15分鐘
- 不是深入的問題討論
- 每天固定時間召開
評審會議 Sprint Review
Sprint 評審會在衝刺末期召開，檢查本期的成果。
- 團隊全體參與
- 邀請相關干係人蔘與
- 2-4小時
- Product Owner可以拒絕接收成果
迭代回顧 Retrospective
團隊一起復盤本次衝刺的過程，總結經驗與教訓，並形成切實可行的改進清單。
- Sprint評審會結束後召開
- 時間2-4小時
- 團隊全體參與
參考資料
[1] Ken Schwaber、Jeff Sutherland.《Scrum指南》