Scrum一直以來爭論不斷。雖然創始人Ken在演講中曾說過即使是白癡也可以用Scrum，但是依然有很多人認為Scrum對團隊成員的素質要求非常高。另據統計，75%以上的Scrum都可以稱得上失敗。

去年十月，有幸參加了Outsofting鮑央舟老師的Scrum培訓。培訓期間，另一位敏捷教練Julien問我：“你信奉Scrum嗎？”當時我沖口而出的回答是：“我不信奉Scrum，我信奉敏捷。”回想起來，了解Scrum這幾年來，一直對Scrum有一種怪怪的感覺。這難道就是傳說中男人的直覺？呵呵。

1. 我們這樣走向Scrum

1.1 在Scrum之前，我們是這么干的。

任何一個項目都可以劃分為活動，角色和產物。在典型的瀑布模型中，活動分為計劃、需求、設計、實現、測試和發布，當然全生命周期還要增加維護。角色是項目經理，需求分析人員，設計師，代碼人員和測試人員。產物有項目計劃，需求文檔，分析設計文檔，代碼，測試用例和最后的軟件包。

?

1.2 Scrum是這樣的

Scrum也符合這一原則，分為活動，角色和產物。活動分為計劃會議，每日立會，評審會議和回顧會議。角色是ScrumMaster，產品負責人和團隊。產物有產品訂單（Product backlog），沖刺訂單（Sprint backlog）和燃盡圖。

聽說Scrum非常神奇，看看Scrum如此簡單，不如我們開始吧。

?

1.3 然后就郁悶了

Scrum并不像想象中那么美好，只是看起來簡單而已。

迭代中的任務總是不能完成，問題非常多。計劃會議時間太長，感覺效率低下，準備不足，有效信息不足。每日立會是個比較嚴重的負擔，時間超時，讓人窒息。評審會議走過場。回顧會議變成抱怨大會。

QA開始抱怨測試工作壓力非常大，每個迭代只交付部分功能讓QA工作不好安排，效率太低；隨著迭代的增加，回歸測試工作量不斷增加，而引入自動化成本又太高，當前的團隊在自動化方面的技能不足。開發人員需要學習的東西更多，代碼在幾個迭代后快速的腐化，每個迭代都要安排不少時間來重構返工，架構不能支撐業務需求，多次大調整。ScrumMaster僅僅是維護Scrum的流程就很累了。（上面僅是部分問題列舉）

結果并不理想，但是Scrum應該沒有問題，那么問題在哪里呢？苦苦思索，好像有了答案。如果我們有了優秀的人，他們組成了優秀的自組織團隊，使用優秀的工具，采用優秀的實踐，那么Scrum應該能夠發揮它的作用。

?

2. 我不信奉Scrum

2.1 Scrum不是解決方案

不少企業或組織根據Scrum重新定義了角色，活動和產物，然后開始工作，然后碰到了困難。于是他們請來教練進行診斷，一番診斷后，教練給出了診斷結果，你們做的不是真正的Scrum，你們做的是Scrum-but。在那一霎那，心都碎了，我們做的不是真正的Scrum。拿出Scrum的定義看看，我們一個也沒少啊，怎么就不是真正的Scrum了呢？（文學夸張，請見諒，呵呵。）

按照Scrum創始人對Scrum的定義，Scrum不是一種方法學，而只是一種管理框架。Scrum不能解決問題，只能暴露問題。然而為什么大家都認為它就是解決方案呢？

1. 問：為什么大家都認為Scrum是解決方案？

2. 答：因為我們需要解決方案。

3. 問：可Scrum不是解決方案啊。

4. 答：這不重要，因為我們需要解決方案。

5. 問：我們還需要學習敏捷思想、原則和其他實踐。

6. 答：實踐可以有，思想就不必了，因為我們已經有了Scrum解決方案。

上面的問答真有愛。“你想要什么，你便得到了什么。”因為我們需要解決方案，我們就有了解決方案，我們也有了無數的網站和人宣傳和咨詢這個解決方案。

2.2 硬套會死的很難看

Scrum不是解決方案，它甚至不是一種方法學，Scrum可以和其他的方法學一起使用，當然相性不合，死的很難看。

2.3 Scrum配合敏捷

回到敏捷宣言和原則，從以事為中心到以人為本、人事和諧發展，這應該是Scrum可以發揮更大威力的重要方式。（篇幅有限，沒有討論為什么我信奉敏捷。）

?

轉載于:https://www.cnblogs.com/davidzhang33/archive/2011/11/27/2264829.html

總結

以上是生活随笔為你收集整理的我不信奉Scrum，我信奉敏捷的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。