為什麼Scrum不行,您的團隊是否採用過Scrum模式,效果如何呢?

很久之前酷殼站長陳皓編譯的一篇《為什麼Scrum不行?》再次引發了敏捷社區的一陣騷動。原文出自《Why Scrum will never work》,在那篇文章中,原作者分析了Scrum不適用的幾種情況。當然,作者並沒有對Scrum全盤否認,而是做了負面思考——思考事物的負面因素。因為這樣才能更全面的分析一項事物的優缺點,並知道:它會起作用嗎?缺點是什麼?它有什麼問題?為什麼不能做。Scrum就是一把雙刃劍,如何用、是否合適還是要看具體的情況。那麼,您的團隊是否採用過Scrum模式,效果如何呢?


哇噻,這個話題可大可小啊,我記得當時我們在微博上進行了很久的討論,要不你翻翻我的微博?

- 徐毅-Kaveri的微博

老實說,我實在是懶得再敲字,只能建議你先閱讀一下我寫過的一些文章,再找我進行有針對性的討論吧……至於為什麼推薦我自己寫的么,因為……我懶得去翻別人的文章再把Link發上來……

傳說我的網站需要翻牆才能訪問,不過你可以試試訪問網站地圖 | 徐毅,這個頁面可以一目了然地看到我的所有博客文章,你可以再根據你的需要挑選相應的文章細看。或者可以考慮先看如下幾篇

- 何物謂之敏捷,何物冠之敏捷,何物之為敏捷

- 總結Scrum實施經驗時勿犯歸因錯誤的毛病

- Scrum/Agile Starter Kit

如果不幸訪問不了我的主站,那麼也可以看看我的新浪博客,早一點的文章在這裡都有:

- 徐毅-Kaveri_新浪博客

- 敏捷和Scrum相關的:Agile_Scrum_徐毅-Kaveri_新浪博客

- 何物謂之敏捷,何物冠之敏捷,何物之為敏捷

- 總結Scrum實施經驗時勿犯歸因錯誤的毛病


不是說scrum行不行的問題。scrum本質來講跟瀑布式項目管理沒有本質區別,完全相同,而是在適應範圍上有差距。另外敏捷開發是一種更好的工作方式,讓工程師更主動的思考,與產品經理討論,甚至挽袖子親自上陣。

先講結論,瀑布式適應什麼項目。1. 新項目團隊,大家從未在一起合作過。2. 新型項目或大規模重構等,幾乎從零開始或推倒重來的項目。有節奏的推進,所有人按部就班,通過流程帶來秩序,通過秩序減少項目延期風險。瀑布式工程師偏被動,有項目經理和產品經理在推動,工程師有點像流水線上工人,參與感不強。

scrum類似的敏捷開發適應什麼項目?在沒有外部依賴資源情況下(比如所有設計人員、測試人員或開發人員都不與其他項目共用,否則敏捷的代價就是不斷的和隔壁項目協調人力),在已有的軟體上增加新特性。敏捷開發倡導主動溝通,希望工程師能夠一起思考。

更大型項目,可以在瀑布式管理的框架下,拆解成更小單元的小迭代,用scrum的方法推動。

scrum對產品經理、工程師素質要求非常高。產品經理 能夠提前規劃,工程師能夠主動思考。所以scrum的前提一定是項目成員在瀑布式管理下比較出眾的產品經理和工程師。

引用《英雄》台詞。練劍第一層境界手中有劍,心中有劍。第二層境界手中有劍心中無劍。最高境界手中無劍心中無劍。scrum的理念有點類似,第一層境界大家沒合作過,或者大型新項目通過強化流程,統一步調,形成默契感和配合節奏。第二層境界,已經有了項目基礎,一部分流程可以弱化稍作放鬆,通過大家的溝通就能夠讓項目井井有條的推進。第三層境界,PM腦海中各種項目管理方法形成一套火眼金睛,無招勝有招,只在有需要的時候出現幫助團隊按時完成目標,平時只是在觀察。這也是教練式管理的思想。

回來再講講為什麼scrum和瀑布式是相同的。

傳統瀑布式項目管理:(以互聯網公司為例)

需求收集-&>需求評審-&>迭代需求範圍確定-&>更多細節討論-&>視覺、交互方案確定-&>技術方案確定-&>開發/溝通-&>測試-&>發布-&>總結-&>新迭代

看看scrum在全流程上有什麼區別?把迭代改叫衝刺?減少文檔規模?當面溝通?以上都不是本質。通過幾年對scrum的實踐,我認為的scrum本質是通過當面溝通的方式,增加信息傳遞效率,減少信息覆蓋範圍,使開發團隊更聚焦自己開發需求,防止信息過載帶來的浪費。

下午要出差,先寫到這裡,未完待續


其實不管scrum或者精益,有一點至少是可以肯定的,就是經驗性的實踐、驗證、修正再實踐的過程對現在的軟體開發是有實際作用的。項目管理的方法論絕對不是什麼萬能仙丹,主要還是要看個個組織的實際情況。但是有一點能在過程中學會解決問題能力的組織必定會取得長遠的成功。


多大的項目適合Scrum


表示關注。


大型團隊不適合敏捷,溝通成本太高。


就我們部門實踐的經驗來看是正面有效的!

歷經三年,才走到今天。

第一年,就是站會,讓大家感受到橫向溝通,及時暴露問題和迅速討論解決方案的好處,個人能力很快提升!

第二年,引入sprint, 客戶的深入參與,kanban,大家大概知道概念了!

第三年,三根支柱透明,檢查,調整以及關鍵活動全部用上,計劃總結...很多敏捷的思想轉化為行動和習慣,全面鋪開,大家明顯感覺到團隊戰鬥力提升!

總結一下關鍵是領導和scrum master得很資深,不要急功近利!肯定會有變化!

第四年,將在系分,設計,編碼領域加強專業能力建設,實踐優秀的方法論,這些專業化做法都對敏捷的效果有更大提升!

PS.潘加宇老師的方法論很有用

老外Mike Cohn的博客每周都會分享agile實踐心得

都是好資源,關鍵在實踐!


創業團隊,自己的體會就是,scrum其實只是提供了一種管理的思路,最後的執行效果還是落到人(這是廢話)。總的來說,相比之前整個團隊毫無章法,我們適當的引入了像用戶故事,用戶地圖,產品列表和燃盡圖和早會後,整體效率得到了很大的提高。


推薦閱讀:

哪些互聯網公司設了項目經理?
沒有設的是將項目和產品經理合併了?
有何利弊?
未來的發展趨勢是怎樣?

研發的看板管理如何持續?
在 sprint 迭代當中,由於很多不確定的因素,有什麼可行的 Scrum DeadLine 設定和管理方法?
所謂的敏捷開發是一個坑嗎?
是什麼因素導致敏捷開發在中國的廣泛應用?

TAG:產品經理 | 項目管理 | 敏捷開發 | Scrum | 項目管理工具 |