--- title: "敏捷去工程化：企业 Agile 如何侵蚀工程文化" canonical: https://wavect.io/zh/blog/agile-de-engineering/ language: zh description: "Alexandre Kotcherguine 与 Kevin Riedl 说明企业 Agile 如何保留仪式，却抛弃让软件得以长期稳定运行的技术纪律。" image: "https://wavect.io/img/blog/headers/header_agile-de-engineering.png" --- [**返回**](/zh/blog/overview/) ![Alexandre Kotcherguine](/img/team/alexandre-kotcherguine.jpeg) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) Alexandre Kotcherguine [Kevin Riedl](/zh/team/kevin-riedl/) 22 min 阅读 · 2026 年 6 月 30 日 [**下一篇**](/zh/blog/the-factory-returns/) 要点速览 企业 Agile 往往变成去工程化：可见的仪式继续存在，测试纪律、重构、架构余量与工程判断却被移除。 Alexandre Kotcherguine 与 Kevin Riedl 追溯从商业化、仪式捕获、指标倒置到自上而下规模化的整套机制， 并指出解药不是另一个框架，而是恢复工程文化本身。 # 敏捷去工程化 **一场旨在解放工程师的运动，如何反而侵蚀了企业的工程文化** **Polity 发布 | 2026 年 6 月** **作者：Alexandre Kotcherguine，Polity Vision Officer & Investor； Kevin Riedl，Wavect GmbH Managing Partner** *本文讨论软件开发方法论与组织设计，依据包括《敏捷软件开发宣言》签署者本人著述在内的公开资料，以及软件工程领域的实证研究。本文不构成任何专业、法律或投资建议。* ## 执行摘要 2001 年，十七位工程师签署《敏捷软件开发宣言》，以反抗此前几十年笨重且以控制为导向的流程。这是一场对工程手艺、可工作的软件以及软件编写者的捍卫。二十多年后，其中数位作者公开否定了「敏捷」一词后来的含义。本文认为，大型组织如今在 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 在后来的演讲中说，艰难的工程工作仍由企业自己完成。咨询公司像石头汤寓言里的来客，多数时候只带来一口锅。 ## “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 的十七人中有两位独立得出同一结论：标签已被捕获，而感受最深的正是它原本要服务的工程师。 这不仅是创始人的失望。实践者数据中也能看到同一模式。长期进行的 State of Agile 类年度调查显示，采用敏捷的主要障碍并非技术，而是文化。到 2023 年，接近一半受访者把组织对变化的普遍抵触或文化冲突，列为业务侧不接受 Agile 的原因，而且这一比例逐年上升。到 2024 年的行业报道记录了相应结果：Agile 在大型企业中的受欢迎程度下降，开发者倦怠被列为核心因素，方法论的「邪教式追随」也受到公开质疑。当 rollout 内部的人报告的是文化冲突与耗竭，而不是技术分歧时，签署者的诊断便从基层得到确认。 ## 实践是可选项，所以最先被丢掉 这里存在推动去工程化的结构性缺陷。Agile 中可见、可管理的部分，如 stand-up、sprint、backlog、story point 和 velocity 图，实施成本低，也容易审计。真正带来工程质量的部分，如测试驱动开发、持续集成、重构、结对以及对代码健康的刻意维护，学习缓慢，对非技术管理者不可见，也不会立刻形成一场仪式。组织采用框架却不采用工程手艺时，会保留仪式，丢弃工程。Jeffries 观察到，团队拒绝学习技术实践的一个原因，是预期它们没有收益。于是实践在价值被体验之前就遭抛弃，随后它们的缺席又被当作可有可无的证明。 Cunningham 的比喻以令人不安的精度解释了后果。去掉重构与测试纪律后，每个 sprint 都交付更多一点不够正确的代码。债务从未偿还，利息持续复合，因为每次后续改动都更慢、更危险。组织通过一系列局部合理的决定，最终抵达他警告过的停摆。“Working software over comprehensive documentation” 被误读成既不写测试也不写文档的许可。“Responding to change” 变成永远修改范围的通行证，却没有吸收变化所需的架构余量。为限制技术债而设计的纪律，正是那些看起来可选、因此最先被删掉的部分。 停摆不再只是比喻，而是财务项目。Stripe 2018 年的 Developer Coefficient 调查约 3,000 名开发者，发现普通工程师每周大约花 13.5 小时处理技术债，另有 3.8 小时处理糟糕代码。约 42% 的工作周没有用于构建任何新东西。报告把全球每年损失的产出估为约 850 亿美元 (6)。McKinsey 的技术债研究把同一现象放上资产负债表：受访 CIO 估计，技术债相当于其整个技术资产折旧前价值的 20% 至 40%，名义上分配给新产品的预算约有五分之一，被悄悄改用于偿债 (7)。Consortium for Information & Software Quality 在 2022 年报告中估计，美国企业累积的技术债约为 1.52 万亿美元，软件质量低劣的总成本则为 2.41 万亿美元 (8)。这些数字必然不精确，委托研究的供应商也有制造警觉的利益。但不同独立研究相互印证了这一数量级，也准确描述了 Cunningham 在 1992 年指出的复利。去工程化所抛弃的纪律，正是原本压低这个数字的东西。 ## 被改造的测量：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 说，一千人共同做一件事，不可能在原始意义上敏捷；企业自身必须先变得敏捷，内部项目才可能敏捷。商业激励却指向相反方向：最大的收入来自 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 证明，被抛弃的纪律恰好是有效的纪律。这让它们的消失成为对强制框架更严重的控诉，而不是更轻。项目维护者也罕见地坦率谈过失败方式。2023 年 10 月，DORA 团队明确警告，不要使用四项指标比较不同团队，而这恰好是企业最热衷的用途。计算机科学家 Junade Ali 与民调机构 Survation 的独立研究发现，工程师和用户都认为，四项关键指标未捕获的因素比速度指标本身更重要。结论与前文一致：一项合理的能力指标一旦被抬为跨团队目标，就会像 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，甚至 DORA 四项关键指标等预测工具被改成目标，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](https://wavect.io) 。 **免责声明：**本文仅为信息与教育目的发布，不构成专业、法律、金融或工程管理建议，也不构成对任何方法、产品、服务或组织的认可。对《敏捷宣言》及其签署者、特定研究者、框架、公司和第三方出版物的引用，仅用于分析与评论。收录第三方来源并不代表 Polity 认可该来源或与之有关联。合著者 Kevin Riedl 是 Wavect GmbH 的 Managing Partner；Wavect 为 Polity 项目提供软件开发与质量保障服务，见上文「关于 Wavect」。为保持透明，本文披露这项商业关系；它不影响分析的独立性。文中观点属于作者本人。 ## 参考文献 1. Beck, K. et al. (2001) *Manifesto for Agile Software Development.* Available at: [https://agilemanifesto.org](https://agilemanifesto.org) (Accessed: 23 June 2026). 2. Cunningham, W. (1992) ‘The WyCash portfolio management system’, *OOPSLA ’92 Experience Report.* (Origin of the ‘technical debt’ metaphor.) Available at: [https://c2.com/doc/oopsla92.html](https://c2.com/doc/oopsla92.html) (Accessed: 23 June 2026). 3. Thomas, D. (2014) ‘Agile is dead (long live agility)’. Available at: [https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html](https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html) (Accessed: 23 June 2026). 4. Jeffries, R. (2018) ‘Developers should abandon Agile’. Available at: [https://ronjeffries.com/articles/018-01ff/abandon-1/](https://ronjeffries.com/articles/018-01ff/abandon-1/); see also the ‘Dark Scrum’ collection: [https://ronjeffries.com/categories/dark-scrum/](https://ronjeffries.com/categories/dark-scrum/) (Accessed: 23 June 2026). 5. Fowler, M. (2018) ‘The state of agile software in 2018’. Available at: [https://martinfowler.com/articles/agile-aus-2018.html](https://martinfowler.com/articles/agile-aus-2018.html) (Accessed: 23 June 2026). 6. Stripe and Harris Poll (2018) *The Developer Coefficient: Software Engineering Efficiency and Its $3 Trillion Impact on Global GDP.* Available at: [https://stripe.com/files/reports/the-developer-coefficient.pdf](https://stripe.com/files/reports/the-developer-coefficient.pdf) (Accessed: 23 June 2026). 7. McKinsey & Company (2020) ‘Tech debt: reclaiming tech equity’. Available at: [https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business) (Accessed: 23 June 2026). 8. Consortium for Information & Software Quality (2022) *The Cost of Poor Software Quality in the US: A 2022 Report.* (Author: H. Krasner.) Available at: [https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/](https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/) (Accessed: 23 June 2026). 9. Strathern, M. (1997) ‘“Improving ratings”: audit in the British university system’, *European Review*, 5(3), pp. 305-321. Available at: [https://doi.org/10.1017/S1062798700002660](https://doi.org/10.1017/S1062798700002660) (Accessed: 23 June 2026). 10. Goodhart, C.A.E. (1975) ‘Problems of monetary management: the UK experience’, in *Papers in Monetary Economics*, Reserve Bank of Australia. Available at: [https://doi.org/10.1007/978-1-349-17295-5_4](https://doi.org/10.1007/978-1-349-17295-5_4) (Accessed: 23 June 2026). 11. DeMarco, T. (2009) ‘Software engineering: an idea whose time has come and gone?’, *IEEE Software*, 26(4), pp. 95-96. Available at: [https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf](https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf) (Accessed: 23 June 2026). 12. Conway, M.E. (1968) ‘How do committees invent?’, *Datamation*, 14(4), pp. 28-31. Available at: [https://www.melconway.com/Home/Conways_Law.html](https://www.melconway.com/Home/Conways_Law.html) (Accessed: 23 June 2026). 13. Forsgren, N., Humble, J. and Kim, G. (2018) *Accelerate: The Science of Lean Software and DevOps.* Portland: IT Revolution Press. Available at: [https://itrevolution.com/product/accelerate/](https://itrevolution.com/product/accelerate/) (Accessed: 23 June 2026). 14. Taylor, F.W. (1911) *The Principles of Scientific Management.* New York: Harper & Brothers. Available at: [https://www.gutenberg.org/ebooks/6435](https://www.gutenberg.org/ebooks/6435) (Accessed: 23 June 2026). 15. Ensmenger, N. (2010) *The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise.* Cambridge, MA: MIT Press. (On the “black art” of programming, the 1968 NATO conference, and the rationalisation of programming labour.) Available at: [https://doi.org/10.7551/mitpress/9780262050937.001.0001](https://doi.org/10.7551/mitpress/9780262050937.001.0001) (Accessed: 23 June 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.* Brussels: NATO Scientific Affairs Division, pp. 138-155. Available at: [https://www.cs.dartmouth.edu/~doug/components.txt](https://www.cs.dartmouth.edu/~doug/components.txt) (Accessed: 23 June 2026). 17. Cusumano, M.A. (1991) *Japan’s Software Factories: A Challenge to U.S. Management.* New York: Oxford University Press. (On the industrialisation of programming via the “software factory”.) Available at: [https://global.oup.com/academic/product/japans-software-factories-9780195062168](https://global.oup.com/academic/product/japans-software-factories-9780195062168) (Accessed: 23 June 2026). ## 新闻与网络来源（编号供事实核查） 正文把具体主张归于某位具名作者时，其一手来源列于上方「参考文献」。以下条目记录本文采用的二手报道与调查数据，以及各自支持的论点。 - InfoQ (2018). ‘Ron Jeffries says developers should abandon “Agile”.’ “Faux/Dark Agile”; enterprise-vs-developer asymmetry; imposition via SAFe/LeSS. [infoq.com/news/2018/06/developers-should-abandon-agile](https://infoq.com/news/2018/06/developers-should-abandon-agile) - pragdave (2014). ‘Agile is Dead (Long Live Agility).’ Noun-vs-adjective argument; “marketing term”; ballet/trade-union analogies. [pragdave.me](https://pragdave.me) - Martin Fowler (2018). ‘The State of Agile Software in 2018.’ “faux-agile”; the name used against its own principles. [martinfowler.com/articles/agile-aus-2018.html](https://martinfowler.com/articles/agile-aus-2018.html) - Wikipedia (2026). ‘Technical debt.’ Cunningham’s 1992 origin and the “standstill” quotation; extension of the metaphor to architecture and social structures. [en.wikipedia.org/wiki/Technical_debt](https://en.wikipedia.org/wiki/Technical_debt) - Chaco Canyon Consulting (2019). ‘Conway’s Law and Technical Debt.’ Conway’s 1968 Datamation observation; architecture mirrors communication structure. [chacocanyon.com/pointlookout/190130.shtml](https://chacocanyon.com/pointlookout/190130.shtml) - Ensmenger, N. (2010), *The Computer Boys Take Over* (MIT Press), and the “black art” chapter; programming reframed as “too artistic” at the 1968 NATO conference and rationalised thereafter; software engineering as a management response to a crisis of control. Author’s companion site: [thecomputerboys.com](https://thecomputerboys.com) - Laws of Software Engineering (2026). ‘Goodhart’s Law.’ Strathern phrasing; velocity, coverage and bug counts as gamed targets. [lawsofsoftwareengineering.com/laws/goodharts-law](https://lawsofsoftwareengineering.com/laws/goodharts-law) - Java Code Geeks (2026). ‘We have been measuring developer productivity wrong for forty years.’ LOC → velocity history; estimate inflation (“a 3 becomes a 5”); cross-team comparison breakdown. [javacodegeeks.com](https://javacodegeeks.com) - InfoQ (2009) and IEEE Software (2009). DeMarco, ‘Software Engineering: An Idea Whose Time Has Come and Gone?’ Recantation of “you can’t control what you can’t measure”; software as experimental/uncontrollable; primacy of transformation. [infoq.com/news/2009/08/demarco-software-engineering](https://infoq.com/news/2009/08/demarco-software-engineering) - Wikipedia (2026). ‘DevOps Research and Assessment.’ DORA’s October 2023 warning against team-by-team comparison; Junade Ali / Survation findings on factors beyond the four key metrics. [en.wikipedia.org/wiki/DevOps_Research_and_Assessment](https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment) - IT Revolution / dora.dev (2018-2026). Accelerate research scope (four years; 23,000+ respondents; 2,000+ organisations); the four key metrics and their capability drivers. [dora.dev/resources](https://dora.dev/resources) - DevClass (2024). ‘Enterprises struggle with Agile methodology.’ Practitioner survey: organisational resistance / culture clash cited by ~half, rising year on year. [devclass.com](https://devclass.com) - IT Pro (2024). ‘Agile development is fading in popularity at large enterprises, and developer burnout is a key factor.’ [itpro.com](https://itpro.com) - The Agile Revolution Podcast, Ep. 119 (2016). Dave Thomas interview: “1,000 working on one thing can never be agile”; enterprise must become agile before any project can be. [theagilerevolution.com](https://theagilerevolution.com) - Smartpedia, t2informatik (2025). ‘What is Technical Debt.’ Cunningham as one of the 17 Manifesto authors; taxonomy of debt including Conway-driven “service debt”. [t2informatik.de/en/smartpedia/technical-debt](https://t2informatik.de/en/smartpedia/technical-debt) - Stripe / Harris Poll (2018). *The Developer Coefficient* (survey of ~3,000 developers). 13.5 hrs/week on technical debt and 3.8 hrs on bad code (~42% of the week); ~$85bn global opportunity cost. [stripe.com/files/reports/the-developer-coefficient.pdf](https://stripe.com/files/reports/the-developer-coefficient.pdf) - McKinsey & Company (2020). ‘Tech debt: reclaiming tech equity.’ CIOs estimate tech debt at 20-40% of technology-estate value before depreciation; ~20% of new-product budget diverted to servicing it. [mckinsey.com](https://mckinsey.com) - CISQ (2022). *The Cost of Poor Software Quality in the US: A 2022 Report* (H. Krasner). Accumulated US technical debt ~$1.52tn; total cost of poor software quality ~$2.41tn. [it-cisq.org](https://it-cisq.org) QA 与生产就绪 ## 继续浏览此集群 [从核心文章开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [外部 QA 基准：软件产品前 30 天通常会发现什么](/zh/blog/external-qa-benchmark-first-30-days/) - [软件上线后维护要花多少钱：DACH SaaS 基准](/zh/blog/software-maintenance-cost-benchmark-dach-saas/) - [Lovable、Bolt 和 Replit 应用尽职调查](/zh/blog/lovable-bolt-replit-app-due-diligence/) - [Vibe-Code 生产就绪清单](/zh/blog/vibe-code-production-readiness-checklist/) - [把一个 vibe-coded 应用做到生产可用要花多少钱？](/zh/blog/vibe-coded-software-audit-cost/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) ![Alexandre Kotcherguine](/img/team/alexandre-kotcherguine.jpeg) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) Alexandre Kotcherguine [Kevin Riedl](/zh/team/kevin-riedl/) 22 min 阅读 · 2026 年 6 月 30 日 [**下一篇**](/zh/blog/the-factory-returns/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/agile-de-engineering/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/zh/blog/agile-de-engineering/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "企业 Agile 往往变成去工程化：可见的仪式继续存在，测试纪律、重构、架构余量与工程判断却被移除。 Alexandre Kotcherguine 与 Kevin Riedl 追溯从商业化、仪式捕获、指标倒置到自上而下规模化的整套机制， 并指出解药不是另一个框架，而是恢复工程文化本身。", "articleBody": " 博客概览/交付与 QA/QA 与生产就绪 要点速览 企业 Agile 往往变成去工程化：可见的仪式继续存在，测试纪律、重构、架构余量与工程判断却被移除。 Alexandre Kotcherguine 与 Kevin Riedl 追溯从商业化、仪式捕获、指标倒置到自上而下规模化的整套机制， 并指出解药不是另一个框架，而是恢复工程文化本身。 敏捷去工程化 一场旨在解放工程师的运动，如何反而侵蚀了企业的工程文化 Polity 发布 | 2026 年 6 月 作者：Alexandre Kotcherguine，Polity Vision Officer & Investor； Kevin Riedl，Wavect GmbH Managing Partner 本文讨论软件开发方法论与组织设计，依据包括《敏捷软件开发宣言》签署者本人著述在内的公开资料，以及软件工程领域的实证研究。本文不构成任何专业、法律或投资建议。 执行摘要 2001 年，十七位工程师签署《敏捷软件开发宣言》，以反抗此前几十年笨重且以控制为导向的流程。这是一场对工程手艺、可工作的软件以及软件编写者的捍卫。二十多年后，其中数位作者公开否定了「敏捷」一词后来的含义。本文认为，大型组织如今在 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 在后来的演讲中说，艰难的工程工作仍由企业自己完成。咨询公司像石头汤寓言里的来客，多数时候只带来一口锅。 “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 的十七人中有两位独立得出同一结论：标签已被捕获，而感受最深的正是它原本要服务的工程师。 这不仅是创始人的失望。实践者数据中也能看到同一模式。长期进行的 State of Agile 类年度调查显示，采用敏捷的主要障碍并非技术，而是文化。到 2023 年，接近一半受访者把组织对变化的普遍抵触或文化冲突，列为业务侧不接受 Agile 的原因，而且这一比例逐年上升。到 2024 年的行业报道记录了相应结果：Agile 在大型企业中的受欢迎程度下降，开发者倦怠被列为核心因素，方法论的「邪教式追随」也受到公开质疑。当 rollout 内部的人报告的是文化冲突与耗竭，而不是技术分歧时，签署者的诊断便从基层得到确认。 实践是可选项，所以最先被丢掉 这里存在推动去工程化的结构性缺陷。Agile 中可见、可管理的部分，如 stand-up、sprint、backlog、story point 和 velocity 图，实施成本低，也容易审计。真正带来工程质量的部分，如测试驱动开发、持续集成、重构、结对以及对代码健康的刻意维护，学习缓慢，对非技术管理者不可见，也不会立刻形成一场仪式。组织采用框架却不采用工程手艺时，会保留仪式，丢弃工程。Jeffries 观察到，团队拒绝学习技术实践的一个原因，是预期它们没有收益。于是实践在价值被体验之前就遭抛弃，随后它们的缺席又被当作可有可无的证明。 Cunningham 的比喻以令人不安的精度解释了后果。去掉重构与测试纪律后，每个 sprint 都交付更多一点不够正确的代码。债务从未偿还，利息持续复合，因为每次后续改动都更慢、更危险。组织通过一系列局部合理的决定，最终抵达他警告过的停摆。“Working software over comprehensive documentation” 被误读成既不写测试也不写文档的许可。“Responding to change” 变成永远修改范围的通行证，却没有吸收变化所需的架构余量。为限制技术债而设计的纪律，正是那些看起来可选、因此最先被删掉的部分。 停摆不再只是比喻，而是财务项目。Stripe 2018 年的 Developer Coefficient 调查约 3,000 名开发者，发现普通工程师每周大约花 13.5 小时处理技术债，另有 3.8 小时处理糟糕代码。约 42% 的工作周没有用于构建任何新东西。报告把全球每年损失的产出估为约 850 亿美元 (6)。McKinsey 的技术债研究把同一现象放上资产负债表：受访 CIO 估计，技术债相当于其整个技术资产折旧前价值的 20% 至 40%，名义上分配给新产品的预算约有五分之一，被悄悄改用于偿债 (7)。Consortium for Information & Software Quality 在 2022 年报告中估计，美国企业累积的技术债约为 1.52 万亿美元，软件质量低劣的总成本则为 2.41 万亿美元 (8)。这些数字必然不精确，委托研究的供应商也有制造警觉的利益。但不同独立研究相互印证了这一数量级，也准确描述了 Cunningham 在 1992 年指出的复利。去工程化所抛弃的纪律，正是原本压低这个数字的东西。 被改造的测量：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 说，一千人共同做一件事，不可能在原始意义上敏捷；企业自身必须先变得敏捷，内部项目才可能敏捷。商业激励却指向相反方向：最大的收入来自 SAFe、LeSS 及其同类扩展框架，它们恰好被卖给最不适合原始理念的大型层级组织。 Jeffries 直接指出后果。大规模 rollout 通常由高层决定后向下强制实施，多数员工在缺乏适当培训、也不了解底层思维方式的情况下被要求采用新流程。因此，到达工程师手中的东西恰好颠倒《宣言》的第一项价值：不是个体与互动，而是从上面交下来的强制流程和工具。Conway 定律让这一点更锋利。Melvin Conway 在 1968 年观察到，系统架构会映照构建它的组织之沟通结构。这意味着，一个僵硬、层级化、受仪式束缚的组织，往往会生产僵硬、脆弱且债务累累的软件，无论墙上贴着多少 Agile 标语。框架能扩展仪式，却无法扩展判断，架构会记录这种差异 (12)。 最强的反对意见：但这些实践确实可测量地有效 对本文论点最严肃的反对，不来自咨询公司，而来自这个领域最好的实证研究，因此应以最强形式陈述。Nicole Forsgren、Jez Humble 和 Gene Kim 主导的 DORA 项目，以 State of DevOps 调查为基础，并在 2018 年的 Accelerate 中综合成果。研究对数万名受访者使用严谨统计方法，证明本文所谓「工程手艺」的技术能力，如持续集成、测试自动化、基于 trunk 的开发以及松耦合架构，并非软性偏好，而是交付绩效和组织成果的可测量驱动因素 (13)。反对者因此认为，既然工程纪律的回报可以证明", "articleSection": "客座文章", "author": [ { "@type": "Person", "name": "Alexandre Kotcherguine" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" } ], "dateModified": "2026-07-07", "datePublished": "2026-06-30", "description": "企业 Agile 往往变成去工程化：可见的仪式继续存在，测试纪律、重构、架构余量与工程判断却被移除。 Alexandre Kotcherguine 与 Kevin Riedl 追溯从商业化、仪式捕获、指标倒置到自上而下规模化的整套机制， 并指出解药不是另一个框架，而是恢复工程文化本身。", "headline": "敏捷去工程化", "image": "https://wavect.io/img/blog/headers/header_agile-de-engineering.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/agile-de-engineering/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/agile-de-engineering/", "wordCount": 1417 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/qa-production/", "name": "QA 与生产就绪", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/agile-de-engineering/", "name": "敏捷去工程化：企业 Agile 如何侵蚀工程文化 | ", "position": 5 } ] } ```