导语：日前，酷壳站长陈皓编译的一篇《为什么Scrum不行？》再次引发了敏捷社区的一阵骚动。原文出自《Why Scrum will never work》，在那篇文章中，原作者分析了Scrum不适用的几种情况。当然，作者并没有对Scrum全盘否认，而是做了负面思考——思考事物的负面因素。因为这样才能更全面的分析一项事物的优缺点，并知道：它会起作用吗？缺点是什么？它有什么问题？为什么不能做。

 

作为敏捷方法领域最火的概念之一，批判Scrum是需要勇气的。在本文开篇处，陈皓也进行了“免责说明”，“这些东西相当的现实。希望各种Scrum的实践者们认识到这些问题，从而可以让你们明白软件开发中的人的重要性”。

 

以下是原文中提到的9个Scrum不行的理由。除此之外，陈皓在里面加入了自己的分析（感谢陈皓提供的精彩内容）。

 

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

 

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

 

有人看到这篇文章后也分享了团队实践Scrum后的心得，他觉得在他的团队里不适用Scrum有几个原因：

 

1.大家对技术不熟悉，因为目前主要的工作量在前端。大家以前都是做java后台的，对js不熟悉，把js当作java来面向对象。而且没有一个成熟的控件库使用。

 

2.没有在项目开始前做足够的技术调研。本来，应该有个architector来做这些事情。我觉得什么TDD，就是胡扯。没有前期调研，什么都是假设我们能做到，然后就去break down,然后就是估时间，只能是瞎估。估完了，真正implement的时候才发现，一堆东西stand in my way。

 

3.人的本性就是利己。如果一个team的performance，不和salary挂钩，大家凭什么会齐心协力，deliver更快，更好。目前情况下，scrum只是pm push developers的工具。现在，大家都想到偷懒的方法，就是尽量多估一些时间，或者implement的时候粗一些，反正都是一个个task领的，谁知道bug是谁的code导致的。以前如果一个人responsible for one module,就很容易知道谁的代码质量不高。

 

4.user story 拆分的不好，容易漏掉很多东西。大家现在都关注task,只想着做完就拉倒，根本不会想着各个task之间的边界和交叉影响。而且，大家现在就习惯看看task就做了，根本不会去看case,所以有些重要的flow全都漏掉了。

 

5.pm就是scrum master,整个team就是在一个不平等的环境下，scrum只不过是pm试验的工具，能在她的简历上添砖加瓦。我们只不过是小白鼠。

 

另一种观点认为，Scrum适用于一帮资深程序员组成的team，每个人都是牛人，每个人都有激情干活，这样才work。在国内大家只是干活拿工资，没什么激情，很不适合Scrum。

 

Scrum就是一把双刃剑，如何用、是否合适还是要看具体的情况。那么，您的团队是否采用过Scrum模式，效果如何呢？

 

http://sd.csdn.net/a/20110721/302047.html

更多精彩评论：

本人也捧一下：中国人更像C语言，而西方则更像是C++;中国的更多的时候是太极，西方就是拳击。所以只接拿老外的东西到中国生搬硬套，肯定是找死！

 

scrum只是提供了一种方式，如何去运作团队和管理项目，至于这种流程是否适合这个团队，是因人而异的，可能在西方适用，中国人不适用，所以我觉得还是应该回归敏捷本质，就是找到适合自己团队的运作方式

 

scrum对团队文化的要求很高的，如果团队整体都缺乏诚信，拒绝改变，拒绝进步，那不仅是scrum，无论采用何种方式开发都是一塌糊涂的。
scrum要求团队稳定，通过一轮又一轮的冲刺与回顾，提高整体的开发人员素质。
如果发现开发中有不认真对待项目的成员，趁早剔除，绝不能带坏整体团队氛围，否则这个团队就算是毁了。
scrum master绝不是什么领导，他和程序员是平级，要擅长理解，沟通与确认开发时间。他不负责开发，但是必须对开发精通。
所有的矛盾，程序员不必直接面对，都是scrum master来负责沟通解决的，所以沟通这样的软技能对scrum master很重要。
scrum 的基石不是简单的相信人，而是有条件的相信被多次项目筛选出来的人。没有技术底蕴的人，别搞scrum，否则保准被忽悠的一塌糊涂。

 

scrum的角色分为2组，猪组全权负责开发，鸡组部分参与监控项目。如果鸡组的这部分人对技术不了解，就有可能被猪组的这部分忽悠的一塌糊涂。
所谓的技术底蕴，并不单指计算机技术，指的是完成项目所需的技能知识。对于鸡组的成员，对这些不求掌握，但要熟悉。如果鸡组的团队对这些都不熟悉，那么这些环节上的任意一个人都有忽悠鸡组成员的能力。
当你一次一次进行scrum迭代的时候，对成员的工作状况都要有所了解，逐步加压直到发现成员压力过大。但如果你实际上不了解相关的技术，你能分辨出他是装出来的，还是能力不够，还是真的压力过大吗？
有良心的技术人员当然不屑欺骗你，绝大部分的技术人员也都是有良心的。但是很遗憾，这个社会上存在没有良心的人。

 

大多数实施敏捷的团队，都不是自发的，是“被敏捷”；大多数敏捷的团队都是在人员没有掌握足够的敏捷技能的情况下开始实施的，即是是团队中敏捷的积极倡导者，对敏捷的理解也不完全是正确的...敏捷团队缺少指导，而那些敏捷的咨询公司则完全是在忽悠。公司内的一个部门从外面聘请了一个咨询公司团队帮助实施敏捷项目，咨询师年轻的让团队中的女生都嫉妒羡慕恨，我问他们如何判断一个团队是否在敏捷开发，他们的回答是：“照着我们说的方法做就是敏捷”，这让我想到了当初的CMM。敏捷就是这样被唱衰的，Scrum和其它敏捷方法一样也不例外...

 

我是07年开始接触SCRUM，08年使用至今，当时是CMMI3实施到一半，团队讨论后停止CMMI的实施，直接转到SCRUM上，实施SCRUM的这几年，使我们团队在软件研发的氛围、成就感、责任心方面都有很大提升，我个人很喜欢演示会上获得客户认可的那种感觉，回顾上分享每一期的小小进步和下期的改进点，产品经理和测试作为一个团队互相支撑，客户经常参与我们的计划会和演示会也更加理解我们。

 

敏捷模式也需要相适应的企业文化做基础，国内能有这样企业文化的又有几家呢。

 

孙子兵法：
一曰道，二曰天，三曰地，四曰将，五曰法。道者，令民于上同意，可与之死，可与之生，而不危也...法者，曲制、官道、主用也。
团队一样，气场是前提。群情激奋下，不犯大错都能行。方法论，形式而已，所以只能放在第5位。
个人觉得Scrum告诉我们什么样的团队有气场，是结论，不是条件。（幸福的人都是一样的，不幸的人各有各的不幸）

不好意思。在下语文学得不好，影响交流了。
我的意思是，成功的团队氛围总是好的，内部总是和谐的。一堆崇尚敏捷的程序员在一起做Scrum当然成功几率大很多。
相反，如果在现有的环境下Scrum会引起广泛反感，那么用它做什么呢？一定要试水的话，也只能找一个独立的有局部氛围的小团队来做，这还是出于保护氛围的考虑啊。
幸福就是团队和谐的那种感觉啊。但凡成功的团队都有这种感觉，不管它是不是敏捷的。

 

根本就没有"本身很好"的东西.任何的模型的运作都是有前提条件的.离开了那些貌似不起眼的前置条件,而只谈某型本身,那肯定连狗屁都不如.这正的有价值的东西都隐藏在那些细节当中.如果不不重视细节.必定会败的一塌糊涂.

 

尤其是结对编程。
团队中通常程序员的水平是参差不齐的，我曾今和一个很差的程序员结对过。结果都是我在写代码，他在旁边发呆，因为他看不懂。
如果我每一句代码都要向他解释，这是一件多么恐怖的事情啊~
但是我仍然不得不结对，因为我希望他能看懂，然后将其他相同的工作丢给他做。当然结果我知道，他做剩下的工作中其中一个所用的时间，我自己写可以把剩下的全部写完。而且他写的程序却有很多的让你哭笑不得的错误。
但是我仍然又不得不这样做，否则我就需要做全部的事情，而他却什么也不需要做。
这是一个悲哀，我至今无法解决。

 

RUP都没玩好的公司的敏捷无非是给混乱的管理，找个借口。公司真正达到CMMI3水平及以上,估计实施敏捷还有可能成功；像练武一样，没有一招一式的基本功，直接就想无招胜有招，那不是骗人，就是白痴。有人说我们是搞互连网的，都是小项目，特点是短平快，相对于瀑布模式，我们是就是敏捷了，真的要喷饭了

 

其实问题不是出在方法上面，关键是出在执行方法的人上面，人的意识上不去，执行不力，任何方法都无济于事，瀑布开发流程一定不好吗，这世上有的是用这方法开发的，目前为止软件行业还无法摆脱它的影响。很多打仗的都读过《孙子兵法》，可是为什么有的人带兵还打不过连书都没读过的呢，原因不在《孙子兵法》，而在运用的人。这和我们的软件过程一样，大家天天在改进方法，其实应该改造的是做事的人。

 

从我们还是小朋友的时候，到长大，在遇到选择哪个职业的问题时，老师，家长，朋友，整个社会的观点都是惊人的一致：
要稳定，要挣钱多，要好找工作，要轻松~~
就是没有一个人告诉你，要想想自己的兴趣是啥。
在这样的大环境影响下，中国能出几个优秀的软件工程师？？
解决不了人的素质问题，就解决不了根本的问题。
用什么都没用，充其量就是糟糕和稍微好一点的区别。
要我说，多花点钱请优秀的人，同时把不合格的人开掉比什么都强。
另外看完文章最大的感觉就是：tmd做程序员太苦逼了！干活多挣钱少还要担责任，简直就是一群因为情商太低，无法混成领导或做销售的一群！！！

 

软件研发，人是第一位的。中国企业引入scrum是希望在人不太行的情况下，还能发挥一点效益。为了推scrum，不少公司因此养多了一些不干实事的人，人均效益反而减低了。

 

其实，根本的原因两点：
（1）在中国，国内的开发环境导致Scrum在某些场景不适合
中国的软件开发工程师非常多，但是有多少人能够真正的将开发作为自己的职业爱好，有多少人能够严格要求自己每天都在不断进步？每天想到的更多的是“QQ”、“微博”、“下班”、“看电影”、“加薪”等问题。
（2）中国的软件工程师的薪资待遇较低，职业规划问题严重
国外的软件工程师是高薪职业，薪资奖励制度非常好，有的公司的开发工程师也有像销售一样的提成，这样工程师哪还没有激情和动力去做好呢？
另外，国内的工程师在30岁以上基本都要考虑转型，而国外很多大型优秀软件的研发团队，很多都是有经验的老员工，包括技术架构代码实现等做的都非常的好。

 

scrum也无法解决， 没有给够足够能力的团队被要求在指定时间指定成本完成任务的问题，因为scrum不能逆天。如果给我一票谷歌的人，我去睡上一礼拜我相信他们也能做出很多有意思的东西。但是事实上，多数PM可能经常需要能带着各种心态和能力的人去挑战各种难题。

 

有保留的赞同部分观点. 我不知道scrum的核心思想是不是对人的信任, 如果是的话, 那么我敢说大部分scrum team确实只是学了一点表面, 也就是实施scrum的那一套process. 不过及时这点皮毛, 其实还是对项目有正面收益的: 1) process在需求风险控制, 进度控制上确实是有效的(当然也可以理解为pm push developer的有效工具) 2) 别人问你用什么模式开发, 你告诉他是scrum模式, 倍儿有面子. 然后你可以阐述一堆书上描述的虽然没实践过的理论, 倍儿有技术含量.

 

做敏捷本质上是对人的信任,做CMMI本质上是对法律的信任,做国内的项目本质上是对权力的信任.

 

我们就在用Scrum，当然理论归理论，实践起来要灵活变通。文中说的问题确实是问题，但是我们需要看到，每天组织大家一起聊一会天，效果确实不错。TDD再怎么不行，至少可以帮我发现很多很愚蠢的错误，及时修改，另外可以迫使我们团队去检查自己的代码，尽早地发现并解决问题。现在看来效果不错呀。
Scrum只是提供了一个指导原则，并没有说一定要怎么样怎么样，根据实际情况灵活变通才是一道。

 

文章说得太好了，深有体会，scrum中的自由、分享、进步、激情——对成员的素质提出非常高的要求。
好的团队可遇不可求
实施了scrum走入正轨了，成长性太可怕了。

 

作者只从他有限的了解来做了评论。如果题目改为《在XX公司Scrum不行》，《在XX群体Scrum不行》，又或者《在XX国家Scrum不行》那就更确切了。有一定深度的东西不是靠模仿来的，需要积累，而Scrum对文化的积累要求很高。

 

高水准的项目源于高素质的团队
技术，士气，热情，方法，在这些之后才能进行成功的项目管理
昨天还发现一个问题，项目中技术核心经验越丰富
对项目的估算精度就越高，项目在整个过程中就越接近成功点
------------------------------------------------------------------------------------
理想的项目状态
前景广阔的创意，充裕的资源，严谨的立项，强大的核心技术，成熟的项目管理方法
如果用数学划分
创意，15%
资源，30%
立项，10%
核心，25%
管理，20%
不知道各位的项目，能拿到多分呢？

 

世上本来就没有银弹，所以，也不指望Scrum能合适所有的项目。 3年前，我也带领一个团队做了一个产品的两个版本，用了Scrum。但是，团队里的人都十分有经验，并且，之前已经在这个产品开发上有多年的经验，所以最终我们还是基本上按照Scrum的思想去，切分Sprint， 用点去做Estimation，用工具生成Burn Down Chart, 早上有Stand Up Meeting。 当然，我们做很很多的定制，比如一个Sprint的周期，改成了5周，其中第一周是对前面的总结和下个Sprint的计划。 ... 总体来讲，还是不错的，特别是对有经验的团队做熟悉的项目。

现在，我们做项目即不是Scrum，又不是传统的waterfall，偏向迭代开发。

 

把软件做好的前提条件是团队里每个成员都要发自内心的想做、想做好。而这往往不是项目层面所能解决的问题。scrum只是个方法，解决不了所有管理问题，也解决不了之前提到的那个根本问题。