Scrum的創始人之一Ken Schwaber受《哈佛商業評論》論文影響，從1990年代開始實踐新方法，在1993年拯救了一個瀕臨失敗的專案。 創新的過程控制 Ken在1994年建立的「控制混亂」網站中，就指出不確定性管理的必要性，他認為自己與另一位創始人Jeff Sutherland對Scrum的研究總結背後蘊含著第一性原理：「複雜性過程需要試驗性的過程控制」。在那個年代，研發型的組織一定都是走在創新之路上的，現在很多研發組織實際走向了富士康模式，但是卻無法管理好。這背後的原因是技術與管理的進步使一些東西變得確定了，然後卻有更多新的不確定因素湧現出來，「控制混亂」前路漫長。 1995年，Jeff Sutherland應邀將《哈佛商業評論》的文章轉發給正在創立極限編程的Kent Beck。Jeff曾是越戰中美軍的戰鬥飛行員，對變化無常的戰場複雜形勢有著切身的體會，要想生存就必須要建立響應變化的能力，沒人能夠走直線的。除了那篇論文，他們還借鑒了精益思想、Timebox概念、SmallTalk社區的面向對象設計思想……等理論基礎，並於1995年正式在OOPSLA發布了Scrum研發過程論文，期間也受到Mike Beedle的幫助，正式提出了Scrum研發框架。根據Jeff的說法，Scrum在創立之初就受到高德拉特的約束理論和精益思想的影響，關注於「Muri, Mura, Muda」。 Muri：避免給予人員和組織不必要的壓力，現在也稱為「可持續發展」。 Mura：消除跳變和不一致，進行整流，有助於達到超生產力(Hyperproductive)。最初幾個Sprint主要是消除流動中的干擾，從而使後續的Sprint更加順暢。 Muda：激進地消除活動中的7大浪費，持續改善。 直到2001年，在美國Snowbird和大家一起形成敏捷宣言，連同《Agile Software Development with Scrum》一書（中譯本《Scrum敏捷專案管理》譯者李國彪）和現代IDE的出現，Scrum逐漸流傳開來。 早年在探索Scrum實踐中，Jeff說類似極限編程的實踐也用了很多，但是後來為了從管理角度將敏捷更好地推廣，於是從Scrum中去掉了技術實踐的部分，泛化為一種工作方法，Scrum更多是一種管理實踐。Ken注意到對於軟體開發而言，技術能力實踐對Scrum落地必不可少，於是借鑑XP極限編程提出了Scrum Developer訓練內容。 Scrum框架的意圖 為什麼要採用Scrum？因為商業組織往往面臨這些痛點： 1. 產品做出來沒人用，忙得像狗卻沒有成就感 2. 計畫趕不上變化，需求變更太快太多，無法聚焦完成一件事 3. 業務與研發總是在拉扯，用戶總是在投訴 4. 時間緊、任務重，每件事情都是高優先狀態，總是在救火之中，做不 完又焦慮 5. 所有壓力和風險都在後期集中爆發，越忙越添亂 6. 技術和架構跟不上時代，知識缺口越來越大，逐漸與社會主流脫節 7. 好的習慣和流程堅持不下來，形同虛設 8. 招不到優秀人才來幫忙，還不斷流失，團隊一盤散沙 9. 個人工作與生活失衡，從加班到辭職 Scrum框架的定義 Scrum基於試驗性過程控制理論(Empirical Process)，或稱之為經驗主義，是自然科學研究方法的基礎。經驗主義主張知識源自實際經驗，以及觀察當前已知情況下做出決定所獲得。（注意區別於教條主義和理性主義，以及完全基於過去經驗進行判斷的過去經驗主義或固定思維，或者忽視理論指導的局部經驗主義）。「透明、檢視和適應」是試驗性過程控制的三大支柱，支撐起每一個試驗性過程控制的實施。Scrum採用一種迭代、增量式的方法來優化對未來的預測和管理風險，建立組織響應變化的敏捷能力，從而達致更好的效果。Scrum借鑑了精益思想、時間盒、模組化設計……等，並完整地體現了敏捷宣言和敏捷原則。 Scrum是一種通過「檢視－調整」來開發和維護複雜產品的框架，是遵循敏捷宣言和原則的一種流派，整合了3個角色、3個工件、5個事件、5個價值觀，簡稱「3355」。在這個框架中，整個開發過程由若干個短的迭代週期組成，稱為Sprint。 每個Sprint的建議長度是1～4週。使用產品Backlog來管理產品的需求，它是一個按照價值排序的需求列表。每個迭代中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行工作。挑選出的需求在Sprint計畫活動上經過討論、分析和估算得到相應的迭代目標和交付計畫，我們稱它為Sprint Backlog。 迭代中每天會有一個站立式的Daily Scrum。在每個迭代結束時，Scrum團隊將邀請業務和利益關係人確認開發團隊的產出。隨後，團隊進行回顧，不斷改進工作方式。Scrum不僅適用於軟體開發專案，也可用於任何複雜的或是創新性的項目和探索，以及組織變革設計。