如何评价网络热文《 Scrum 行还是不行 》？
2012-01-19 17:42:46   来源：   点击：

9 个答案

• 答案 1：

  以下是我对那篇博文的点评。欢迎大家讨论 近来，Maurits的一篇博文"Why Scrum will never work" 一石激起千层浪。著名技术分享网站酷壳（coolshell.cn/articles...）翻译了这篇文章，我的好朋友，网站创始人陈浩还加入了他的一些想法。 直到我看到在知乎（zhihu.com/question...）上的一个问题之前，我也认为大多数软件开发团队已然知道敏捷是什么，可以给团队带来什么。他们可能完全不在乎别人怎么看敏捷。（注：知乎是李开复老师创新工场孵化的类似于Quora的一个中文问答网站） 说一下我对Maurits9个“Scrum永远不能成功的原因“的解读： 首先，我个人认为一个产品的成功和是不是使用什么方法论，工程实践没有必然联系，尤其是对于小而简单的产品更是如此。其次，我个人不认为在没有广泛应用的软件工程实践的支撑下Scrum可以持续不走样的保持下去。这些工程实践包括持续集成，自动化测试，简单设计，代码审查等等。 我个人理解，敏捷不单单是Scrum和极限编程的集合，而是一个以精益原则为基础，可以创造目标驱动，自我驱动和学习型的团队的一整套方法论。这也是我选择帮助很多产品团队不断完善自我作为我职业的原因。 原因1：我完全赞同，的确有些人很难在最开始相信别人。我也曾有过一个团队中的大多数人希望得到我的帮助，但是个别人非常抵制的经历。为什么会这样呢？因为“信任歧视”！你可以读我另外一篇博文有对这个话题的分析（blog.sina.com.cn/s/blog_6...）。但是这并不意味着，这些人永远不会或者故意不相信别人。如果您已经读过我的博客，你就知道他们其实相信某些人。这些人是领域专家，朋友，家庭成员或者和他们有共同价值观的工程师。任何人都不会否定，“团队中没有信任”是项目失败的首要原因之一，是毒药，也会造成工作效率低下。因此每个人都希望能建立一个互相信任的团队。我也在努力帮助团队互相信任。如果你想创造出牛X的产品，不想浪费你宝贵的生命，这就是一个非常有挑战但不得不做的任务。当你拥有这样一个团队，你成功一半了。 原因2：大多数软件工程师收入不高？在华为，腾讯，创新工场，Google, Facebook, Twitter, Amazon，好的工程师薪水很高。如果你花超过30秒时间，你会列出一个更长的名单。如果你是好的工程师，你甚至可以创业，自己当老板，MarkZuckerberg（Facebook创始人），LarryPage（Google创始人），Bill Gates（微软创始人）这些拥有百亿身家的人都曾经是工程师。在硅谷成千上万的工程师创造暴富神话。并且，这些神话还在发生着。的确有工程师的薪水不高。如果他们是有潜力的，他们的薪水可能会上涨。如果他们自认为是好工程师，但是缺钱花，那我猜有可能他们不是好工程师。他们或许擅长架构设计，但是不擅长软件工程；或许代码写得很好，但是交流能力欠缺。成功是需要经验和技能的积累。你必须无时不刻的学习。并且，每个人，无论他所在什么行业都会抱怨老板应该给我更多报酬，近来我只听说一个人说他收入太高，政府应该多收他的税。这个人就是著名投资人巴菲特。 原因3：既然Maurits的原因2是悖论，一些团队需要管理者，一些可以自组织。很多我认识的非常好的管理者不单单是分任务，管理开发人员，对于他们来说更重要的是设定清晰目标，辅导缺乏经验的队员。他们的共性是不追求细节管理，但是结果考核，授权给团队去发挥。 原因4：Scrum不单单是一个流程，如果你读过这本书，并且在3个以上的项目中实践过Scrum的话，你一定会理解，Scrum可以帮助团队快速学习，快速成长，早犯错误，早改进，早失败，早总结。相对于聪明人来讲，有经验的人可以创造出更好的团队。我不太理解Maurits所说的”Good people”，我猜可能是和善，并且有经验的人吧。 原因5：项目或产品大致上分成两种，一种是定制开发，一种是面向大众的产品。大多数面向大众的产品，例如SNS，搜索引擎，电子商务，在线游戏都会有产品经理负责。他们非常关注用户反馈，他们把自己的产品当做自己的baby一样看待。大多数情况下，定制开发软件的决策者往往是客户方的业务经理，他们未必那么关心产品。我个人经验中，那些非常关注产品的业务经理往往得到更早的晋升。 原因6：我曾经在TED上看过一个演讲，演讲嘉宾是DanPink（ted.com/talks...），他研究一个“如何激励知识工作者”的题目。其结论是：知识工作者通常情况下有意愿提高自己，因为他们希望成为更有经验的人，学习更多知识，变得更资深。相对于在某个领域成为专家的追求，他们对收入的诉求相对会小一点。这是一个和其他领域非常不同的群体。知识工作者是一个极为特殊的生产力。 原因7：产品经理专注与“做什么”和“为什么做”。开发团队专注于“如何做”，但是他们同样需要知道“做什么”和“为什么做”。Maurits的观点是对敏捷原则和方法论的一种片面的理解。我正在参与的一个敏捷组织转型项目中，我所作的第一件事情就是和项目核心成员共同确定项目目标，策略等，之后给团队所有成员解释。这是创建一个目标驱动团队的第一步也是必要一步。 “交付期限”是必须有的，它可以帮助业务部门和开发团队巧妙的找到投资回报的平衡点。中国人的文化就是这种“中庸”文化。 产品质量也是“功能”，为什么呢？如果某个功能有bug，这意味该功能不能使用，换句话说就是这个功能的开发没有完成。因此维护产品的质量等同于“挽救”功能。 原因8：幸运的是，大多数我曾工作过的项目“极其”在乎产品质量。为什么呢？其原因不是这些“平均水平”的工程师只朝九晚五的工作，而是因为他们并不想痛苦的加班加点的修bug。作为“知识工作者”他们希望自己更专业，更牛X，不想丢脸。 原因9：对于这条原因，我倒是不得不赞同。对于政府项目和固定预算固定范围的项目，敏捷不是一个合适的方法。当我在英国做一家IT公司的运营总监（COO）的时候，我说服了我的客户从这种固定时间固定范围的方法转换成按人天付费的方法。最大的区别是什么？这种新的方式给予我的客户更大的自由去争取更多的投资回报。他们在乎么？当然在乎！在英国，大多数的政府项目使用PrinceII来管理，在中国瀑布模式还是主流。如果你不想你上缴的税收浪费掉，尽你最大的努力说服你的客户转向敏捷方式吧。 最后说几句，我真的不在乎一个项目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎。我真正在乎的是“组建牛X团队”，“实现商业目标”，“创造出高品质产品”，“让客户满意”，“增强客户盈利能力”。恰好，包括敏捷在内的一些有效的方法论帮助我去实现了以上的目标。我更希望看到我们的用户在使用我们产品，玩我们的游戏的时候得到真正的开心和便捷。 摘自：http://blog.aaladdin.com

• 答案 2：

  如果把软件看成人的因素更重要，那么软件开发实际上还是一种艺术；如果把软件看成是标准的流程，那么软件开发和流水线没啥两样，各种方法论、质量论就都是有效的。现阶段我仍然觉得艺术的成分居多，也就是靠人的创造力居多，所以各种方法论基本上是靠不住的。

• 答案 3：

  就软件开发的生命周期而言，方法论和过程是必须的，不然怎么能够提高生产力，怎么控制质量？

• 答案 4：

  性本善还是性本恶？这篇文章的出发点完全是基于麦格雷戈的X-Y理论的X理论而写的。能为现在热得不行的敏捷降降温，本身我觉得是好的。可是以偏概全就缺乏说服力了。现实中，敏捷到底行不行很大程度上与组织和团队的成熟度有很大的关系。只有在一个良好激励的成熟团队中，才有施展的空间。我想不光是敏捷，团队才是一切的基础。而Scrum无非是一种方法论罢了。

• 答案 5：

  没有哪一种方法是银弹，Scrum作为敏捷方法中偏重于管理的一种实践，我觉得很不错，就看如何去体会和应用了。敏捷本身就不是百米赛跑，也许是个400米接力赛，马拉松也有可能。要想获得效果，人员、技术、过程，缺一不可。

• 答案 6：

  敏捷开发=先刷卡消费，在免息期还款(重构)。如果只对付最低还款额(重构不彻底)，需支付循环利息(技术债)。如果次次如此，最终资不抵债(架构腐烂)。如果直接无视账单，珍惜生命，远离信用卡。 所以行不行更重要的在于团队自身的还款能力，而非方法本身。

• 答案 7：

  正在做一个Scrum项目，对于做政府项目的团队来说，Scrum最大的好处是在一个可控的时间段内，明确了可控的目标，面对需求随心而变的政府客户，有了一个很好的拒绝变更的理由。同时，快速的迭代，也保证了随时看到效果，随时修正，很能应对变更，这些都能很好的保护团队，维持团队成员的积极性。那句话说的很对“真的不在乎一个项目是用敏捷，Scrum，瀑布或者CMMI，完全不在乎”，老板，客户都不会在乎这个～

• 答案 8：

  行还是不行要看适不适合自己的团队了，方法和流程没有绝对的，适合自己的就是最好的

• 答案 9：

  这篇文章看似胡搅蛮缠，但是有些理由的确是建立在阴暗的现实世界的基础上的，比如Reason5和Reason7，对于我们这样的外包公司，当需求无法从最终客户手里获得的时候，其他再牛逼的方法论都是摆设，毫无意义。 Scrum之所以让人觉得不行还有一个重要的原因就是：推广Scrum的人和书籍大多只介绍成功经验，却很少客观的指出哪些情况不适合甚至绝对不要使用Scrum，除非是一些财大气粗的大公司和内部项目，否则没有几个项目组有条件一再进行失败的尝试的，失败了以后，大多数人都会把罪责推到新的开发方法上，其实并不是Scrum不行，而是Scrum本来就不适用。