為什麼Scrum容易學習卻難以精通？

在快速變化的數位環境中，敏捷性的概念變得越來越受歡迎。每個人都在談論Scrum, 敏捷軟體開發，以及各種其他方法，例如極限程式設計（XP）、Scrum、水晶方法、適應式軟體開發（ASD）、特性導向開發（FDD）、動態系統開發方法（DSDM）和輕量級方法。RUP、測試驅動開發（TDD）及其他方法，如下方圖示所示。在所有敏捷開發方法中，Scrum 是最廣泛採用的。

本文主要分享對理解與實施 Scrum 的洞察，以及 Scrum 為團隊帶來的改變。

敏捷傘

什麼是 Scrum？

Scrum 是一種用於開發與維護複雜產品的框架，遵循增量式與迭代式開發流程。在此框架中，整個開發過程由多個短周期的迭代組成，其中一個稱為Sprint，持續時間為 2 到 4 週。

在 Scrum 中，產品待辦事項清單用於管理產品需求。產品待辦事項清單根據商業價值進行優先排序。在 Sprint 期間，Scrum 團隊從產品待辦事項清單中選擇最高優先級的項目，並透過Sprint 規劃流程，建立Sprint 待辦事項清單。在 Sprint 規劃會議中，會討論、分析並估算所選的產品待辦事項（PBIs），以形成下一個 Sprint 所需包含的任務清單（稱為 Sprint 待辦事項清單）。當 Scrum 團隊完成 Sprint 待辦事項清單上的所有選定任務後，當前的 Sprint 結束，並進入下一個 Sprint 的迭代。

敏捷 Scrum 框架

為什麼 Scrum 難以精通？

Scrum 非常有價值。然而，在某些組織中，實施 Scrum 是具有挑戰性的。有些人認為 Scrum 的影響力不大。為什麼這麼多人覺得 Scrum 難以掌握或實施？讓我們重新回顧一下 Scrum 指南對 Scrum 的描述：

• 輕量級
• 容易理解
• 難以精通

由於 Scrum 需要文化上的改變，因此難以實施。如果一個組織從傳統的團隊結構轉向採用 Scrum 進行敏捷開發，則必須為所有 Scrum角色。每個Scrum角色的責任遠比傳統的瀑布式環境更廣泛。為什麼Scrum難以掌握？主要原因如下：

1. Scrum中的角色對所有團隊成員的要求都更高。
   例如，在Scrum專案中，開發人員不僅僅是「撰寫程式碼」——他們必須負責規劃、估算、管理自己的工作，並與其他團隊成員整合，以交付一個一致的解決方案。他們還應直接與業務使用者合作，以理解需求。
2. Scrum是一種需要高度技能與判斷力的適應性流程。
   Scrum基於經驗式過程控制模型，意味著在專案執行期間，解決方案及其產生過程必須根據觀察結果不斷調整。許多技能與判斷決策只能透過在一些指導下的實際操作經驗來學習。許多人試圖機械性地應用Scrum，卻未理解其背後的基本原則，這通常導致失敗。
3. Scrum需要組織的轉型。
   Scrum要求開發團隊與業務使用者在整個專案生命週期中建立合作夥伴關係。這通常需要打破組織的「孤島」，以促進有效合作。

十項敏捷成功的策略

從傳統方法轉向敏捷開發的成功策略，源自於對全球各地積極交付軟體專案的敏捷專案經理與實務人員的訪談，包括：對敏捷專業人士（業務、IT與管理）的訪談，標準組織（PMI、Scrum.org、敏捷聯盟、Scrum.org、DSDM、IEEE等）的訪談，產業案例研究、書籍與研究機構（Gartner、Standish、Forrester等）。

（來源：轉向敏捷：十項成功策略。出自Carilli，JFPMI®全球會議2013年)

1. 確保管理層承諾 – 在啟動任何實施計畫之前，必須確保管理層的承諾。
2. 支援你的團隊 – 敏捷提供高度透明性，並減少對大量檢查點審查的需求。
3. 理解合作文化 – 業務側的代表必須推動敏捷計畫；他們的參與是敏捷方法論的基石。
4. 全面接受敏捷 – 敏捷的真正價值唯有透過完全投入才能充分實現。
5. 制定路線圖與初步計畫 – 敏捷是整體規劃流程的一部分。
6. 聘請敏捷教練並訓練你的團隊 – 至少需有一位具經驗的敏捷教練，Scrum Master，且至少20%的團隊成員具備敏捷經驗，能顯著提高成功的機率。
7. 從小處著手並取得早期成果 – 沒有任何事情能比展現早期且具體的成功更能推動敏捷計畫的動能。
8. 建立敏捷績效指標 – 敏捷專注於解決當前的業務優先事項，而非遵循一組可能已不再反映當前業務方向的基線需求。
9. 建立敏捷合約 – 不應著重於「交付什麼」，而應明確定義並交付「解決方案如何被定義與交付」。
10. 採用ALM工具以增強互動 – 敏捷ALM工具在傳統ALM工具整合的基礎上，整合敏捷流程與治理結構。

根據研究與經驗，建議組織採用這些策略，並配合強健的業務與IT管理實務，以確保從傳統開發方法順利過渡至敏捷。