繁體中文在當前的 IT 行業，敏捷的概念已經相當流行。每個人都在談論。幾乎所有的 IT 公司都採用了某種程度的敏捷。
在敏捷開發的範疇內還有很多方法，包括極限編程（XP）、Scrum、水晶方法、自適應軟件開發（ASD）、特徵驅動開發（FDD）、動態系統開發（DSDM）和輕量級。RUP、測試驅動開發 (TDD) 等。在眾多敏捷開發方法中，Scrum 的實現更為流行。
敏捷還是瀑布？見數字
Standish Group 的最新報告涵蓋了他們在 2013 年至 2017 年間研究的項目。在此期間，敏捷和瀑布式的成功、挑戰和失敗的總體突破如下所示，敏捷項目成功的可能性大約高出 2 倍，失敗的可能性降低 1/3。
（來源：viabilitychicago.com — 比較瀑布和敏捷項目的成功率）
本文主要分享對 Scrum 的理解、Scrum 的實現過程以及 Scrum 的實現帶來的變化，並說明什麼是運行中的 Scrum。
什麼是 Scrum？
Scrum 是一個用於開發和維護複雜產品的框架，是一個增量、迭代的開發過程。在這個框架中，整個開發過程由幾個短的迭代周期組成，一個短的迭代周期稱為一個 Sprint，每個 Sprint 為 2 到 4 週。
在 Scrum 中，使用產品 Backlog 來管理產品的需求。產品積壓按照執行的優先級排序，以商業價值為主要排序原則。在 Sprint 中，Scrum 團隊從產品 Backlog 中選擇最高優先級的需求進行開發。在 Sprint 計劃會議上討論、分析和估計選定的需求，以獲得稱為 Sprint 待辦事項的任務列表。當 Scrum 團隊完成 Sprint backlog 列表中的所有任務時，Sprint 結束並進入下一個 Sprint 迭代周期。
為什麼 Scrum 在一些公司失敗了
Scrum 具有很大的價值。但是，在一些公司中實施 Scrum 很困難。有人說 Scrum 在他們的組織中沒有實質性的影響。他們為什麼會有這樣的結果？主要原因可能是：
- 敏捷更快 ——項目團隊對敏捷缺乏正確的理解。它簡單地認為敏捷是快速的，即追趕進度，可以不受任何系統的限制。
- 敏捷更快，或者我們需要加班 ——我聽說有些公司必須開發一個新功能。由於scrum的實施，項目組需要加班，2週以上的開發任務會在1週內發布。實施 Scrum 意味著項目團隊加班加點，導致項目團隊的敏捷性產生“恐懼”；
- Product Backlog維護不好——PO 無法勝任工作，無法拆分有效的用戶故事，或者用戶故事拆分不合理，無法實現增量生成開發；
- 團隊組建問題 ——Scrum對自組織團隊的要求很高，但很多團隊成員覺得自己達不到自組織的標準；
- 缺乏敏捷文化 ——Scrum 提倡工作的透明化、項目的實時完成和每個人的任務識別。衝刺板和項目燃盡圖一目了然，很多人不習慣；
- 檢查和適應不到位 ——在迭代過程中，不能及時發現問題，或者發現問題，不能有效解決問題，讓項目組感到沮喪。還有很多。
如果 Scrum 的知識只停留在：
“早上有個想法，下午實現，晚上上線。”
這是不合適的。在我看來，Scrum 絕對是有價值的。Scrum 的主要功能包括：
- Scrum 可以確保優先開發對客戶有價值的產品 backlog，更好地滿足用戶的需求。
- 與瀑布流程下的開發方式相比，通過實施Scrum，團隊可以使開發效率翻倍，最大限度地發揮團隊的作用；
- Scrum 可以縮短開發週期，提高項目交付效率。
但是，實施 Scrum 並不意味著它不受規則和項目約束。那麼實施 Scrum 的正確姿勢是什麼？
實施 Scrum 的步驟
1. 分配採購訂單
PO是Product owner，是一個角色，PO是管理產品to-do list的唯一所有者。當然，在一些公司中，PO已經作為一個組織存在——比如我們公司在Scrum的實施中已經將PO作為一個組織實現了。
作為業主，一定要有大局；深入了解行業信息和方向；能夠把握產品的方向，負責產品的短期和中長期規劃和管理；能夠根據公司戰略要求進行用戶調研和產品功能規劃，跟踪不斷變化的需求，不斷創新產品。
此外，如果您將 PO 用作組織，在軟件開發項目中，PO 團隊可能包括其他利益相關者，例如產品經理、最終用戶等成員。
2.組建開發團隊
團隊是產品的實施者，負責在每個 Sprint 結束時交付潛在的可交付增量和“已完成”的產品增量。
團隊主要包括開發和測試人員，團隊必須能夠實現PO對產品的願景。
團隊的規模應該在 5 到 9 人左右。
Scrum 團隊也應該是跨職能的，具有“全棧”能力的成員更可取，即使 在大多數公司可能難以實施。
3. 選擇 Scrum Master
Scrum Master 負責 Scrum 流程並為 PO 和開發團隊服務。Scrum Master要有儀式感，能有效高效地組織迭代計劃會議、日常常設會議、功能演示會議、回顧會議；Scrum Master 必須具有高度的執行力並保持可信度以幫助團隊。專注於交付目標和質量目標，確保團隊高效交付高質量產品；推動團隊建立高效的流程，指導團隊敏捷價值觀、原則和敏捷實踐；負責培訓團隊其他成員，確保正確使用 Scrum；溝通、問題管理、衝突解決，幫助團隊消除一切障礙。
4.維護產品Backlog
Product Backlog 是所有 backlog 項目的集合，基於公司的戰略和產品願景。PO將產品積壓中的所有項目按照業務價值按照優先級排序，形成優先項目列表。產品積壓可以作為產品開發的“路線圖”。 要了解產品上下文，產品待辦事項是最好的參考。
我們每天都面臨來自新競爭對手的新需求，這意味著 PO 必須不斷優化其產品設計並調整產品積壓的優先級以應對新的變化。
在此過程中，PO 應諮詢所有利益相關者和團隊，以確保產品積壓反映用戶的真實主張。
5. 使用故事點的敏捷估計
相對敏捷的估計通常在 sprint 計劃中執行或在 sprint 期間進行修改，並且產品積壓由團隊與負責實際開發和測試工作的人員一起評估。
為了在實踐中更高效地進行 sprint 計劃，PO 和 Scrum Master 會在 sprint 計劃會議之前進行粗略的估算。他們需要問這些問題，例如：
- 看看sprint計劃是否可行？
- 是否有足夠的信息來完成這些事情？
- 產品積壓項目拆分是否合理？
開發團隊進行估算時，建議摒棄傳統方法（即分配多少小時任務），採用敏捷估算方法，利用故事點——斐波那契數（1、2、3、5） , 8, 13, 21…) 用於評估實施項目所需努力的表格。
在估算時，團隊需要首先確定一個可能是用戶故事形式的待辦事項，作為估算的參考。另外需要注意的是， 當評估的單個故事點大於21時，需要再次拆分用戶故事，單個用戶故事點不超過8是理想狀態。
6. Sprint 計劃會議
這是第一次真正的 Scrum 會議。團隊、Scrum Master 和 PO 坐在一起計劃 sprint 的內容。 作為一個軟件開發項目，進入規劃衝刺的用戶故事，應該已經拆分了用戶故事，完成了視覺設計。
sprint 週期一般是固定的，多為 2 到 4 週。團隊從產品待辦事項列表中優先級最高的用戶故事開始，看看在一個 sprint 中可以完成多少工作。
如果團隊已經進行了多次沖刺，請參考：
- 在之前的迭代中完成的“故事點”，
- 團隊可能會估計此迭代的大致故事點。
- “故事點”相當於團隊的速度。
Scrum Master 和團隊應該努力在每個 sprint 迭代中增加這個數字。
所有團隊成員都應該就 sprint 的目標形成共識，即在 sprint 迭代中需要完成什麼。在 sprint 計劃會議上，PO 需要告訴團隊用戶故事實施的優先順序。團隊承諾他們將能夠在下一個 sprint 迭代中完成多少個故事。在衝刺過程中，任何人都不能擅自單方面更改衝刺內容。
7. 每日站立會議
每日站會是 Scrum 活力的源泉。參與者一般包括 PO、Scrum Master 和團隊。團隊每天在固定地點和固定時間進行內部溝通。時間一般 是早上，時間不超過15分鐘，站著。Scrum Master 向團隊 成員提出以下問題：
- 你昨天做了什麼？
- 你今天打算做什麼工作？
- 什麼是障礙和障礙？
這樣做的意義在於讓整個團隊清楚地知道在這個 sprint 週期內每個任務的進度，以及所有的任務是否能夠按時完成。
團隊的任務不是自上而下分配的，而是由他們主動和自願決定的。如果上一個任務沒有完成，就不能申請下一個任務，也不能申領兩個不能在同一天完成的任務。
Scrum Master 負責消除團隊成員面臨的障礙。
8. 使用 Scrum 任務板跟踪項目進度
在 Scrum 中，工作必須是透明的，最常見的做法是實現一個 Scrum 任務板。
有些團隊擅長使用第三方工具來使用電子 Scrum 板，例如 Visual Paradigm 或 Jira；一些團隊樂於使用大型離線物理白板。
無論您使用電子 Scrum 板還是物理白板，看板的列通常包括三個部分：待辦事項列表、正在進行的項目和已完成的項目。隨著迭代進度的推進，團隊每天都會及時將此事更新到對應的Scrum看板欄目。
9. 使用燃盡圖跟踪進度
另一個使工作透明的工具是倦怠圖。在下圖中，一個軸代表工作量，另一個代表時間。Scrum Master 每天都會記錄下要完成的剩餘點數，然後將它們繪製在倦怠圖上。理想情況下，該圖是一條向下的曲線，隨著其餘工作的完成而燒毀為零。
10. 產品展示
Scrum 指南的演示部分稱為 Sprint 評審會議，它指出它應該包括演示開發團隊完成的工作並回答有關產品增量的問題。會議通常在本次迭代發布之前舉行。 本次會議最重要的工作是驗證用戶故事的實施場景，並接受對每個已完成項目的評估，以實現完成的定義。
這個會議是任何人都可以參加的地方，不僅是 PO、Scrum Master 和團隊，還有利益相關者、業務和經理，甚至是客戶。
這是一個公開會議，任何人都可以成為參與者，不僅是 PO、Scrum Master 和團隊，還包括利益相關者、業務和經理，甚至是客戶。
團隊應該只展示那些滿足完成定義的項目，即無需做更多工作就可以交付的結果。這個結果可能不是一個完整的產品，但至少它對最終用戶來說是一個完整且可用的功能。
11. Sprint 回顧展
sprint 回顧會議通常在本次 Sprint 結束後的第二天舉行。
衝刺回顧會議應仔細審查以下問題：
- 發生了哪些改進；
- 為什麼會這樣？
- 為什麼當時我們忽略了它；
- 我們怎樣才能加快工作。
作為一個團隊，為了使這個 sprint 回顧過程有效，團隊需要相互信任。我們必須記住基於項目和技術問題的討論和爭論：
- 沒有絕對的對、錯和擔心，
- 鼓勵技術碰撞；
- 不能涉及人身攻擊的討論；
- 抵制戴有色眼鏡看人，
- 引導大家理性討論；
- 勇敢地接受別人的挑戰，
- 接受自己的不完美。
- 對自己的過程和結果負責，
- 集思廣益並尋求問題的解決方案。這是至關重要的。
最後，團隊確定了最有價值的改進之一，並將其設置為下一個 sprint 的首要任務。您需要以具體且可操作的方式定義什麼是“成功的”，以便您可以快速確定在下一次 sprint 審查會議上是否已做出改進。
最後一個sprint結束後，開始進入新的sprint迭代。
概括
Scrum 是3355的組合，scrum框架的核心概念可以簡單的記為3.3.5.5如下：
3個角色
3 神器
- 產品積壓
- Sprint Backlog ——Sprint 待辦事項列表
- 產品增量——潛在的可交付產品增量
5 個事件
5 個值
- 打開
- 尊重
- 勇氣
- 重點
- 承諾
3355 的目標落後於三個 Scrum 支柱
- 透明的
- 檢查
- 適應
“完成”（DoD）的定義是通過 Scrum 團隊的 5 個事件實現 3 個支柱來實現的。
繁體中文
English
简体中文
Deutsch
Español
Français
العربية
Italiano
Português
日本語
Nederlands
Русский