补充“为什么Scrum不行”

最近有一篇“为什么Scrum不行”的文章很热，本来路过打酱油的时候看到过，但是后来在另外一个网站的敏捷诊室里边被要求评价一下，所以顺便转发到这里。

为了不让大家再去找原文，原文发在这里（好像是由一篇外文翻译的？没找到原始出处）：

因为本人经常站在Agile的风口浪尖，所以我有必要也来一个“免责声明”。Shit！其实我想来的是“不免责声明”——下文中的九大原因是对中国的各种Agile实践者咨询师不注重实际只重方法论的批判，本人必然要和那种只以流程方法论为中心的软件开发斗争到底。其实我没有那么嚣张，我只是想说，下面的这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人有重要。

　　Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队上顶上做管理，这样才会有产出。于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等。直至把团队拖垮。

　　Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好，什么需要改进，并定义行动方案。你真的以为员工想进步吗？让他们不得不去想想怎么进步，然后他们还不得不去执行行动方案。别天真了，人的天性是不喜欢改变的，人的天性是习惯于一些按部就般的事的，也许那样做令人讨厌，但是人家还是能干出来。如果你逼着人家改变，你就是在压迫人家，人家自然会反抗。

　　Reason 7: Product Owner 专注于‘what’和‘why’的问题，开发团队决定‘how’。很不错的分工，于是可以造就一个即高速有重质量的团队。然而，这根本不行。你的Product Owner马上就想要这个功能，他才不管你的软件开发的技术难题，人家只要快，要你meet deadline，要你给我们重要的客户做出承诺。另外，你千万不要以为你们可以哄走这个初级的product owner，因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰，或者只是外包公司，你觉得可能吗？你觉得创建信任可能吗？

　　Reason 8: 软件质量和生产率成正比。也就是说，质量越高，生产率越高。如果质量不高，你开发效率就会低下，但是谁管呢？我们朝九晚五的上班，质量好了也是做8小时，质量差了也是做8小时，无所为嘛。另外，我们的 project manager (或者是Scrum master!)总是会批评我们没有按计划完成。所以，这根本不可能。

　　Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”，为什么这世上总是会有这些幼稚的人？这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格（可能还会有回扣），为了打单子，销售什么都干得出来，让你去做项目是因为你是廉价劳动力，而且，他们会不断地加需求，因为软件合同谈好的价格时候，连需求都没有，你去做了才有，还是模糊和不确定或根本就是错的，然后需求是越来越多，越改越多。等你精疲力尽的时候，你才意识到，销售早就把你卖了。

整体上感觉世界上一共有这么几个问题需要回答，原文回答了第2和第3个，后面会补充回答另外4个：

1. Scrum行不行？

2. Scrum什么时候不行？

3. 为什么Scrum不行？

4. Scrum不行什么行？

5. Scrum什么时候行？

6. 怎样才能让Scrum行？

第2/3个问题其实原文回答得很好，当我们的公司1人心叵测，2程序员懒惰，3项目经理专断，4人才不优秀，5无人关心产品价值，6无人想改变现状，7产品经理蛮横，8无人关心质量，9开发组被销售出卖……的时候，Scrum不行，解释也很到位，几乎涵盖了所有敏捷开发咨询时被问到的尖锐问题。不过当这些问题都存在的时候，个人感觉已经不是讨论Scrum行还是不行的时候了，整个公司可能都快都不行了。

第4个问题不回答了，因为不能因为有人批评，就要求人家也创造一个方法论。这要是谁想批评秦始皇，恐怕至少得把台湾、蒙古、藏南全收回来再说话了。

之所以提出5、6两个问题，是因为本人被面试和面试的次数有100多次，发现用人单位对什么时候不行、为什么不行这类问题很不关心，但对什么时候行，怎样才能行的问题很关心，简单说就是凡事多看积极面，多点头少摇头，就能被聘用。所以对两个点头问题，不可不查。

下面简单地对R1～R9，从5/6两个问题的角度做个分析。

R1、R2讲的是自组织团队的问题，感觉很多团队相信“领导不来干涉，就是自组织了”。这个误解应该来自于领导过度干涉引发的逆反心理，原文也一针见血地指了出来。

本人虽然不相信所有人都是人心叵测和懒惰的，但的确只要出现一个这样的人，在“领导不来干涉”下建立的自组织团队就立刻分崩离析了，估计大家到时候恨不能领导快来干涉一下他。

R3讲的是团队领导的职能问题。其实在实际工作中，我还没遇到以“事无巨细指手画脚”为乐的项目经理呢，既无发展前途，又上下不讨好。但又有一大半项目经理的确以这种方式工作，原因就是R1、R2存在。如果同行压力解决了R1、R2，如果我是项目经理，我一定会专心业务或者管理，前途光明多了。

R5，R7，R9的产生，应该来自作者所经历过的真实企业，本人也遇到过。个人感觉应该分解为两个问题看：如果遇到了一个不存在579问题的好的产品经理（或销售……），我们能为他做什么？之所以要做这个假设，是毕竟世界上有多达10万以上的软件业产品经理和销售。答案是：当然用Scrum支持他！第二个问题是不幸我们遇到了同时存在579问题的产品经理，怎么办？答案是：如果没有比闭上眼睛更快的方法让他从面前消失，就得学会和他打交道。

本人在一段时间里边直接管理市场和销售工作。有一个销售人员在和客户花天酒地回来后很苦恼地来问：“有时候客户问我产品里边有没有这个功能，我深知只要说假话回答有，就能拿下单；而说真话回答没有，就会丢单。所以很痛苦。” 当时我的回答是：“反正一般即使成交也要3个月后才会去部署，所以请回答有，3个月后开发团队会为你造出那个功能，你不用说假话。”如果研发团队回答：“好的，瞧我们的吧”他就会回来和大家一起编写urgly的 backlog，否则，他会选择继续和客户花天酒地。

但上策其实是：既然领导关注生产率胜过质量，那么就让质量来提高生产率。平心而论，很多项目上自动化测试、测试驱动、持续集成是因为觉得这样才是先进的敏捷开发技术，而不是为了提高生产率让公司更好地生存。尽管两者在开头的做法是相同的，但之后会越来越远：前者会盲目地提高自动化测试比例、测试效率、追求100%测试驱动……后者会平衡更高的测试水平是否是现在开发的重点。

R6的情况很常见，算是最后一个总结性问题。曾经遇到过一个深圳的出租车司机，愤怒地提到10年前来到深圳一个月赚四万，现在连四千都没有。他牢骚了一路，最后我问他：这10年里您做过哪些事情尝试改变一切？我记得当时没有听到可以称为答案的内容，否则我们也遇不到他了。

其实本人因为杂七杂八的内容走访过100多家企业，从经历看不太相信有什么公司能彻底避免这9个原因，甚至很多公司9个原因都有。有道是“世界上从来不缺少发现问题的眼睛，缺少的是解决问题的大脑。”关键是面对9个原因时的心态是怎样的。

不过由于中国的IT业晚于其他国家很多，已经习惯了照搬国外的流程，很容易发生原文作者指出的“不注重实际只重方法论”的情况，咨询师和企业都应该认识到这一点，灵活应用，勇于变更。不能只想把企业结构变成敏捷的，还要把敏捷过程变成企业的！。

回到第1个问题：Scrum行不行？不确定。不过能确定的一点是，即使Scrum不行，有一天上帝本人抽空从太空降落到某公司，却遇到了R6的团队，我们第二天就可以看到一篇“为什么上帝不行”的文章了。

本文转自火星人陈勇 51CTO博客，原文链接:http://blog.51cto.com/cheny/1100242