前言

最近，敏捷开发的代表人物、也是 Agile manifesto 的作者之一 Ron Jeffries 发表了文章 Developer Should Abandon Agile（中译：开发者应该放弃敏捷）。InfoQ 也有这篇文章的 中文新闻。以作者的身份表达这样的观点，无疑是很有震撼性的，然而（我认为） InfoQ 的新闻并没有完整地表达清楚作者的思想，读起来有一种雾里看花的感觉。

这里，我试图从自己的角度，尽可能全面地传达 Ron 大叔原文中的观点，同时也想表达我自己的一些个人看法。当然，我会明确的将两者区分开，以下除特殊说明外，原文将统一以引用的形式标注出来。

背景

毋庸置疑，经过多年宣传和实践（从敏捷宣言发表至今已将近20年），敏捷已经逐渐成为开发社区中的主导性的开发思想。但繁荣的表面下也隐藏着很多不合理的现象，对此敏捷社区的人也应该是心知肚明的。记得前几年就有国内的一名知名业内人士说过“从此不再谈敏捷”（大意），可见对业界的现实相当失望。对国外的情况我了解比较有限，但从文章字里行间看，即便是在发达国家也存在同样的现象，并且这也是作者写这篇文章的主要原因：

“Agile” has become big business. Led, no doubt, by the Scrum Alliance’s successful Certified ScrumMaster offering, we now see hundreds, perhaps thousands of so-called “Agile” coaches and trainers, and many competing frameworks and methods. We see “Agile” leadership training, “Agile” project management offerings, and on and on.

文章第一段就描述了现实中的敏捷。作者的用词还是比较委婉的，不过我更愿意直白一点说：敏捷已经被某些人变成了一门生意。各种教学、培训、认证，本质上并不关心企业和个人的成功，而是奔着钱而来；而各种打着敏捷旗号的方法学、成功学、管理学也招摇过市，它们的一些做法其实是背离甚至反敏捷的。而这些人实施“敏捷”的后果，往往是自己戴上了大师的帽子，名利双收，扬长而去，给企业和开发者留下的却是一地鸡毛，同时给敏捷这个名字蒙上了污点。Ron 对此应该也是深恶痛绝的，因为他后文指斥这些为“虚假敏捷”（Faux Agile）和“黑暗敏捷”（Dark Agile）。

个人和企业

接下来，Ron 从个人和企业两个视角分析了敏捷运动所带来的后果。按照 Ron 的看法，即便敏捷实施得没有那么好，对企业来说也是有益处的，因为尝试总是会带来新的发现，从而改进决策：

Organizations that try to improve usually do improve, and so even if “Agile” ideas are applied poorly, trying will almost always provide some benefits to the organization. The organization should at least get increased visibility into what’s going on, and that will often lead even the least enlightened management to make better decisions.

对个人来说就不是那么美好了。下面这一段很重要，所以我全文引用，并在后面进一步说明。

The picture is not so attractive for developers, all the people engaged in actually building the products that the “Agile” enterprises are undertaking. When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.

这里提出了几个要点：

• 当“敏捷”理念应用不佳时，往往会导致对开发者造成更多干扰、完成工作的时间变少、更大的压力，以及“更快”的要求；
• 如果“敏捷”做得不好，会导致更多的缺陷和更慢的进展；
• 优秀的开发人员会离开推行“敏捷”失败的组织。

现实很残酷，但以我个人的经验来看，上面描述的这些都是真实的场景，而且也是部分人反对或厌恶敏捷的客观原因。我完全同意 Ron 大叔对个人影响大的观点，不过对于企业来说，我有不同的看法——在企业中实施敏捷失败并不是好事。尽管尝试的确会带来新的收获，但对于企业来说，项目是否成功是直接的、最重要的结果，因为企业是直接用真金白银为项目买单的；同时，也直接关系到企业开发者的薪酬问题。不论具体原因为何，项目的失败会被很多人直接归咎为敏捷的问题。很多经历过失败的企业通常也会变得更保守、更加抗拒改变。总之，我认为企业实施敏捷的失败是很糟糕的结果，在这个问题上，我并不像 Ron 大叔那样乐观。

敏捷的现实——更糟了

在下面一段话中，Ron 谈到他自己也是一名开发者，并且他关注的核心问题也是开发者的问题。最触动我的是这样一句话：

So it breaks my heart to see the ideas we wrote about in the Agile Manifesto used to make developers’ lives worse, instead of better.

如果在敏捷宣言发表近二十年之后，开发者的境况变得更糟，而不是更好了——不论这个锅是否应该由敏捷运动来背——那么我们还有自信说，敏捷成功了吗？并且，Ron 明确表示敏捷宣言中宣称的观点应该为此负有一定的责任。

我还是很钦佩 Ron 大叔勇于承认现实，而不是像某些粉那样无脑甩锅，或是基于本能拼命维护自己的观点。以“敏捷”为名，不切实际地要求开发者提高速度，忽略一切设计，毫无节制地变更需求————这也是许多地方客观存在的事实。如果敏捷的拥护者放任一些不负责任的夸大宣传 在市场上流传，那么实际上是在败坏敏捷的名声。敏捷鼓励拥抱变更，这似乎给了许多管理者和产品经理错误的信号，似乎用了敏捷之后，他们就有权力随时用一些拍脑瓜想出来的点子去反复折腾开发者。

反思——回归本质

接下来的段落中，Ron 对上述问题进行了反思，并且他给出的建议是：开发者应该理解敏捷的核心，即在宣言中声明的价值观；同时，尽量脱离特定的“敏捷”方法。同时，Ron 列出了他认为作为开发者应该坚持的若干实践，包括每周或每两周发布一个完全工作的版本、保持设计整洁、以当前进展作为写作的基础，等。

Be that as it may, I believe that developers should detach their thinking from any particular named “Agile” method. Instead, they should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods.

作为读者，我能从 Ron 的描述中感受到：他是 XP 的忠实拥护者，而对其他一些敏捷方法比如 Scrum 多少持有怀疑的态度。征之于现实，这种立场或许不无道理，不过相应的也导致该文带有一定程度的感情倾向。

说实话，看到 Ron 大叔的结论，我的心情是复杂的。从道理上讲，这个结论并无问题————很多现实问题确实是人们没有理解（或者刻意地曲解）敏捷的本质引起的。但是从现实的角度讲，这样无异于说“XX 不行了，让我们从头来过吧”，人还是同样的人，从头再来一遍，所有的错误就不会再发生了吗？

杂谈，关于敏捷

我认为，敏捷运动的形式可能是存在问题的。

敏捷宣言 是由 17 位作者联名编写的。这 17 位作者无疑在各个领域都是优秀的人物，但他们只是在价值观的层面达成了一致。他们各自的活动领域、兴趣及理论路线方面都有着极大的差别，并没有一位真正的核心级人物，从而也使得拥护者们在实践的层面上，不可避免地产生了各种不同的派别，甚至彼此之间有所冲突。例如 Rails 的作者、被视为敏捷代表任务之一的 DHH，也曾公开质疑过单元测试等敏捷理念。这种分裂事实上造成了，长期以来敏捷运动既没有一个统一的目标，也缺乏明确的发展路线，只是依靠爱好者的力量在推动。这对于敏捷的长期发展是不利的。

前面说过，经过十几年的发展，开发者目前的情况从某种程度上反而不如从前了。（这一点我认为 Ron 说的没错）但是我本人并不因此觉得前途一片黯淡。事实上我相信，这十几年里软件行业已经取得了很大进展。21 世纪头几年里，单机版应用还是最普遍的程序，企业软件刚刚发展起来，能支持几百个用户的程序已经算是“大型”系统了。分布式技术还是屠龙术，除了 Google 发表几篇论文外，整个业界基本上没有什么人能一窥堂奥。今天，许多互联网应用动辄要支持亿级以上的并发规模，得益于开源软件的发展，普通开发者自己也能搭建分布式架构，更不要说百花齐放的前端技术了。这些都是非常大的进步。因此，今天我们所看到的诸多问题，很大程度上并非是敏捷或者开发者有什么问题，而是我们今天要面对的软件世界更深化、更复杂了，要解决的问题也变得更加庞大了。

从另一方面说，对于目前的软件开发现实，敏捷或许是有点落寞的。在历史上，敏捷主要是以瀑布式开发的的反对者形态出现的。在这个背景下，我们可以说敏捷成功了：尽管目前仍然存在着针对敏捷的大量批评，不过现在几乎没有人认为瀑布优于敏捷。然而，瀑布早已不再是开发过程的主流，失去了主要的敌人，敏捷的存在意义也因此大打折扣。目前业界的主要形势是：前端呈百家争鸣的爆发性增长；新的语言和框架层出不穷，也有一批老旧的在慢慢死去；企业级开发已经不受重视了，互联网应用才是皇冠上的明珠；Web 和 Native 的争斗仍在继续；AI 野蛮生长，但没有人说得清未来是什么样的...对于面临新问题的开发者，敏捷似乎难以给他们足够的帮助和指导。

尽管我和 Ron 大叔的观点不尽相同，但是我们似乎最终走向相同的结论：或许，是时候“离开敏捷”了。