关于敏捷的一次内部争论

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

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

 

正文

原文地址以下：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的越早将结果呈现给客户越早发现问题的理念。一个好的原型赛过一万页需求分析说明书。