分類: 為什么 常識詞典 編輯 : 常識 發(fā)布 : 04-24

閱讀 :331

如何評價網(wǎng)絡熱文《 Scrum 行還是不行 》？原文：《W-y Scrum will never work》-urits.wordpress/2011...酷殼：編譯《為什么Scrum不行？》cools-ell.cn/articles...1000copy的評價：《我有不同的看法》1000copy.iteye/blog...9 個答案

答案 1：

以下是我對那篇博文的點評。歡迎大家討論 近來，Maurits的一篇博文"W-y Scrum will never work" 一石激起千層浪。著名技術分享網(wǎng)站酷殼（cools-ell.cn/articles...）翻譯了這篇文章，我的好朋友，網(wǎng)站創(chuàng)始人陳浩還加入了他的一些想法。 直到我看到在知乎（z-i-u/question...）上的一個問題之前，我也認為大多數(shù)軟件開發(fā)團隊已然知道敏捷是什么，可以給團隊帶來什么。他們可能完全不在乎別人怎么看敏捷。（注：知乎是李開復老師創(chuàng)新工場孵化的類似于Quora的一個中文問答網(wǎng)站） 說一下我對Maurits9個“Scrum永遠不能成功的原因“的解讀： 首先，我個人認為一個產品的成功和是不是使用什么方-，工程實踐沒有必然聯(lián)系，尤其是對于小而簡單的產品更是如此。其次，我個人不認為在沒有廣泛應用的軟件工程實踐的支撐下Scrum可以持續(xù)不走樣的保持下去。這些工程實踐包括持續(xù)集成，自動化測試，簡單設計，代碼審查等等。 我個人理解，敏捷不單單是Scrum和極限編程的集合，而是一個以精益原則為基礎，可以創(chuàng)造目標驅動，自我驅動和學習型的團隊的一整套方-。這也是我選擇幫助很多產品團隊不斷完善自我作為我職業(yè)的原因。 原因1：我完全贊同，的確有些人很難在最開始相信別人。我也曾有過一個團隊中的大多數(shù)人希望得到我的幫助，但是個別人非常抵制的經(jīng)歷。為什么會這樣呢？因為“信任歧視”！你可以讀我另外一篇博文有對這個話題的分析（blog.sina.cn/s/blog_6...）。但是這并不意味著，這些人永遠不會或者故意不相信別人。如果您已經(jīng)讀過我的博客，你就知道他們其實相信某些人。這些人是領域專家，朋友，家庭成員或者和他們有共同價值觀的工程師。任何人都不會否定，“團隊中沒有信任”是項目失敗的首要原因之一，是毒藥，也會造成工作效率低下。因此每個人都希望能建立一個互相信任的團隊。我也在努力幫助團隊互相信任。如果你想創(chuàng)造出牛X的產品，不想浪費你寶貴的生命，這就是一個非常有挑戰(zhàn)但不得不做的任務。當你擁有這樣一個團隊，你成功一半了。 原因2：大多數(shù)軟件工程師收入不高？在華為，-，創(chuàng)新工場，Google, Facebook, Twitter, A-zon，好的工程師薪水很高。如果你花超過30秒時間，你會列出一個更長的名單。如果你是好的工程師，你甚至可以創(chuàng)業(yè)，自己當老板，MarkZuckerberg（Facebook創(chuàng)始人），LarryPage（Google創(chuàng)始人），Bill Gates（微軟創(chuàng)始人）這些擁有百億身家的人都曾經(jīng)是工程師。在硅谷成千上萬的工程師創(chuàng)造暴富神話。并且，這些神話還在發(fā)生著。的確有工程師的薪水不高。如果他們是有潛力的，他們的薪水可能會上漲。如果他們自認為是好工程師，但是缺錢花，那我猜有可能他們不是好工程師。他們或許擅長架構設計，但是不擅長軟件工程；或許代碼寫得很好，但是交流能力欠缺。成功是需要經(jīng)驗和技能的積累。你必須無時不刻的學習。并且，每個人，無論他所在什么行業(yè)都會抱怨老板應該給我更多報酬，近來我只聽說一個人說他收入太高，政府應該多收他的稅。這個人就是著名投資人巴菲特。 原因3：既然Maurits的原因2是悖論，一些團隊需要管理者，一些可以自組織。很多我認識的非常好的管理者不單單是分任務，管理開發(fā)人員，對于他們來說更重要的是設定清晰目標，輔導缺乏經(jīng)驗的隊員。他們的共性是不追求細節(jié)管理，但是結果考核，授權給團隊去發(fā)揮。 原因4：Scrum不單單是一個流程，如果你讀過這本書，并且在3個以上的項目中實踐過Scrum的話，你一定會理解，Scrum可以幫助團隊快速學習，快速成長，早犯錯誤，早改進，早失敗，早總結。相對于聰明人來講，有經(jīng)驗的人可以創(chuàng)造出更好的團隊。我不太理解Maurits所說的”Good people”，我猜可能是和善，并且有經(jīng)驗的人吧。 原因5：項目或產品大致上分成兩種，一種是定制開發(fā)，一種是面向大眾的產品。大多數(shù)面向大眾的產品，例如SNS，搜索引擎，電子商務，在線游戲都會有產品經(jīng)理負責。他們非常關注用戶反饋，他們把自己的產品當做自己的baby一樣看待。大多數(shù)情況下，定制開發(fā)軟件的決策者往往是客戶方的業(yè)務經(jīng)理，他們未必那么關心產品。我個人經(jīng)驗中，那些非常關注產品的業(yè)務經(jīng)理往往得到更早的晉升。 原因6：我曾經(jīng)在TED上看過一個演講，演講嘉賓是DanPink（ted/talks...），他研究一個“如何激勵知識工作者”的題目。其結論是：知識工作者通常情況下有意愿提高自己，因為他們希望成為更有經(jīng)驗的人，學習更多知識，變得更資深。相對于在某個領域成為專家的追求，他們對收入的訴求相對會小一點。這是一個和其他領域非常不同的群體。知識工作者是一個極為特殊的生產力。 原因7：產品經(jīng)理專注與“做什么”和“為什么做”。開發(fā)團隊專注于“如何做”，但是他們同樣需要知道“做什么”和“為什么做”。Maurits的觀點是對敏捷原則和方-的一種片面的理解。我正在參與的一個敏捷組織轉型項目中，我所作的第一件事情就是和項目核心成員共同確定項目目標，策略等，之后給團隊所有成員解釋。這是創(chuàng)建一個目標驅動團隊的第一步也是必要一步。 “交付期限”是必須有的，它可以幫助業(yè)務部門和開發(fā)團隊巧妙的找到投資回報的平衡點。中國人的文化就是這種“中庸”文化。 產品質量也是“功能”，為什么呢？如果某個功能有bug，這意味該功能不能使用，換句話說就是這個功能的開發(fā)沒有完成。因此維護產品的質量等同于“挽救”功能。 原因8：幸運的是，大多數(shù)我曾工作過的項目“極其”在乎產品質量。為什么呢？其原因不是這些“平均水平”的工程師只朝九晚五的工作，而是因為他們并不想痛苦的加班加點的修bug。作為“知識工作者”他們希望自己更專業(yè)，更牛X，不想丟臉。 原因9：對于這條原因，我倒是不得不贊同。對于政府項目和固定預算固定范圍的項目，敏捷不是一個合適的方法。當我在英國做一家IT公司的運營總監(jiān)（COO）的時候，我說服了我的客戶從這種固定時間固定范圍的方法轉換成按人天付費的方法。最大的區(qū)別是什么？這種新的方式給予我的客戶更大的自由去爭取更多的投資回報。他們在乎么？當然在乎！在英國，大多數(shù)的政府項目使用PrinceII來管理，在中國瀑布模式還是主流。如果你不想你上繳的稅收浪費掉，盡你最大的努力說服你的客戶轉向敏捷方式吧。 最后說幾句，我真的不在乎一個項目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎。我真正在乎的是“組建牛X團隊”，“實現(xiàn)商業(yè)目標”，“創(chuàng)造出高品質產品”，“讓客戶滿意”，“增強客戶盈利能力”。恰好，包括敏捷在內的一些有效的方-幫助我去實現(xiàn)了以上的目標。我更希望看到我們的用戶在使用我們產品，玩我們的游戲的時候得到真正的開心和便捷。 摘自：blog.aaladdin

答案 2：

如果把軟件看成人的因素更重要，那么軟件開發(fā)實際上還是一種藝術；如果把軟件看成是標準的流程，那么軟件開發(fā)和流水線沒啥兩樣，各種方-、質量論就都是有效的?，F(xiàn)階段我仍然覺得藝術的成分居多，也就是靠人的創(chuàng)造力居多，所以各種方-基本上是靠不住的。

答案 3：

就軟件開發(fā)的生命周期而言，方-和過程是必須的，不然怎么能夠提高生產力，怎么控制質量？

答案 4：

性本善還是性本惡？這篇文章的出發(fā)點完全是基于麥格雷戈的X-Y理論的X理論而寫的。能為現(xiàn)在熱得不行的敏捷降降溫，本身我覺得是好的。可是以偏概全就缺乏說服力了?，F(xiàn)實中，敏捷到底行不行很大程度上與組織和團隊的成熟度有很大的關系。只有在一個良好激勵的成熟團隊中，才有施展的空間。我想不光是敏捷，團隊才是一切的基礎。而Scrum無非是一種方-罷了。

答案 5：

沒有哪一種方法是銀彈，Scrum作為敏捷方法中偏重于管理的一種實踐，我覺得很不錯，就看如何去體會和應用了。敏捷本身就不是百米賽跑，也許是個400米接力賽，馬拉松也有可能。要想獲得效果，人員、技術、過程，缺一不可。

答案 6：

敏捷開發(fā)=先-卡消費，在免息期還款(重構)。如果只對付最低還款額(重構不徹底)，需支付循環(huán)利息(技術債)。如果次次如此，最終資不抵債(架構腐爛)。如果直接無視賬單，珍惜生命，遠離-。 所以行不行更重要的在于團隊自身的還款能力，而非方法本身。

答案 7：

正在做一個Scrum項目，對于做政府項目的團隊來說，Scrum最大的好處是在一個可控的時間段內，明確了可控的目標，面對需求隨心而變的政府客戶，有了一個很好的拒絕變更的理由。同時，快速的迭代，也保證了隨時看到效果，隨時修正，很能應對變更，這些都能很好的保護團隊，維持團隊成員的積極性。那句話說的很對“真的不在乎一個項目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎”，老板，客戶都不會在乎這個～

答案 8：

行還是不行要看適不適合自己的團隊了，方法和流程沒有絕對的，適合自己的就是最好的

答案 9：

這篇文章看似胡攪蠻纏，但是有些理由的確是建立在陰暗的現(xiàn)實世界的基礎上的，比如Reason5和Reason7，對于我們這樣的外包公司，當需求無法從最終客戶手里獲得的時候，其他再-的方-都是擺設，毫無意義。 Scrum之所以讓人覺得不行還有一個重要的原因就是：推廣Scrum的人和書籍大多只介紹成功經(jīng)驗，卻很少客觀的指出哪些情況不適合甚至絕對不要使用Scrum，除非是一些財大氣粗的大公司和-項目，否則沒有幾個項目組有條件一再進行失敗的嘗試的，失敗了以后，大多數(shù)人都會把罪責推到新的開發(fā)方法上，其實并不是Scrum不行，而是Scrum本來就不適用。

下一篇:google很多開源項目，怎么學習？有什么建議或經(jīng)驗？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:iOS 沒有鍵盤類的 API ？ 上一篇 【方向鍵 ( ← )上一篇】