如何評價網路熱文《 Scrum 行還是不行 》？
原文：《Why Scrum will never work》
http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/酷殼：編譯《為什麼Scrum不行？》http://coolshell.cn/articles/5044.html1000copy的評價：《我有不同的看法》
http://1000copy.iteye.com/blog/1131633
以下是我對那篇博文的點評。歡迎大家討論
近來，Maurits的一篇博文"Why Scrum will never work" 一石激起千層浪。著名技術分享網站酷殼（http://coolshell.cn/articles/5044.html）翻譯了這篇文章，我的好朋友，網站創始人陳浩還加入了他的一些想法。
直到我看到在知乎（http://www.zhihu.com/question/19793669）上的一個問題之前，我也認為大多數軟體開發團隊已然知道敏捷是什麼，可以給團隊帶來什麼。他們可能完全不在乎別人怎麼看敏捷。（註：知乎是李開復老師創新工場孵化的類似於Quora的一個中文問答網站）
說一下我對Maurits9個「Scrum永遠不能成功的原因「的解讀：
首先，我個人認為一個產品的成功和是不是使用什麼方法論，工程實踐沒有必然聯繫，尤其是對於小而簡單的產品更是如此。其次，我個人不認為在沒有廣泛應用的軟體工程實踐的支撐下Scrum可以持續不走樣的保持下去。這些工程實踐包括持續集成，自動化測試，簡單設計，代碼審查等等。
我個人理解，敏捷不單單是Scrum和極限編程的集合，而是一個以精益原則為基礎，可以創造目標驅動，自我驅動和學習型的團隊的一整套方法論。這也是我選擇幫助很多產品團隊不斷完善自我作為我職業的原因。
原因1：我完全贊同，的確有些人很難在最開始相信別人。我也曾有過一個團隊中的大多數人希望得到我的幫助，但是個別人非常抵制的經歷。為什麼會這樣呢？因為「信任歧視」！你可以讀我另外一篇博文有對這個話題的分析（http://blog.sina.com.cn/s/blog_626530940100mn3c.html）。但是這並不意味著，這些人永遠不會或者故意不相信別人。如果您已經讀過我的博客，你就知道他們其實相信某些人。這些人是領域專家，朋友，家庭成員或者和他們有共同價值觀的工程師。任何人都不會否定，「團隊中沒有信任」是項目失敗的首要原因之一，是毒藥，也會造成工作效率低下。因此每個人都希望能建立一個互相信任的團隊。我也在努力幫助團隊互相信任。如果你想創造出牛X的產品，不想浪費你寶貴的生命，這就是一個非常有挑戰但不得不做的任務。當你擁有這樣一個團隊，你成功一半了。
原因2：大多數軟體工程師收入不高？在華為，騰訊，創新工場，Google, Facebook, Twitter, Amazon，好的工程師薪水很高。如果你花超過30秒時間，你會列出一個更長的名單。如果你是好的工程師，你甚至可以創業，自己當老闆，Mark
Zuckerberg（Facebook創始人），Larry
Page（Google創始人），Bill Gates（微軟創始人）這些擁有百億身家的人都曾經是工程師。在矽谷成千上萬的工程師創造暴富神話。並且，這些神話還在發生著。的確有工程師的薪水不高。如果他們是有潛力的，他們的薪水可能會上漲。如果他們自認為是好工程師，但是缺錢花，那我猜有可能他們不是好工程師。他們或許擅長架構設計，但是不擅長軟體工程；或許代碼寫得很好，但是交流能力欠缺。成功是需要經驗和技能的積累。你必須無時不刻的學習。並且，每個人，無論他所在什麼行業都會抱怨老闆應該給我更多報酬，近來我只聽說一個人說他收入太高，政府應該多收他的稅。這個人就是著名投資人巴菲特。
原因3：既然Maurits的原因2是悖論，一些團隊需要管理者，一些可以自組織。很多我認識的非常好的管理者不單單是分任務，管理開發人員，對於他們來說更重要的是設定清晰目標，輔導缺乏經驗的隊員。他們的共性是不追求細節管理，但是結果考核，授權給團隊去發揮。
原因4：Scrum不單單是一個流程，如果你讀過這本書，並且在3個以上的項目中實踐過Scrum的話，你一定會理解，Scrum可以幫助團隊快速學習，快速成長，早犯錯誤，早改進，早失敗，早總結。相對於聰明人來講，有經驗的人可以創造出更好的團隊。我不太理解Maurits所說的」Good people」，我猜可能是和善，並且有經驗的人吧。
原因5：項目或產品大致上分成兩種，一種是定製開發，一種是面向大眾的產品。大多數面向大眾的產品，例如SNS，搜索引擎，電子商務，在線遊戲都會有產品經理負責。他們非常關注用戶反饋，他們把自己的產品當做自己的baby一樣看待。大多數情況下，定製開發軟體的決策者往往是客戶方的業務經理，他們未必那麼關心產品。我個人經驗中，那些非常關注產品的業務經理往往得到更早的晉陞。原因6：我曾經在TED上看過一個演講，演講嘉賓是Dan
Pink（http://www.ted.com/talks/dan_pink_on_motivation.html），他研究一個「如何激勵知識工作者」的題目。其結論是：知識工作者通常情況下有意願提高自己，因為他們希望成為更有經驗的人，學習更多知識，變得更資深。相對於在某個領域成為專家的追求，他們對收入的訴求相對會小一點。這是一個和其他領域非常不同的群體。知識工作者是一個極為特殊的生產力。
原因7：產品經理專註與「做什麼」和「為什麼做」。開發團隊專註於「如何做」，但是他們同樣需要知道「做什麼」和「為什麼做」。Maurits的觀點是對敏捷原則和方法論的一種片面的理解。我正在參與的一個敏捷組織轉型項目中，我所作的第一件事情就是和項目核心成員共同確定項目目標，策略等，之後給團隊所有成員解釋。這是創建一個目標驅動團隊的第一步也是必要一步。
「交付期限」是必須有的，它可以幫助業務部門和開發團隊巧妙的找到投資回報的平衡點。中國人的文化就是這種「中庸」文化。 產品質量也是「功能」，為什麼呢？如果某個功能有bug，這意味該功能不能使用，換句話說就是這個功能的開發沒有完成。因此維護產品的質量等同於「挽救」功能。原因8：幸運的是，大多數我曾工作過的項目「極其」在乎產品質量。為什麼呢？其原因不是這些「平均水平」的工程師只朝九晚五的工作，而是因為他們並不想痛苦的加班加點的修bug。作為「知識工作者」他們希望自己更專業，更牛X，不想丟臉。
原因9：對於這條原因，我倒是不得不贊同。對於政府項目和固定預算固定範圍的項目，敏捷不是一個合適的方法。當我在英國做一家IT公司的運營總監（COO）的時候，我說服了我的客戶從這種固定時間固定範圍的方法轉換成按人天付費的方法。最大的區別是什麼？這種新的方式給予我的客戶更大的自由去爭取更多的投資回報。他們在乎么？當然在乎！在英國，大多數的政府項目使用Prince
II來管理，在中國瀑布模式還是主流。如果你不想你上繳的稅收浪費掉，盡你最大的努力說服你的客戶轉向敏捷方式吧。
最後說幾句，我真的不在乎一個項目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎。我真正在乎的是「組建牛X團隊」，「實現商業目標」，「創造出高品質產品」，「讓客戶滿意」，「增強客戶盈利能力」。恰好，包括敏捷在內的一些有效的方法論幫助我去實現了以上的目標。我更希望看到我們的用戶在使用我們產品，玩我們的遊戲的時候得到真正的開心和便捷。
摘自：http://blog.aaladdin.com
你想讓它行，就一定能行，因為一定會有辦法讓它行。你不想讓它行，它就不行，因為一定有辦法讓它不行。
沒有哪一種方法是銀彈，Scrum作為敏捷方法中偏重於管理的一種實踐，我覺得很不錯，就看如何去體會和應用了。敏捷本身就不是百米賽跑，也許是個400米接力賽，馬拉松也有可能。要想獲得效果，人員、技術、過程，缺一不可。
這篇文章是在說反話。
敏捷開發=先刷卡消費，在免息期還款(重構)。如果只對付最低還款額(重構不徹底)，需支付循環利息(技術債)。如果次次如此，最終資不抵債(架構腐爛)。如果直接無視賬單，珍惜生命，遠離信用卡。
所以行不行更重要的在於團隊自身的還款能力，而非方法本身。如果把軟體看成人的因素更重要，那麼軟體開發實際上還是一種藝術；如果把軟體看成是標準的流程，那麼軟體開發和流水線沒啥兩樣，各種方法論、質量論就都是有效的。
現階段我仍然覺得藝術的成分居多，也就是靠人的創造力居多，所以各種方法論基本上是靠不住的。不管什麼管理方法，核心都是人。認為一種管理方法可以包打天下的，都沒有重視人的多樣性和一定程度上的不可塑性。
敏捷開發適合50到100人的團隊，50人以下時設置專職的管理職位都是比較浪費的。而且scrum很多實踐方式是反直覺的，需要培養習慣，和在較長時間內持續投入，所以會出現很多跟風但無法堅持到出成效的團隊。總得來說成本高（培訓師，sm，pm），見效慢（團隊需要數個周期的練習才能更準確的估計時間和閱讀燃盡圖）。但在資源寬裕，政策執行力強，團隊人數較多的大公司，不失為一種系統有效的方式。
未來軟體工程的管理方式會進一步分化，個人認為github的流行帶來的以非同步溝通和上下文代碼為核心的工作流程會最終在小而美的團隊中佔據統治地位。
另外就是管理方式將和招聘風格有著更深入的綁定關係（也就是做不到像valve一樣招人的公司就沒辦法像它一樣管理）。最後遠程協作的地位會繼續提高，沒人喜歡每天定時開會。
剛才不是在說大公司還是會很依賴嚴格的管理方式么？在未來大公司很難和一幫相互合作建立完整業務鏈的小公司競爭，所以純管理型的職位好日子沒有幾年了。這篇文章看似胡攪蠻纏，但是有些理由的確是建立在陰暗的現實世界的基礎上的，比如Reason5和Reason7，對於我們這樣的外包公司，當需求無法從最終客戶手裡獲得的時候，其他再牛逼的方法論都是擺設，毫無意義。
Scrum之所以讓人覺得不行還有一個重要的原因就是：推廣Scrum的人和書籍大多隻介紹成功經驗，卻很少客觀的指出哪些情況不適合甚至絕對不要使用Scrum，除非是一些財大氣粗的大公司和內部項目，否則沒有幾個項目組有條件一再進行失敗的嘗試的，失敗了以後，大多數人都會把罪責推到新的開發方法上，其實並不是Scrum不行，而是Scrum本來就不適用。正在做一個Scrum項目，對於做政府項目的團隊來說，Scrum最大的好處是在一個可控的時間段內，明確了可控的目標，面對需求隨心而變的政府客戶，有了一個很好的拒絕變更的理由。同時，快速的迭代，也保證了隨時看到效果，隨時修正，很能應對變更，這些都能很好的保護團隊，維持團隊成員的積極性。那句話說的很對「真的不在乎一個項目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎」，老闆，客戶都不會在乎這個～
性本善還是性本惡？這篇文章的出發點完全是基於麥格雷戈的X-Y理論的X理論而寫的。能為現在熱得不行的敏捷降降溫，本身我覺得是好的。可是以偏概全就缺乏說服力了。現實中，敏捷到底行不行很大程度上與組織和團隊的成熟度有很大的關係。只有在一個良好激勵的成熟團隊中，才有施展的空間。我想不光是敏捷，團隊才是一切的基礎。而Scrum無非是一種方法論罷了。
Scrum:事半功倍的藝術
Random商業書屋出版，2015年
作者Jeff Sutherland，是Scrum的創立者，同時也是《敏捷宣言》的簽署者之一。《敏捷宣言》標誌敏捷運動的發端。Jeff畢業於西點軍校，最初是美國空軍的一名戰鬥飛行員，之後進入科羅拉多醫科大學學習並任教。博士畢業後，在11個軟體公司任項目副總或CTO，在最後7個公司全部使用Scrum進行管理，取得了行業領先的累累碩果。目前任Scrum公司CEO，Scrum協會主席，開放觀點投資合作公司的高級顧問(基金公司敏捷教練)。前言第1章 世界運行的方式碎了第2章 Scrum起源第3章 團隊第4章 時間第5章 浪費就是犯罪第6章 計劃的是現實，不是幻想第7章 幸福
第8章 優先第9章 改變世界附錄 實施Scrum——怎樣開始前言為什麼是Scrum？20年前，我和Ken Schwaber最早創立Scrum。我們給Scrum的定位是，高科技行業的軟體開發模式。它更快、更可靠、更有效。當時，或者說最晚到2005年，大多數的軟體開發項目都採用瀑布流模式進行管理。在這種模式中，項目分階段進行，最終交付給消費者或用戶。過程很慢，無法預測。最終結果經常是做出來的東西不是用戶想要的，或者明顯超出用戶的預算。延誤數月甚至數年是家常便飯。項目初期以甘特圖形式給出各階段計劃，細節令人賞心悅目。呈現在管理層面前的是，「我們的開發過程完全受控」，幾乎沒有失敗。但實際效果卻總是大大延誤，完成整個任務的費用就像一場災難。為了克服這些問題，1993年，我發明了一種新的做事模式，Scrum。它對過去那種預期式的、自頂向下的項目管理方式是一個極大的改變。Scrum是一種演變式的、自適應的、自糾正的系統。從一開始，Scrum框架就成為IT業的軟體/產品開發模式。在矽谷，Scrum在軟硬體開發管理方面的成功早已聲名鵲起。但在一般的商業實踐中，它仍然鮮為人知。因此，我決定寫這本書，向IT業以外的行業揭示並解釋Scrum管理系統。在這本書里，我給出了Scrum在豐田生產系統中的起源，以及空戰中的OODA迴環。對如何利用小團隊組織項目做了討論，還討論了為什麼Scrum是一種行之有效的高效方式。怎麼排優先順序、怎麼建立周/月時間回合(獲得衝勁)、怎麼使團隊中的每一個人都負起責任、怎麼做簡短的每日站會(做了什麼，完成的挑戰有哪些)。怎麼把持續改進和最小變數產品的概念納入Scrum，從而馬上得到用戶反饋，而不是等到項目全部完成才去獲取用戶反饋。之後你還將看到，我們用Scrum做一切事情。從一加侖油跑100英里的經濟型轎車，到把FBI數據系統帶到21世紀。讀吧。我覺得你將會明白，怎麼用Scrum來讓你的公司運營、創新、規劃以及思考做出改變。我堅信，Scrum有助於實現各個領域商業運作的革命。在矽谷，在科技業，新公司燦若星河，新產品如火如荼令人心動神搖，這一切都離不開Scrum在創新和加速上市方面掀起的革命。而這兩個革命則並無不同。
Jeff Sutherland博士其實這篇文章的主題在於指出「若干能對敏捷實施產生極大威脅的條件」。
看了下原文，在回答之前想限定下我們到底在討論些什麼？原文如果說scrum不好，卻又沒有提出更好的方法，我們公司有個文化就是非常鄙視只會提問題的人，老闆的原話是剛畢業的學生都能發現很多問題，能解決問題才是高手。
現在回歸正題，關於scrum，有研究指出它在需求變動比較劇烈的項目中更能發揮作用，但是在需求非常明確，不太變化的場景要輸過傳統的管理模型。原因在於後者可以做更好的預測，規劃，設計，找出關鍵路徑，資源分配等。
scrum我自己的感覺是比較適合帶新人，人的能力成長離不開隨時的點評，反饋和指導。設計，優先順序，時間評估如何越做越好？昨天做的東西有沒有問題？有這樣一個站立會議來給管理者快速發現，指正。
軟體管理也是門藝術，要反對任何形而上。行還是不行要看適不適合自己的團隊了，方法和流程沒有絕對的，適合自己的就是最好的
就軟體開發的生命周期而言，方法論和過程是必須的，不然怎麼能夠提高生產力，怎麼控制質量？
能讓客戶滿意，用什麼方法進行項目管理都是可以的
瀏覽了幾乎所有網上關於這篇文章的評論，感覺很有趣的一點：這篇調侃甚至說反話的文章，讓很多人非常認同。一些評論比如「Scrum就是形式主義」、」只有初創公司才適合敏捷「等看法可以在任何打算做點改變的公司中聽到。
因為接觸了很多實際的敏捷轉型項目，我看到過很多成功的Scrum團隊，也看到了很多（或者說更多）失敗的Scrum團隊。在後者的團隊里，我非常理解他們對Scrum的怨言。因為在走形的Scrum團隊中，成員之間的信任土崩瓦解，共同目標也被徹底忘記，流程變成了枷鎖。PO苦逼著臉說：「Scrum這不扯淡么，成天開會，還不給我好好乾活？」 ScrumMaster苦逼著臉說：「這工作沒法做，PO天天改需求，Manager天天過來指導工作。應付他們就夠喝一壺了，扯啥自組織啊？」
說說文章里提到的一些典型想法：誰和你扯信任啊？誰需要這麼多自由啊？持續進步這事和我有半毛錢關係么？ 質量做好了加薪嗎？這幾點都是基於人性本惡的前提。這種人有嗎？有，太有了，哪家公司都有，但是如果哪家公司都是這種人，估計也快不行了。據我看到的情況，大多數軟體開發者都是有著或多或少的自我提高的動力的。動力的來源不一，有的高大上的是為了開自己的公司，有的就是單純地想成為技術大牛，有的目標明確就是要跳個更好的公司，有的嘛，為了還房貸能輕鬆點。這樣的人在一起，其實只要搭配得好，管理者不亂出幺蛾子，無所謂用不用Scrum，成功都是水到渠成的事情。失敗的項目有著各種各樣的理由，當然，拿Scrum來說事是個很好的借口。推薦閱讀：