这是一个来自Quora的问题。Rocket程序员Jasmine Adamson在文中表达了敏捷开发原则是废话的观点，他觉得现实生活中没有什么人会推崇这些原则来工作，不过他们仍然在说其所做的是敏捷，这是非常让人沮丧的。

以下为译文：

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在过去8年里，我一直工作于“Agile”开发小组，所以让我用敏捷开发原则来告诉你事实，或许你会明白为什么那些在像Google这样巨头公司工作的开发者会认为敏捷开发是废话。

1.及早并持续的交付有价值软件来满足客户需求的优先级是高的。

“我的客户一直由其他业务部门接洽，我从未见过我的客户，我不知道他们是做什么的。”这是现如今大多数公司的真实写照。

2.欢迎需求变更，即便是在开发的后期。为了客户的竞争优势。

没有人愿意接受改变需求。这就是第二个敏捷原则，普遍被厌恶的一个。

3.频繁交付软件，倾向于较短时间跨度。

部分公司在这方面做的很好，但是大多数团队无法很好的掌控敏捷时间的尺度。交付时间表通常是基于大的更新，而大更新不属于敏捷。

4.业务人员与开发者的绑定模式一直贯穿项目始末。

开发者和业务人员一起工作是罕见的，大多数公司都会有一个中间人来促进这种关系，然后效果是不理想的。开发者需要直接对话的应该是直接使用程序的人，而不是他们的经理。现实生活中的需求往往是由几个个层次以外的人来决定，而不是直接从用户到开发者那来的。

5.激发个体的斗志，以他们为核心创建项目——大多数人都不知道这表达了什么。

这意味着低水平的员工对软件有好的注意，并且他们积极的去解决问题。项目围绕这些欲望来构造，而这也了直接影响公司的底线。

5a.为他们提供所需的环境和支援，辅以信任，从而达成目标。

这是关于开发者的，你曾经有过这样的工作环境吗？你所需要的工具、访问权限和配件都有。或许不用多说什么了，不是吗？

6.不论团队内外，传递信息效果好、效率也高的方式是面对面交谈。

这句话的意思是告诉我不能用IM和邮件来交流吗？如果团队的成员分散于各地呢？我改进现有软件的有效方法是站在某人后面看他使用。然而在大多数公司中，你做不到这样，即便你知道客户是谁。他们也是忙的无暇顾你，也有可能是其他原因。现如今的人际交往不再像从前那样。不是吗？

7.可工作的软件是进度的首要度量标准

我们所在测量的都是类似于缺陷率、工作时间等事情，几乎从来没测量过这些事项：顾客得到可工作的功能了吗？我们发布了多少个可工作的功能？这些功能是大、中还是小的？没人知道。

8.敏捷过程倡导可持续开发。负责人、开发者和用户要能够共同维持其步调稳定延续。

这意味着每个人每周都要花30个小时在开发上，还需要花10个小时管理自己和工作负载、与他人沟通等等。这样才能保证这种做法持续下去。更多公司所做的是不定时的加班，有的则是经常加班。这是不可持续的。敏捷模式很少进入这样的紧急模式，而你则是经常性的。

9.坚持不懈的追求技术卓越和良好设计，增强敏捷能力。

在我看来这是对原则1和7的正确权衡。

10.以简洁为本，极力减少不必要的工作量

坦白来讲，大多数团队并没在这上面花费足够多的时间，我们终不仅复杂了软件，也复杂了开发习惯、复杂了代码，这减缓了维护和新开发。

11.好的架构、需求和设计出自自组织的团队

团队是由管理层组织的，几乎没有他们自己的事。不过这只是一个企业文化的问题，并很难被克服。有时在初创公司和小公司你可以发扬这种原则并让其工作，但是在大多数大公司，还是算了吧。

12.团队定期地反思如何能提高成效，并以此调整自身的举止表现。

这更多地算是一种常见的绩效考核形式，没有我们真正想要的层面。敏捷想要的是“作为一个团队，一起坐下来看看我们做了什么，如何在下一次做的更好”。然而实际上所发生的是个人主观上的计算和测量，基于这些团队几乎得不到任何实际的改进。

所以说敏捷是废话，因为没有人会推崇这些原则来工作，不过他们仍然在说其所做的是敏捷，这是非常让人沮丧的。

敏捷方法存在很多废话，但是同样的废话也会存在于新的软件开发中，从面向对象到面向服务的体系结构等等。一个真正的敏捷方法不适用于紧急状况，更多的是为了产品创新。如果作为准备，他可以改变整个组织，Salesforce从2007年就开始使用Scrum，这使它们能够创建一个可预测的发布周期。并因此而创建越来越多令人印象深刻的功能和产品。

需要明确的是，敏捷方法不是良方，有能力的人、勤奋、专注和自律造就的软件开发。