Alexandre Kotcherguine

Alexandre Kotcherguine

22 min 阅读 · 2026 年 6 月 30 日

敏捷去工程化

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

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。

免责声明：本文仅为信息与教育目的发布，不构成专业、法律、金融或工程管理建议，也不构成对任何方法、产品、服务或组织的认可。对《敏捷宣言》及其签署者、特定研究者、框架、公司和第三方出版物的引用，仅用于分析与评论。收录第三方来源并不代表 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 (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 (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 (Accessed: 23 June 2026).
  4. Jeffries, R. (2018) ‘Developers should abandon Agile’. Available at: https://ronjeffries.com/articles/018-01ff/abandon-1/; see also the ‘Dark Scrum’ collection: 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 (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 (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 (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/ (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 (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 (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 (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 (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/ (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 (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 (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 (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 (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
  • pragdave (2014). ‘Agile is Dead (Long Live Agility).’ Noun-vs-adjective argument; “marketing term”; ballet/trade-union analogies. 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
  • 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
  • Chaco Canyon Consulting (2019). ‘Conway’s Law and Technical Debt.’ Conway’s 1968 Datamation observation; architecture mirrors communication structure. 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
  • Laws of Software Engineering (2026). ‘Goodhart’s Law.’ Strathern phrasing; velocity, coverage and bug counts as gamed targets. 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
  • 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
  • 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
  • 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
  • DevClass (2024). ‘Enterprises struggle with Agile methodology.’ Practitioner survey: organisational resistance / culture clash cited by ~half, rising year on year. devclass.com
  • IT Pro (2024). ‘Agile development is fading in popularity at large enterprises, and developer burnout is a key factor.’ 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
  • 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
  • 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
  • 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
  • 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
Alexandre Kotcherguine

Alexandre Kotcherguine

22 min 阅读 · 2026 年 6 月 30 日