近日，在 Reddit 网站上一篇题为《简而言之，为什么许多开发人员不喜欢敏捷？》的帖子引发了开发人员的大量讨论。在该帖子中，许多开发人员表达了他们对敏捷的“感受”，以下是几个重点内容：
敏捷 = 随意的目标和不切实际的截止日期。
敏捷 =“繁文缛节”，没有开发人员发挥创造力的空间。
敏捷 = 催促开发人员赶紧完成工作。
让我们细想一下，敏捷的最初目的不是“人员比流程更重要”，并最终消除所有官僚作风和中间环节吗？
敏捷发生了什么？对于这个问题，2001 年拟定原始《敏捷宣言》（Agile Manifesto）的 Robert C. Martin 可能更有发言权。
他指出，敏捷方法长期以来被一大批通过认证的 Scrum master 和不了解软件开发的业务人员所劫持。
敏捷是由技术人员开发的，它是软件行业的产物。但随后出现了敏捷认证，并且成群结队的项目经理开始获得认证。于是，在这些通过敏捷认证的项目经理的引导下，敏捷运动朝着项目管理方面急剧转移。现在敏捷已经偏离了轨道。
此后，敏捷又出现了反向运动，就是软件工艺（Software Craftsmanship）。很显然，它试图回到敏捷最初承诺的那样，就是填补业务人员与编程人员之间的鸿沟。同时，催促开发人员不仅交付“可运行的软件”，还要交付“精心设计的软件”。这就引出了更大的技术债务。
下面是炮轰敏捷方法的其中一个读者评论:
我一直以来看到的是：敏捷是推迟棘手项目的根本原因。它堆积了技术债务，堆得又快又高，原因是我们专注于可还原、可扣除、可简化的问题。而当这堆技术债务倒塌时，也就是它变得政治化的时候，我们就非常糟糕地回到了起点。
Robert C. Martin 在另一次会议上也猛烈抨击了技术债务问题，他称敏捷想要保持干净的代码和防止代码腐烂的机制，但又有多少人因为步伐过快的 Scrum 团队所产生的错误代码而导致进度降低？这好比讲故事，如果你专注于讲完故事，那么故事质量必定降低。同理，代码腐烂的速度会与你急于迈出敏捷的步伐一样快，一年后会出现步伐开始放慢的情况，因为技术债务过重了。
项目经理 / Scrum master 是否明白这一点？一些人明白，但是很多人不明白。因此，开发人员有责任向经理提出这个问题，免得他们草率编写的“大杂烩式代码”要了某人的命。
因此，在理想环境下，应该让开发人员有足够的时间来清理或重构代码，并仔细考虑功能，以便使软件易于长期维护。
那么，我们可以使敏捷再次变得出色吗？敏捷方法已经存在了近二十年。大量的案例研究表明，敏捷方法可以改善公司的流程和软件质量，比如思科的主要软件缺陷减少了 40%，英国电信能够将交付周期从 12 个月缩短至 90 天，等等，这完全归功于敏捷方法。
那么，敏捷能否重新实现填补业务人员与程序员之间鸿沟的初衷呢？Robert C. Martin 猜想，只有当我们开始关注在一些不必要的官僚作风和一些项目上不断积累的技术债务时，这一幕才会发生。
总之，对于敏捷出问题，许多开发人员一直在表示担忧，其中包括像 Robert C. Martin 这样的知名人士。敏捷方法最常被提到的一些问题是：敏捷忽视技术债务；像 Scrum 这样的框架完全是“繁文缛节”，它们根本不应该是这样；程序员被要求恪守随意的估计和截止日期，却永远没有时间仔细考虑他们正在开发的功能。因此，如果我们能够承认这些问题，并努力解决这些问题，也许我们挽救得了敏捷方法。