补充“为什么Scrum不行”

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

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

---

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

　　Reason 1:  Scrum 的基石是相信人。创造一个安全的环境，这样每个人都能相互学习，相互直言。但是，这是不行的，这世上有很多人并不关心这些，而且政治和竞争到处都是，办公室里无小事，你和别人交心，你相信他们，最终受伤的你自己。你真的以为那里有空间让你可以去犯错，去冒险吗？别天真了！你啊，too young, too simple, sometimes naive!

　　Reason 2: Scrum 认为只要给员工足够多的自由员工就能做得最好。这该死是理论是基于什么玩意？不可能，人的天性是懒惰的，他们才不会把事做好的，他们只会做相应报酬的工作量，基本还达不到，认不想混日子啊。尤其是和经理比起来，谁不想能尽快地成为经理或Team leader啊，因为那样他们就可以即不干活，又挣得多。另外，你给他们自由，他们就会发现，他们会只会做他们感兴趣的事，要么聊QQ，要么打游戏，反正不干正事。直到你催了，他们才动一动。

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

　　Reason 4: Scrum 只不过是一个流程。这世上有太多的流程，尤其是那那些操CMMi的公司，几乎所有玩CMMi流程的公司，我看到的是员工都是那一副副苦逼的脸。所以，Scrum的流程同样会这样。因为这些都不是开发团队自发的，而是上面管你喜欢不喜欢按给你的。 Scrum 根本不可能增进你的软件质量和技术，只能是优秀的人才！使用Scrum的公司都是些吝啬鬼，他们不愿花大钱招优秀的人，他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率，Scrum成了push程序员最有用的工具。

　　Reason 5: Scrum delivers ‘business value’。不是这样的，实际上，Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队，那些人谁TMD愿意和苦逼的技术人员加班啊。那些人喜欢和我们的用户吃吃喝喝，花天酒地的，根本不会和你们那些奇怪的东西（如：backlog）或是那堆ugly的内向古怪的技术人员打交道，更别说什么技术了。所以，你的团队就像一个客服团队或救火队一样疲于奔命。

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

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

自组织团队实际上是有管理力量存在的，只是不是来自一条一条的领导指令。在外部而言，产品负责人以目标驱动的方式“管理着”团队，从内部而言，“跨职能团队”以“同行压力”管理着个体。比如在松结对编程系列中提到的1-3-9团队中，如论师傅还是徒弟，都很难“坦然地偷懒”。

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

R4说得很好，人优秀，项目才优秀。假设我们凑了一大群不优秀的人……额太悲惨了，人力资源部怎么搞的……还是换成一些优秀和不优秀的人的混合团队吧，怎样把他们全部变成优秀的人？师徒团队，松结对编程，共同估算，前后检查点……这些都能改善团队个体的能力。作为广大廉价劳动力中的一员，很多人极有可能希望公司不要把自己炒掉自己然后用大把钞票聘用优秀的人，而是希望能用Scrum让自己发挥更大的效率。

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

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

我们有两个制度保证销售不会乱提需求。一个是我会过滤所有功能，并判断哪些拥有市场前景，才交给研发团队；二是若产品部署中存在超支的服务，需要由销售承担，因此他们不会乱提不必要的需求。唯一可惜的是我们是外企所以本土销售不会承担功能开发费用而只提供实施费用，否则将更好地把责权利统一在一起。这两者都是为了避免公地悲剧。

“钱赚来了是销售的，活却是开发人员干的”……怎么说呢，本人还没见过一家企业销售不赚钱而开发人员工资很高，也没见过一家企业销售人员奖金风光无限而开发人员正准备去乞讨的，有的企业（1.B）甚至直接建立了开发团队从销售额中提成的制度。如果你不幸真的呆在一家糟糕的公司，不是Scrum不行，是公司制度不行。

R8的情况也很常见，在冬吴相对论里边称为无法“延迟满足感”，就是会把容易的事情都做了，麻烦的事情以后去吧。个人感觉无法用简单的语言劝说领导事先重视质量（有嘛？），可以采取无烟会议室中见机行事的方法。

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

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

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

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

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