敏捷去工程化

一场旨在解放工程师的运动，如何反而侵蚀了企业的工程文化

Polity 发布 | 2026 年 6 月
作者：Alexandre Kotcherguine，Polity Vision Officer & Investor；
Kevin Riedl，Wavect GmbH Managing Partner

本文讨论软件开发方法论与组织设计，依据包括《敏捷软件开发宣言》签署者本人著述在内的公开资料，以及软件工程领域的实证研究。本文不构成任何专业、法律或投资建议。

执行摘要

2001 年，十七位软件从业者签署《敏捷软件开发宣言》，以反抗此前几十年笨重且以控制为导向的流程。这是一场对工程手艺、可工作的软件以及软件编写者的捍卫。二十多年后，其中数位作者公开批评了 Agile 作为品牌被实施后的样子。本文认为，大型组织如今在 Agile 旗号下实施的东西，往往构成一种去工程化：让耐久软件成为可能的技术纪律、架构余量与工程判断被逐步移除，可见的仪式却原封不动。文章既考察 Thomas、Jeffries、Fowler 和 Cunningham 等签署者本人的证词，也连接一条更广的思想脉络，包括 Taylor 与劳动史学者 Ensmenger、Goodhart 与 Strathern、Conway 与 DeMarco，以及 DORA 研究项目。由此可以看到一套清晰机制：一场工程手艺运动被捕获为品牌；可审计的仪式得以保留，缓慢的工程实践被抛弃；原本用于预测的工具被改造成施压手段；整套做法又被自上而下地强加到它从未为之设计的规模。最强的反对意见认为，工程实践已经被实证证明可以预测绩效。本文正面检验这一点，并发现它支持而非反驳本文的论点。最后几节重申了签署者近二十年来试图传达的教训：去工程化的解药不是更好的框架，而是恢复工程文化本身。

《宣言》本是一份工程文件

先回想原作者真正承诺的内容。《宣言》提出四组价值偏好：个体与互动高于流程和工具，可工作的软件高于详尽的文档，与客户合作高于合同谈判，响应变化高于遵循计划。同时，它明确肯定右侧各项同样具有价值。这份文件回应的是当时开发实践中的问题，也是彼此竞争的方法论者寻找共同立场的一次尝试 (1)。

关键在于，这场运动在工程层面并非空手而来。多位签署者直接来自极限编程（XP）。XP 由测试驱动开发、持续集成、结对编程、重构和代码集体所有权等纪律定义。其主要作者 Kent Beck 说，发明 XP 的目标之一，是让程序员的工作环境更安全。合作者兼签署者 Ron Jeffries 此后反复回到这一点。另一位签署者 Ward Cunningham 早已为这个领域留下最持久的工程审慎概念：技术债。这个比喻指出，一点不够正确的代码只有在很快通过重写偿还时，才能加速交付；从不偿还的组织，最终会被累积利息拖到停摆 (2)。敏捷在创立之初与技术实践不可分割。流程之所以能轻，是因为下面的工程足够强。

这个词成了品牌，品牌又被卖掉

按照作者们自己的叙述，衰落始于 agile 不再是描述工作方式的形容词，而变成一个可以买来、认证和推广的名词。2014 年，签署者 Dave Thomas 发表《Agile is Dead (Long Live Agility)》。他认为，这个词已经吸引所有手里有工时要开账单、有产品要卖的人，退化成类似 eco 或 natural 的营销标签。他刻意远离 Agile 产业，把关于敏捷性的大会比作关于芭蕾舞的大会，把围绕四项价值建立的行业组织比作「呼吸者工会」。他的语法抱怨包含实质指控：“do Agile right” 就像 “do orange right” 一样没有意义，因为敏捷是行动的特质，不是可以安装的产品 (3)。

这就是去工程化的第一套机制：商业化。一场由实践者发起、旨在保护实践者的运动，变成认证经济；卖方法的人往往不是写代码的人。Thomas 在 2016 年的一次访谈中说，艰难的工程工作仍由企业自己完成。咨询公司像石头汤寓言里的来客，多数时候只带来一口锅 (20)。

“Dark Agile”：当这个名字被用来对付工程师

如果说 Thomas 描述的是商业稀释，Ron Jeffries 描述的则更加尖锐。2018 年，他建议开发者放弃大写且品牌化的 “Agile”，回到其底层价值。他区分了 “Faux Agile” 与 “Dark Agile”，并把主流框架中的对应形态称为 “Dark Scrum”。这些形式在他看来让开发者的生活变得更糟，而不是更好，恰好颠倒了 XP 的创立意图。他的诊断值得直说：当 Agile 思想被糟糕地应用时，往往会带来更多对开发者的干扰、更少真正做事的时间、更高压力，以及管理层长期要求再快一点 (4)。

另一位签署者 Martin Fowler 同年在大会舞台上表达了相同观点。眼前的斗争不再是说服人们采用 Agile，而是对抗 faux-agile：只有 Agile 之名，没有相应实践与价值。比假装更糟的是，主动把 agile 这个词用于反对它原本要捍卫的原则 (5)。Snowbird 的十七人中有两位独立得出同一结论：标签已被捕获，而感受最深的正是它原本要服务的工程师。

这不仅是创始人的失望。Digital.ai 在 2023 年的第 17 份 State of Agile 报告中调查了 788 名受访者。该供应商报告称，小型组织仍对 Agile 持积极看法，中型和大型组织则满意度较低，也看到了全组织采用的实质障碍。报告还称，42% 的受访者使用混合模式，大型组织尤其可能如此 (18)。这是一项只能提供方向性信号的供应商调查，不是对所有软件组织的代表性估计，也不能证明 Agile 导致了倦怠或不满。但它确实显示，采用体验会随组织语境显著变化，这与签署者反对把方法当成可安装产品的警告一致。

实践是可选项，所以最先被丢掉

这里存在推动去工程化的结构性缺陷。Agile 中可见、可管理的部分，如 stand-up、sprint、backlog、story point 和 velocity 图，实施成本低，也容易审计。真正带来工程质量的部分，如测试驱动开发、持续集成、重构、结对以及对代码健康的刻意维护，学习缓慢，对非技术管理者不可见，也不会立刻形成一场仪式。组织采用框架却不采用工程手艺时，会保留仪式，丢弃工程。Jeffries 观察到，团队拒绝学习技术实践的一个原因，是预期它们没有收益。于是实践在价值被体验之前就遭抛弃，随后它们的缺席又被当作可有可无的证明。

Cunningham 的比喻以令人不安的精度解释了后果。去掉重构与测试纪律后，每个 sprint 都交付更多一点不够正确的代码。债务从未偿还，利息持续复合，因为每次后续改动都更慢、更危险。组织通过一系列局部合理的决定，最终抵达他警告过的停摆。“Working software over comprehensive documentation” 被误读成既不写测试也不写文档的许可。“Responding to change” 变成永远修改范围的通行证，却没有吸收变化所需的架构余量。为限制技术债而设计的纪律，正是那些看起来可选、因此最先被删掉的部分。

停摆不再只是比喻，组织也在尝试量化它。Stripe 与 Harris Poll 2018 年的 Developer Coefficient 调查覆盖五个国家的 1,000 多名开发者和 1,000 多名 C 级高管。报告称，开发者平均每周工作 41.1 小时，其中 13.5 小时归因于技术债，3.8 小时归因于糟糕代码。Stripe 对每年约 850 亿美元机会成本的估算，只适用于这 3.8 小时的糟糕代码，而不是全部维护时间 (6)。McKinsey 2020 年 7 月的调查范围更窄：50 名来自年营收超过 10 亿美元的金融服务和技术公司 CIO。这些受访者估计，技术债相当于技术资产折旧前价值的 20% 至 40%，并占用新产品技术预算的 10% 至 20% (7)。Consortium for Information & Software Quality 的 2022 年模型估计，美国累积技术债约为 1.52 万亿美元，软件质量低劣的总成本至少为 2.41 万亿美元 (8)。这些估算的定义、样本、资助者和方法各不相同。它们说明技术债会占用大量能力，但既不能建立统一通用的比率，也不能证明 Agile 导致了这些成本。

被改造的测量：Sprint 里的 Goodhart

第二套机制，是把预测工具转化为控制工具。Story point 与 velocity 原本只是粗略、相对于团队的规划辅助。一旦它们成为管理目标，Goodhart 定律就会生效。人类学家 Marilyn Strathern 对经济学家 Charles Goodhart 的著名表述是：“when a measure becomes a target, it ceases to be a good measure.” (9) 一旦 velocity 获得奖励，一项诚实估成 3 的任务就会变成 5。估算膨胀，跨团队比较失去意义，数字不再反映它原本要描述的产能。这不是不诚实，而是被测量者的理性优化。Goodhart 最初观察到的也是同一种结构效应：央行开始把原本有用的货币总量指标设为目标后，指标随即失效 (10)。

曾教会这个领域测量的人本人已经发出警告。Tom DeMarco 在 1982 年提出 “you can’t control what you can’t measure”，影响了一代软件管理者，却在 2009 年公开撤回立场。他得出结论，软件项目从根本上是实验性的，而不是可控的。他曾倡导的指标导向，让整个学科偏离唯一重要的问题：软件是否改变了任何有价值的东西。当控制范式的作者本人放弃它时，以 velocity 驱动的企业还在坚持一套被其架构师抛弃的方法 (11)。

规模从来不是重点，企业里却处处都是规模

创始人后来的评论中反复出现一个主题：敏捷为小型、共址、有自主权的团队而设计，不是为数千人通过企业层级协调而设计。Thomas 在同一次 2016 年访谈中说，一千人共同做一件事，不可能在原始意义上敏捷；企业自身必须先变得敏捷，内部项目才可能敏捷 (20)。商业激励却指向相反方向：最大的收入来自 SAFe、LeSS 及其同类扩展框架，它们恰好被卖给最不适合原始理念的大型层级组织。

Jeffries 直接指出后果。大规模 rollout 通常由高层决定后向下强制实施，多数员工在缺乏适当培训、也不了解底层思维方式的情况下被要求采用新流程。因此，到达工程师手中的东西恰好颠倒《宣言》的第一项价值：不是个体与互动，而是从上面交下来的强制流程和工具。Conway 定律让这一点更锋利。Melvin Conway 在 1968 年观察到，系统架构会映照构建它的组织之沟通结构。这意味着，一个僵硬、层级化、受仪式束缚的组织，往往会生产僵硬、脆弱且债务累累的软件，无论墙上贴着多少 Agile 标语。框架能扩展仪式，却无法扩展判断，架构会记录这种差异 (12)。

最强的反对意见：但这些实践确实可测量地有效

对本文论点最严肃的反对，不来自咨询公司，而来自这个领域最好的实证研究，因此应以最强形式陈述。与 Nicole Forsgren、Jez Humble 和 Gene Kim 相关的 DORA 项目对多年 State of DevOps 调查数据进行了统计分析，并在 2018 年的 Accelerate 中综合成果。该研究把持续集成、测试自动化、基于 trunk 的开发以及松耦合架构等技术能力，识别为交付绩效和组织成果的预测因素 (13)。这是对相关性和预测效度的强有力证据，但不能证明某一项单独实践在任何语境中都会导致所有结果。反对者因此认为，既然工程纪律的回报可以证明，市场必然会选择它，「去工程化」只是错误的悲观主义。

这个反对意见在事实层面是正确的，但也因此成为支持本文的证据。DORA 的研究结果表明，被抛弃的纪律与更好的结果相关。这让它们的消失成为对强制框架更严重的控诉，而不是更轻。该项目自身的测量指南同样重要。DORA 称，这些交付指标最适合用于跟踪同一应用随时间的变化，并警告管理者避免跨团队粗暴汇总，也不要比较不同语境。其官方历史还记录了该模型在 2024 年从熟悉的四项关键指标演变为五项软件交付指标，新增部署返工率，并把这些指标归入吞吐量和不稳定性两类 (19)。结论与前文一致：一项有用的指标一旦被抬为脱离语境的跨团队目标，就可能像 velocity 一样被 Goodhart 定律降质。DORA 没有授权指标迷恋，而是要求团队用测量来学习和改进。测量正确的东西与把它们设为目标，是两种不同的行为。去工程化就存在于两者之间的缝隙。

更深的模式：科学管理披着 Agile 外衣回归

退后一步，这个形状并不陌生，因为它比软件更古老。Frederick Winslow Taylor 1911 年的 Principles of Scientific Management 提出三步，至今仍定义工业管理：把工作分解为可测量单元，标准化工作流，以及最关键的一步，把工作的规划与执行分离，从工人手中拿走判断，集中到管理层 (14)。历史学家 Nathan Ensmenger 在 2010 年的 The Computer Boys Take Over 中表明，这正是后来应用于编程的方案 (15)。他记录了一门在 1950 年代被称为 “black art” 的手艺，如何从 1968 年 NATO Conference on Software Engineering 起被重新定义为 “too artistic”，继而遭到有意理性化。在他的叙述中，连 “software engineering” 这个词本身，都是管理层面对一支被认为难以控制、缺乏纪律且成本高昂的劳动力所采取的回应。同时期的 “software factory” 运动让 Taylor 式野心更加明确。Douglas McIlroy 在 1968 年主张大规模生产、按目录订购的软件组件 (16)；后来 Hitachi、Toshiba、NEC 与 Fujitsu 建立工业软件工厂，试图把编程从艺术形式变成 “repeatable, scientifically managed” 的供应链 (17)。

企业 Agile 的历史讽刺在于，它以一场旨在逃离这种范式的运动为旗号，重新建立了同一种范式。笨重、分阶段的流程，是软件行业第一次继承 Taylor；《宣言》反抗它；二十年后被强制推行、依赖仪式的规模化 Agile 又悄然恢复它。Sprint 变成秒表，story point 变成动作与工时单位，burndown chart 变成工头账簿，“velocity” 则把 “individuals and interactions over processes and tools” 原本要移走的控制重新交还管理层。这套机制甚至复制了 Taylor 对规划与执行的典型分离：自上而下的 rollout 决定流程，工程师只负责执行。这就是结果为何常常一边高举《宣言》，一边违反其第一项价值。这里必须精确定义立场，因为它很容易被误解为反对一切流程。本文并不认为规划、测量或协调不合法。大型软件显然需要三者，而它们所含的分工自 Adam Smith 以来就是生产型企业的基础。问题在于，当测量装置脱离工程判断，又被变成节奏工具，它就不再测量工程，而开始压制工程。DeMarco 的撤回，最终承认了控制范式把创造性、实验性活动误当作确定性活动，而且错误恰好在应用得最自信之处代价最大。

「去工程化」究竟意味着什么

把所有线索连起来，敏捷去工程化不是理念的失败，而是理念的实质被抽空后，包装继续存活。它遵循一套清晰顺序：

1. 商业化。 方法成为产品，由不写软件的人认证、扩展和销售。
2. 仪式捕获。 可审计的仪式得以保留；测试、重构、集成等缓慢且不可见的工程纪律被悄悄放弃。
3. 指标倒置。 Point、velocity 乃至软件交付指标等预测工具被改成脱离语境的目标，Goodhart 定律使它们退化为节奏工具。
4. 规模化强制。 扩展框架被自上而下强加给方法从未为之设计的组织。员工得到流程，却没有得到思维方式。
5. 工程手艺侵蚀。 技术债持续复利，架构按 Conway 所说的层级形状僵化，Cunningham 警告的停摆随着一次又一次看似合理的决定到来。

每一步在局部都合理，合起来却具有腐蚀性。没有谁主动决定去工程化。它是优先优化可见、可计费之物，而牺牲技术性、缓慢之物的涌现结果。这并非某位管理者的道德失败。像所有 Goodhart 效应一样，它是激励架构的结构属性，正是工程判断本应抵抗、而强制框架会系统性移除的那类系统行为。

恢复工程文化，不需要新框架

值得注意的是，诊断问题的创始人没有呼吁 Agile 2.0。Thomas 明确认为，再写一份宣言将是悲剧性的错误。答案不是另一个可以品牌化和出售的名词，而是回到底层思维方式：交付真正可工作软件的小增量，保持短反馈循环，最重要的是恢复那些最初驱动敏捷的技术实践。Jeffries 的建议同样具体而不宏大：按小切片工作，诚实面对真实交付能力，抵抗只是加快速度的压力。DeMarco 更加激进：与其完善控制，不如质疑为何有那么多低价值项目仍在严密控制下运行。

因此，给企业的教训并不舒服。去工程化的解药不是更整洁的看板、更高级的认证，也不是更忠实的框架 rollout，而是恢复工程文化本身：工程手艺、余量以及原签署者认为始终会位于「敏捷」一词之下的专业判断。抽走这些，只剩仪式：空洞地基上的每日 stand-up，架构腐烂时仍持续上升的 velocity 图。《宣言》作者近二十年来一直试图以自己的名义、甚至违背自己的商业利益来说明这一点。企业保留了大部分仪式，却错过了重点。在太多大型组织里，“doing Agile” 最显著的成就，是让软件开发去工程化，同时相信自己正在把它完善。

2008 至 2009 年金融危机让一代人认识到，优雅模型一旦从工具升格为教条，就会变得危险。企业 Agile 的历史在相邻领域传达同一教训：一种方法的危险不在于它错误，而在于它的仪式比赋予它意义的工程手艺活得更久。

关于 Polity

本文属于 Polity 治理模型内部持续推进的治理与思想领导力出版项目。Polity 的核心论点是，持久结果，无论发生在市场还是组织中，都由治理架构塑造，也就是工作、价值与义务借以形成的规则、激励和制度。从这个意义上说，软件工程是一个治理问题。本文描述的去工程化，正是组织激励架构奖励可见之物而非持久之物时发生的结果。Polity 为受监管数字金融建设基础设施，其治理框架旨在连接去中心化系统与机构级合规要求。

关于 Wavect

Wavect GmbH 是一家奥地利软件工程机构，为初创企业、规模化企业和大型企业构建产品导向的软件。服务涵盖全栈开发、兼职工程与产品领导、软件质量保障，以及人工智能、区块链和零知识系统的应用工作。Wavect 已为 Polity 项目提供软件开发与质量保障服务，合著者 Kevin Riedl 是公司 Managing Partner。更多信息见 https://wavect.io。

免责声明：本文仅为信息与教育目的发布，不构成专业、法律、金融或工程管理建议，也不构成对任何方法、产品、服务或组织的认可。对《敏捷宣言》及其签署者、特定研究者、框架、公司和第三方出版物的引用，仅用于分析与评论。收录第三方来源并不代表 Polity 认可该来源或与之有关联。合著者 Kevin Riedl 是 Wavect GmbH 的 Managing Partner；Wavect 为 Polity 项目提供软件开发与质量保障服务，见上文「关于 Wavect」。为保持透明，本文披露这项商业关系；它不影响分析的独立性。文中观点属于作者本人。

参考文献与一手来源

1. Beck, K. et al. (2001), Manifesto for Agile Software Development. agilemanifesto.org (Reviewed 2 September 2026).
2. Cunningham, W. (1992), ‘The WyCash portfolio management system’, OOPSLA ’92 Experience Report. c2.com/doc/oopsla92.html (Reviewed 2 September 2026).
3. Thomas, D. (2014), ‘Agile is dead (long live agility)’. pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html (Reviewed 2 September 2026).
4. Jeffries, R. (2018), ‘Developers should abandon Agile’. ronjeffries.com/articles/018-01ff/abandon-1/ (Reviewed 2 September 2026).
5. Fowler, M. (2018), ‘The state of agile software in 2018’. martinfowler.com/articles/agile-aus-2018.html (Reviewed 2 September 2026).
6. Stripe and Harris Poll (2018), The Developer Coefficient. stripe.com/files/reports/the-developer-coefficient.pdf (Reviewed 2 September 2026).
7. McKinsey & Company (2020), Tech debt: Reclaiming tech equity. McKinsey research PDF (Reviewed 2 September 2026).
8. Krasner, H. for the Consortium for Information & Software Quality (2022), The Cost of Poor Software Quality in the US. it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/ (Reviewed 2 September 2026).
9. Strathern, M. (1997), ‘Improving ratings: audit in the British university system’, European Review, 5(3), pp. 305-321. doi.org/10.1017/S1062798700002660 (Reviewed 2 September 2026).
10. Goodhart, C.A.E. (1975), ‘Problems of monetary management: the UK experience’. doi.org/10.1007/978-1-349-17295-5_4 (Reviewed 2 September 2026).
11. DeMarco, T. (2009), ‘Software engineering: an idea whose time has come and gone?’, IEEE Software, 26(4), pp. 95-96. doi.org/10.1109/MS.2009.101 (Reviewed 2 September 2026).
12. Conway, M.E. (1968), ‘How do committees invent?’, Datamation, 14(4), pp. 28-31. melconway.com/Home/Conways_Law.html (Reviewed 2 September 2026).
13. Forsgren, N., Humble, J. and Kim, G. (2018), Accelerate: The Science of Lean Software and DevOps. itrevolution.com/product/accelerate/ (Reviewed 2 September 2026).
14. Taylor, F.W. (1911), The Principles of Scientific Management. gutenberg.org/ebooks/6435 (Reviewed 2 September 2026).
15. Ensmenger, N. (2010), The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. MIT Press (Reviewed 2 September 2026).
16. McIlroy, M.D. (1968), ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.), Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. cs.dartmouth.edu/~doug/components.txt (Reviewed 2 September 2026).
17. Cusumano, M.A. (1991), Japan’s Software Factories: A Challenge to U.S. Management. Oxford University Press (Reviewed 2 September 2026).
18. Digital.ai (2023), 17th State of Agile Report. digital.ai/resource-center/analyst-reports/state-of-agile-report/ (Reviewed 2 September 2026).
19. DORA, ‘How to empower software delivery teams as a business leader’ and ‘A history of DORA’s software delivery metrics’. current measurement guidance; metric history (Reviewed 2 September 2026).
20. The Agile Revolution Podcast (2016), ‘Episode 119: Agile is Dead with Dave Thomas’. theagilerevolution.com/2016/11/25/episode-119-agile-is-dead-dave-thomas/ (Reviewed 2 September 2026).