第一部分：1 - 來源

Scrum是一個可以用來開發複雜產品的管理框架。Scrum來源於知識管理，複雜適應系統和經驗主義的流程控制理論。公認起源於一份Nonaka和Takeuchi於1986年發佈的研究報告：The New，New Product Development Game。Scrum也從Lean借鑑許多知識。

Scrum是目前全部敏捷方法當中最流行的。在2013年，72%的宣稱本身實施敏捷的團隊或單獨使用Scrum，或將Scrum與其它方法結合使用。更多有關敏捷和其它方法的信息參考「更多關於敏捷和Lean」。

 

現有方法存在的問題

l  發佈時間過長

l  穩定須要很長時間

l  變動很難實施

l  質量降低

l  時間點要求讓人很難受

長期以來，軟件開發人員都在嘗試使用定義化的方法開發和管理項目。定義化的方法適用於用戶需求以及交付成果很是明確的場合。軟件開發或其它複雜的工做不適合使用這樣的定義化方法。而高比例的項目失敗以及客戶的不滿意也正好證實了這一點。

 

Scrum如何解決問題

Alistair Cockburn將軟件開發定義爲「創新和溝通的合做遊戲」。

傳統的開發理論依賴於文檔的記錄以及將知識從一個專業人員傳遞到另外一個專業人員。反饋時間太長甚至不存在反饋。大量未達到績效的項目也顯示這樣的工做方法失敗透頂。

2012年8月，Gartner發佈一篇名爲「咱們熟知的瀑布模式的終結」的文章。它闡述了持續時間過長的瀑布模式是軟件發佈的最高的風險所在。

Scrum提供了一個有效協同工做和可視化的風險預測平臺。

我發現許多首席級別的經理（C-Level）都明白下面這個傳統項目管理模式和敏捷模式之間的對比。

在傳統的預測型模式中，項目經理嘗試經過約束項目範圍來提供可信的項目預算及項目日程。在實踐中，咱們會碰到「三角約束」【即範圍，成本和時間】，而質量每每被忽視。而在敏捷當中，時間和成本被認爲是約束條件。產品經理與項目團隊合做來迭代和持續交付最大價值的產品。計劃與現實符合。

我發現高級別的利益相關者很是樂於見到項目可以達到時間和成本要求，至少時間和成本能被控制住。固然，項目範圍做爲變量確實很是讓人感到擔憂。個人作法是尋求以及確認明確的項目約束。