InfoQ 2025 年趋势报告：文化与方法

作者 | Shane Hastie, Charity Majors

译者 | 张卫滨

策划 | 丁晓昀

主要内容

• AI 工具大大提升了开发速度，但是也带来了质量问题，因此需要新的测试和质量方法。

• 尽管 AI 在不断进步，团队协作依然非常重要，有一种风险在于，工程师有可能会转向 AI 而不是同事来寻求解决方案，这可能会破坏高效的协作文化。

• 初级工程师对整个行业依然至关重要，如今的初级工程师再向资深的同事提出具体的问题之前，可以利用 AI 作为学习的加速器，从而实现快速适应。

• 心理安全感依然是高绩效团队的基本要素，不过它正在遭受新冠大流行后的组织文化和经济压力所面临的挑战。

• 可观测性的成本在不断上涨，组织需要将可观测性作为一项战略投资，而不是将其视为成本中心。

• 敏捷和 DevOps 实践已经融入行业标准，成为“我们呼吸所需的空气”，平台工程会成为下一个发展方向，它会将产品和设计理念引入开发人员的工具。

1 AI 加速、工程卓越和不断发展的团队动态化

在年度的 文化与趋势报告播客 中，InfoQ 的文化与方法编辑团队与特邀嘉宾 Charity Majors 一起探讨了软件开发文化、工具和实践的变迁。从 AI 工具对开发实践的深远影响，到团队绩效和可观测性观点的演变，他们的广泛讨论揭示了影响软件团队 2025 年工作方式的几个关键趋势。

你可以通过播客收听完整的文化与趋势的报告讨论，并查阅相关的文字记录。

为了帮助 InfoQ 的读者以及 QCon 和 DevSummit 国际软件开发会议的观众把握现在和未来的趋势，我们使用了 Geoffrey Moore 在其同名著作中首先提出的“跨越鸿沟（crossing the chasm）”技术成功心理模型。我们努力识别符合 Moore 所说的早期市场的创意，在早期市场领域，“客户群是由技术爱好者和有远见的人组成的，他们希望能够抓住机遇或解决迫在敏捷的问题”。

与 2024 年、2023 年、2022 年、2021 年、2020 年、2019 年、2018 年 和 2017 年 的文化与方法趋势报告类似，我们提供了 2025 年的主题图：

作为互相参考的背景知识，如下是 2024 年的主题图：

2 AI 对开发的双重影响

最重要的趋势就是 AI 对开发实践的变革性影响。虽然 AI 工具极大地提高了生产效率，但是它们也带来了重大的 质量问题，团队依然在学习如何解决这些问题。

AI 的应用已经从谨慎的实验阶段发展为开发实践中不可或缺的一部分。最近的一些报告，比如 DevOps 状态报告，Copilot 等 AI 辅助工具已经成为现代开发工作流程中的重要组成部分。但是，这些报告也揭示令人担忧的变更失败率在不断上升。

“我们现在的构建块（chunk）正变得越来越大。多年以来，我们一直在致力于缩小构建块。现在，你只需要说‘机器人，给我一个解决方案’，就会得到好几页你甚至根本读不懂的东西。”

团队发现，AI 工具能让他们在不牺牲工作范围的情况下完成更多的任务，尤其是在黑客马拉松这样环境中。在一家企业的 AI 黑客周上，团队完成了从实现暗模式到创建解释数据库查询的工具或从其他供应商导入仪表盘的所有工作。各团队在短时间内完成工作的范围和深度均令人叹为观止。

不过，小组成员也强调了关于 AI 生成的代码在生产中失败率增加的统计数据。最近的一项研究显示，“据他们所知，发布的代码数量增加了 300%，但错误数量增加了 400%”，这似乎是一点不祥的预兆。这与 2024 年 DevOps 状态报告 不谋而合，该报告警告说，AI 的速度可能会导致变更列表变大，违反 DevOps 研究与评估（DORA）的小批量原则，从而增加不稳定性：

“根据前几年的研究结果，我们假设，AI 在受访者的生产力和代码生成速度方面带来了根本性的模式转变，这可能导致该领域忘记了 DORA 最基本的原则之一，即小批量的重要性。也就是说，由于 AI 允许受访者在相同的时间内生成更多的代码，因此变更列表的规模有可能，甚至很可能在不断扩大。DORA 一直表明，较大的变更会导致速度更慢，也更容易造成不稳定。 综合来看，我们的数据表明，改进开发流程并不能自动改善软件交付 -- 至少在没有恰当遵守成功交付软件的基本原则（如小批量和强大的测试机制）的情况下是这样的。

这一现实提出了新的挑战：团队习惯于通过找到编写或深入理解一段代码的专家来进行调试，但随着 AI 所带来的代码生成，特定的专家可能不复存在。业界刚刚开始制定如何处理和维护 AI 生成代码的方法。

3 技术应用中的“富人”与“穷人”

已经采用新技术的组织与仍在犹豫不决的组织之间出现了明显的鸿沟。这种技术采用上的差距表明，前沿团队正在使用各种可用的 AI 技术，而较为保守的组织则限制使用微软 Copilot 等有限的工具，两者之间形成了鲜明对比。

虽然一些更成熟的组织正在突破界限，但许多其他组织才刚刚摸索出如何以敏捷的方式来开展工作。如果没有坚实的既有实践作为基础，增加新技术和新方法的风险就会越来越大。

这种分歧可能会继续扩大。随着早期采用者不断完善 AI 工具的使用方法并开发出防止质量问题的防护栏，限制使用这些工具的组织可能会在能力和专业知识方面进一步落后。

4 在 AI 强化的世界中如何实现团队协作

虽然 AI 可以提高个人的生产力，但专家小组担忧 AI 对团队协作所带来的潜在影响。高效的软件开发从根本上取决于有效的团队合作。软件开发是协同性的工作。高绩效软件开发团队的关键在于协作，而 AI 可能会抑制协作。

工程师们越来越多地向 AI 寻求答案，而不是咨询同事，这可能会破坏高绩效协作文化的推进。

“人们在 AI 上问了更多的问题，然后看着 AI 产生的结果，会觉得‘好吧，我们现在已经得到了答案，所以不需要再去找组织里的其他人了’”。

小组成员一致认为，在急于采用 AI 的过程中，团队必须保留人类协作、反思和学习的空间。可观测性、渐进式部署策略和生产验证等赋能性功能的重要性仍然需要人类的监督和协作。

5 初级工程师在 AI 增强型行业中的价值

尽管有人担心 AI 可能会削弱初级工程师的作用，但专家小组还是极力主张初级工程师 依然非常重要。业界认为不再需要初级工程师的声音受到了质疑：

“我看到很多人在说‘哦，我再也不会雇用初级工程师了’之类的话，我认为这种说法太短视了。这是一个学徒制的行业。我们都是通过向其他人学习而学会的。”

今天的初级工程师远没有被 AI 取代，他们正在迅速适应，将 AI 作为学习的加速器。初级工程师在与资深同事接触之前，会利用 AI 来完善自己的问题，从而使他们的互动更加高效、更有针对性。

建立重视学习和持续改进文化的团队为初级工程师提供了一个天然的家园，他们可以对团队的知识共享能力进行压力测试。组织如果解雇初级工程师，就有可能失去团队长期弹性的重要组成部分。

6 高绩效团队：心理安全感与反思

在讨论 2025 年如何打造高绩效团队时，专家小组强调了几项持久性的原则和新兴的实践。

心理安全感 仍然是基础：

“如果你想建立高绩效团队，那就需要让每个人都真正参与到团队中来，每个人都贡献出他们个人所能做的最好的东西...... 如果你想实现这一点，关键的一点是团队中应该有心理安全感。

新冠大流行后的组织文化，再加上经济方面的压力，对许多团队的心理安全感提出了挑战。许多组织正在削减团队辅导和赋能相关的角色，让经理或新晋升的工程师在没有充分培训或准备的情况下填补这些空白。

从技术角度看，紧凑的反馈回路至关重要。缩短员工编写代码与代码投入生产之间的时间。尽可能缩短反馈周期，并使其尽可能紧凑。

高绩效团队要求系统有一定的松弛度。任何以 100% 使用率运行的团队都会停滞不前。

“如果你的团队一直以 90% 的速度运转，就会让人 疲于奔命，而这需要很长时间才能恢复过来。”

7 度量指标和改进周期

工程度量指标 已经成为一个越来越重要的团队改进工具。当工程师因构建失败、需求不明确或其他障碍而损耗时间时，跟踪精益浪费的工具就会用来收集各种数据。

高绩效团队并不惧怕衡量标准，但衡量标准应该是对话的开端，而不是对话的终结，更不是评估工具。不要用指标来 评判人，而是要用指标来帮助识别系统中的瓶颈，然后解决这些瓶颈。

对成本、周期时间、吞吐量、事故次数和恢复时间指标，以及产品指标要进行定期的审查，为持续改进提供必要的反馈。这些审查并不需要耗费大量时间，即使是简短的定期检查也能带来价值。

仅抽出时间进行改进这一行为就有很重要的意义。关注绩效、关注指标告诉了我们什么内容、保持好奇心、尝试真正了解团队中发生的事情，这都是实现改进的关键。

8 可观测性的成本危机

最引人注目的趋势之一是 可观测性成本的迅速攀升。Gartner 的统计数据显示，一家客户的可观测性成本从 2009 年的每年 5 万美元增长到 2024 年的 1400 万美元，在 15 年间每年增长 40%。

一位小组成员警告说：“如果不解决这个问题，我们都会被淘汰。”

企业必须要确定，可观测性是一项需要确保最小化的成本，还是一项能带来红利的投资。使用 10-20 种可观测性工具的企业，其可观测性成本与业务增长之间的乘数实际上是 10-20 倍。

然而，可观测性成本的增长在一定程度上反映了系统复杂性的增加。系统的复杂性在呈爆炸式增长，上升速度越来越快。现代系统如此复杂，变化如此之快，以至于工程师无法依赖心智模型，认知负荷往往过高，他们需要强大的可观测性工具来了解系统的行为。

一种可能的解决方案是采用 数据湖 的方法，一次性存储所有可观测性数据，并通过 AI 界面进行访问。购买可观测性决策应该被视为投资，而不仅仅是成本。

9 超越“敏捷”和“DevOps”：下一步是什么？

讨论中几乎没有提到“敏捷”和“DevOps”这样的术语，这表明这些方法已经融入到行业实践中，不再需要明确标注。

“InfoQ 的文化和方法领域曾经全是关于敏捷类的东西，而现在我们正处于后敏捷时期。有趣的是，在整个播客中，它一次也没有被提及过，这就是对相关领域的总结。”

另一项观察结果在于，“我对 DevOps 有这种感觉。我觉得我们正处于 DevOps 运动的黄昏时期，这并不是因为 DevOps 已经不再重要，而是因为它现在已经成为我们呼吸的空气。”

展望未来，不断改善 开发人员的体验 非常重要。平台工程 被认为是一个很有前景的方向，它被描述为“将产品思维和设计思维引入到为工程体验而构建的工具中”。“工程师也是人，好的设计可能会提高开发人员的工作效率”，这一认识代表了行业思维的重要演变。

Gene Kim 的“三种方法（Three Ways）” 原则侧重于流程、反馈和持续学习，为超越传统的敏捷方法提供了一个有用的思维框架。这些原则与目前讨论的许多趋势相吻合，从加速开发流程到改进可观测性反馈和创建学习环境。

10 结论：分布不均的未来

在小组讨论结束时，与会者对 William Gibson 的著名观点进行了反思，即“未来已来，只是分布不均”。这句话完美地概括了行业的现状，一些团队在利用最先进的工具和实践，而另一些团队仍在苦苦挣扎。

我们注意到了行业的一些积极发展，包括平台工程的出现和 Staff Plus 工程职业道路的建立，这些道路提供了超越管理层的晋升机会。资深的个人贡献者往往是那些制定计划来招募和指导初级工程师的人，他们认识到 “没有具有建设者信誉的人来谈论建设者需要什么”。

对于希望在快速发展的环境中茁壮成长的团队来说，主要经验包括：

• 拥抱 AI 工具，但要围绕其使用制定防护措施和质量规范

• 保持并加强团队协作

• 为初级工程师投资并创造学习环境

• 在代码创建和生产之间建立紧密的反馈回路

• 将可观测性作为一项战略投资，同时管理其不断增长的成本

• 为实验、反思和改进保持系统的宽松度

• 认识到 DevOps 和敏捷等实践已成为基础，而非差异化的因素

通过专注于这些领域，开发团队可以应对 2025 年的复杂挑战，同时建立更有弹性和更高效的组织，能够交付日益复杂的软件系统。

InfoQ Culture and Methods Trends Report - 2025(https://www.infoq.com/articles/culture-trends-2025/)

声明：本文由 InfoQ 翻译，未经许可禁止转载。