这篇文章是内部的一次邮件讨论，晚上写方案的时候，突然想换换脑子，于是翻出来重新整理了一下，放在园子里，希望这个砖头能引来更多的良玉。

最近在项目执行过程中，部分项目经理对于绩效考核制度产生了一些情绪，认为有苦劳就不应该考核绩效，或是认为项目经理不应对项目收款负责。我不知道有多少项目型的公司中项目经理对成本有着如何的敏锐性，只是觉得一个好的项目经理首先应具备一个良好、开放、感恩的心态。好了，牢骚话不说了，放正文吧。

正文

原文地址如下：http://coolshell.cn/articles/5044.html

准确的说，Scrum只是敏捷的一个分支。敏捷是泊来品，如果全部照单接收，当然有象这篇文章中说的这样那样的水土不服。但我相信人的动力和主动性是无穷的，传统的软件工程理论从根本上说是违反了人性的，过多关注了过程而忽略了目标。将一个项目目标事无巨细的拆分成无数的过程和细节，不可否认这样在流水线的生产环境上可以得到发挥，但在以创新、主动、学习、团结的软件开发过程中，过多的泯灭了人性中的光辉。

就这篇文章中的内容，根据我个人的一些片面的理解去阐述，仅供大家参考。

Reason 1:  Scrum 的基石是相信人。但现实人无法相信。

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

Answer  1:  Scrum的基石准确地说不是相信人，而是相信人普遍有成就自我的动力，这个动力符合马斯洛的人的需求模型的理论。我相信投身软件行业的人，无论抱着成就财富或是成就名誉，甚至成就延续人生价值的目标，都普遍适用。如果你相信一个道理能够直来直去的普遍适用于地球上的任何环境，那我只能表示遗憾，不懂灵活运用并不是理论的问题，只能说你的经历太少，书读多了并不代表你能真正地运用这些理论。

Reason 2: Scrum 认为只要给员工足够多的自由员工就能做得最好。

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

Answer  2: Scrum从未认为给员工足够多的自由就能做得最好，相反，Scrum要求团队不断在短周期内（一周）求证自己的成果，靠一个个划分成短期的目标来不断缩减总体目标的距离。只是这个过程中，Scrum要求团队的领导者有足够的教练技术，发挥每个员工的主观能动性，而不是一味的要求正规的过程，完善的管理。大家有兴趣的话，可以搜索一下“NLP教练技术”，这是Scrum中教练职位的理论来源。

Reason 3: 因为前面的原因，所以，我们仍然要把一个PM放在Scrum团队的上面做管理，这样才会有产出。

原文：于是，PM给团队分配任何，管得细枝末节，事无巨细，天天让你做进度汇报，等等

Answer 3 :这是中国Scrum变相的更改，我不认为这个更改有什么不好，难道Scrum中就不要求沟通是最重要的工作了吗。在中国普遍缺乏项目组合格教练的情况下，加一个PM来进行沟通协调各方的利益是再正常不过了。至于PM是不是要管到细节，那是根据企业管理制度和个人工作习惯，与Scrum无关。

Reason 4: Scrum 只不过是一个流程。

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

Answer 4 : 这个论点有点奇怪，既然说Scrum不好，那又为什么说其它公司没有按正规的Scrum来做。Scrum从未提出要优秀的员工来组成，只要求同一配对小组中，两个人的水平要相近。

Reason 5: Scrum delivers ‘business value’。

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

Answer 5 : 如果没有客户参与到项目组，确实传统的Scrum就无所适从。但任何一个理论都只适用于特定的一个和几个环境中。如何灵活运用，这是教练的事情，客户了解业务，教练了解客户和组员，这样就足够了。

Reason 6: 一个敏捷的团队应该是持续进步的。别天真了，人的天性是不喜欢改变的

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

Answer 6 : 我只能说没人喜欢改变可能是真的，但没人喜欢进步和没人喜欢改变是一个命题吗？个人进步是自我驱动的，而外界改变一个人是普遍很难的。在一个普遍以知识为谋生手段的行业环境中，拒绝成长的人根本无法生存。写这篇文章的人恐怕没有认真的思考一下基本的逻辑。

Reason 7: Product Owner 专注于 ‘what’ 和 ‘why’ 的问题，开发团队决定 ‘how’。

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

Answer 7:  还是传统的工程师思维，建立信任的基础是提供价值，技术如果没有收益就是废铁。而带来收益的技术哪怕再简单也会成为无价之宝，如果能深切的理解客户业务，实现的方式是多种多样的，只要能提供价值，客户怎么会管你具体用何种技术。更何况Scrum中评估工期是自下而上的综合评估，并非由Master或Product Owner说了算的。

Reason 8: 软件质量和生产率成正比。

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

Answer 8 : 基本常识错误，懒得回答了。

Reason 9: “是的，如果我们只做需要的功能，那么我们就会最低的成本，对吗？”

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

Answer 9 : 在国外是这样的，在国内确实这是Scrum的硬伤，所以需要变通，在需求上一定要严谨，而这里恰恰是要用到Scrum的越早将结果呈现给客户越早发现问题的理念。一个好的原型胜过一万页需求分析说明书。