[转]对Why Scrum will never work的评论

近来，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团队”，“实现商业目标”，“创造出高品质产品”，“让客户满意”，“增强客户盈利能力”。恰好，包括敏捷在内的一些有效的方法论帮助我去实现了以上的目标。我更希望看到我们的用户在使用我们产品，玩我们的游戏的时候得到真正的开心和便捷。