当我们回顾过去一年，我们的视角转向 2024 年开发者生产力的发展趋势，这包括平台工程的创新、AI 的辅助作用以及对这些因素的量化评估。
2023 年，开发者生产力成为了一个日益受到关注的话题。这主要是因为 技术行业的大规模裁员 在云计算工具不断增加的复杂性中频繁出现。
在资源紧缩的背景下，团队被迫以更少的资源完成更多的工作。这导致的工作量和认知负荷几乎难以承受，迫使行业必须进行某种转变。
这促成了 平台工程 这一跨技术与社会的学科的发展，以及专门负责改善内部开发者工作体验的 开发者赋能团队 的出现。因为不管经济环境如何，有大量数据显示 快乐的员工通常更高效。
提升开发者生产力的努力主要集中在加快软件开发团队以高质量代码交付商业价值的速度。这种努力在消除软件交付过程中的障碍方面，将在 2024 年得到进一步扩展。
现在是时候回顾过去一年中开发者生产力方面的各项举措，并结合最新的研究成果，来预测 2024 年开发者生产力的走向。
平台工程的崛起
2023 年，平台工程成为软件开发界及 The New Stack 网站上的热议话题。我们甚至为此撰写了一本书。
平台工程，顾名思义，是一种支撑架构 — 通常是一个内部开发者平台加上相应团队 — 它为组织内大部分开发团队提供了一个坚实可靠的基础，使其能够安全地进行开发工作。
开发团队可以选择走不同的道路，但这意味着他们将偏离平台工程团队设定的通向高效生产的黄金路径，从而可能无法获得同等级别的支持和稳定性。
不同于以往自上而下、强制性的平台实现方式，现在的平台团队更像是以内部开发者为客户，采纳了一种将平台视为产品的理念。这种方法更注重于通过实际提升团队的工作效率来吸引用户使用。
今年早些时候，Syntasso 公司的首席工程师 Abby Bangser 对平台工程进行了界定，将其定义为旨在从软件开发生命周期（SDLC）中抽象出“重要但非差异性”的工作的团队和技术。DX 开发者体验平台最近发布的开发者生产力团队的常见类型列表也反映了这一观点：
- 开发者工具： 构建、测试、部署。
- 启用和内部支持： 规范化工作流程和提供支持。
- 前端平台： UI 组件、Web 框架、搜索。
- 后端平台： 认证、Web 网关、API。
- 基础设施： Terraform、日志、Kubernetes、可观测性、云服务。
- 可靠性： 事件管理和站点可靠性工程。
- 安全： 安全标准和风险管理。
- 数据： 数据工程、数据仓储、数据访问。
在 DevOps 时代，软件开发生命周期（SDLC）涉及了许多本应由开发团队来完成的关键工作，这些工作常常会使团队偏离其主要目标——为终端用户创造独特价值。平台团队，一个集成了部分或全部开发者生产力功能的团队，可以规范化和自动化这些关键工作，让开发者更快地感受到他们的工作高效且富有影响力。
但请注意：平台团队常常面临众多功能请求，需要优先考虑那些既能减少开发者工作摩擦又能提升工作流程的改进。因此，刚开始时这个任务特别具有挑战性。
Team Topologies —— 由 Manuel Pais 和 Matthew Skelton 提出的一种流行且可持续的团队结构方法 —— 倡导首先构建一个“最小可行平台”，这种平台能带来早期的成功。这通常是从提供清晰的文档或提高可发现性开始的，比如明确哪些人在做什么，以及如何做，并在此基础上逐步扩展。
平台工程并非一时之风。作为提升开发者生产力的首选策略，它正逐渐受到越来越多的投资。
Port 最近发布的 “2024 年内部开发者门户现状” 报告调查了 100 位在有 150 名或更多开发者的组织中的工程领导人，他们谈论了自己的平台和门户项目。内部开发者门户是开发者访问内部开发平台的方式。
研究发现，85% 的公司已经开始实施或计划实施内部开发平台（IDP），而 99% 的受访者至少已经开始了他们的平台工程之旅。
调查中最值得注意的是，53% 的受访者表示他们是在今年才开始这一旅程。这意味着到了 2024 年，我们很可能会见证这些平台的成熟期。
支持开发者的生产力提升
今年，The New Stack 探讨了开发者生产力团队或平台工程团队的规模问题。在初创企业中，几乎每位开发者都在为平台贡献力量，尽管这并不是他们的主要工作。这种做法体现了一个理念：遇到问题就解决，而且要做到大规模效应。
根据本作者一年来的采访，大多数提升效能的团队成员不到整个工程团队的 10%，Netflix 的开发者生产力团队则是个例外，其中有 15% 的成员专注于提升效能。
DX 最近的一份报告标题为“开发者生产力团队的规模”。报告调查了 40 个团队，发现拥有不足 1000 名开发者的公司中，约有 19% 的人力集中在开发者生产力团队。
而在员工超过 10000 名的大公司中，大约 11% 的工程师负责跨部门的工程效能提升。
无可否认，开发者生产力的提升就像它所支撑的工程一样，需要大量投入。但一旦运转起来，它应当能为整个组织节省大量时间和成本。从逻辑上讲，一个高效的平台团队的工作成果，应当远远超过其团队规模。
未来一年，我们可能会进一步了解随着平台越来越受欢迎，这些团队的规模是否会随之增长，或者随着平台的成熟，是否能够用更小的团队支撑更庞大的工程师队伍。
开发者效率指标的持续争议
OpsLevel 的 DevRel Fernando Villalba 最近在 LinkedIn 上表示，“对于不同的团队、不同的季度，甚至不同的个人而言，提高开发者或团队的工作效率的方法各不相同。”他认为，强制性地制定统一的效率指标是没有意义的。
然而，你无法提升那些你无法量化的东西。在这个大家都热衷于提升生产力的时代，衡量开发者的生产效率成了一个热门话题。实际上，许多出色的框架应运而生，正是为了做到这一点。
接下来，麦肯锡发布了一份报告，声称“是的，你可以衡量软件开发者的生产效率”，但这引发了广泛的争议。有人质疑，即使是世界上最大的咨询公司之一也未必能做到这一点。
确实，麦肯锡的框架是基于行业标准的 DORA 和 SPACE 框架发展而来的。但它试图创建一个自己的框架，这个框架过于狭隘地定义了开发者的生产力，认为开发者的主要价值在于构建、编程和测试。
这也是为什么，众所周知，开发者对生产力指标持怀疑态度的原因之一。
极限编程的创始人 Kent Beck 在接受 The New Stack 采访时表示，许多组织并没有提出并回答这些指标背后的关键动机问题：
- 是谁提出的问题？
- 他们与被评估者之间有什么样的权力关系？
- 提问的目的是什么？基于这些数据会作出哪些决策变化？
- 被评估者会采取哪些应对措施？
- 这些应对措施将如何影响管理者、投资者和客户的目标？
- 我们使用哪些单位进行测量？这些单位与其他人关心的单位（例如利润）有何关联？
“除非我们对这些问题得到彻底且坦诚的答案，否则我无法对衡量开发者生产力的任何尝试发表意见，”Beck 表示。
2023 年发布的其他生产力测量框架采纳了更为复杂的社会技术综合视角。其中包括 5 月份，计算机专业协会 (ACM) 发布的文章“DevEx: 真正驱动生产力的是什么，”该文认为生产力源于开发者体验，包括：
- 沉浸状态：开发者在专注工作时完全投入。
- 反馈周期：开发者完成工作所需的时间与等待时间之间的比较。
- 认知负担：开发者为了更快完成专注工作需要掌握的知识量。
这些 DevEx 指标在 2021 年的 SPACE 开发者生产力框架 的基础上，拓展了研究和建议，后者提出了 25 个社会技术因素进行测量。
“在一个常通过技术手段来测量行为的领域，我们必须记住，创造开发者生产力指标的背后，是真实的人在工作。”
— 《面向人类的开发者生产力》，Google
Google 最新的报告，发表于 12 月在 IEEE 上，“面向人类的开发者生产力，第 6 部分：测量开发者的流动、专注与阻力，”着眼于通过测量行为来提升生产力。这个模型聚焦于开发者的三个关键领域：
- 开发者的流动性。
- 专注时间。
- 阻力。
报告在间接提及麦肯锡框架时指出：“与代码行数或审查轮次等其他生产力衡量标准不同，我们定义的流动性和摩擦性指标更多基于人的判断，而不是仅仅依据特定工具的使用或行为假设。”
作者表示，他们对谷歌工程师的研究主要基于主观体验——以每日工作结束时的日记和后续访谈为基础，接着是基于日志的数据分析，并与第一种方法的结果进行了验证。
报告建议，不应只依赖于容易获取的数据，如构建次数。更为重要但也更复杂的是，要衡量开发者是否感觉自己处于高效的流动状态，或是被棘手的问题困扰。
2023 年初，Syntasso 的联合创始人兼首席运营官 Paula Kennedy 曾建议，制定平台工程路线图时，应从分析 Jira 上最常见的问题单开始，这能反映出团队共同面临的障碍和挫折。
谷歌最近的研究允许开发者自定义并识别摩擦——他们何时遇到摩擦，他们正在处理什么问题，以及如何解决这些问题。
在谷歌，开发者最常遇到的摩擦包括构建和测试的延迟、不稳定的测试，以及持续集成失败导致的代码更改受阻。在您的组织中，这些问题可能大相径庭，因此进行日记式的练习更显其价值，而且规划工作量不大。
无论您在 2024 年如何衡量开发者的生产力，所有方法的出发点和归宿都应该是与开发者的沟通，并且要理解在每个工程组织中，这些方法至少会有些许不同。
或许，您应该以一种不同的方式来开展这一讨论。正如 Atlassian 的高级技术布道师 Andrew Boyagi 所言，我们应将问题从“我们应该如何衡量开发者的生产力？”转变为“我们如何帮助开发者提高他们的生产力？”
生成式 AI：开创下一代开发者的生产力新篇章
在开发者生产力支持迅速崛起的同时，不得不提的是生成式 AI（简称 GenAI）的同步飞速发展。在 2024 年，AI 将持续作为一款重要的生产力辅助工具。
当平台工程着眼于激励团队，早期 GenAI 的主要优势则体现在个人层面。无论是自动化的任务审批，还是 AI 协助编程，个人任务的应用场景将成为持续采纳的关键。正如平台工程一样，AI 在解决最大的困扰和挑战中扮演着至关重要的角色。
比如，开发者们总是渴望更好的文档，却又不愿亲自撰写。谷歌云的《2023 DevOps 状态报告》指出，高质量文档对组织绩效的影响可达到惊人的 12.8 倍。
因此，像 Joggr 这样以案例为导向的 AI 工具在新年里将广受欢迎。这些工具旨在使用 AI 构建和更新集成开发环境内的内部知识库，与众多大品牌并肩作战。
但需要记住的是，并非所有生成式 AI 都是一样的。ChatGPT 生成的代码有 52% 的几率是不准确的，但其回应却颇具说服力。
随着公众不断训练这些大语言模型，它们的准确度也将不断提高。然而，工程组织必须制定并传达生成式 AI 政策，确保员工不会像 2023 年三星事件那样，将敏感数据泄露到公共数据库。
这不仅是因为声誉风险，也因为团队正在迅速适应这些 AI 辅助工具的使用，并不会轻易放弃。
开发者工具的新篇章：背景理解与 AI 协作
开发者们正快速采纳如 GitHub Copilot 这类工具。据报道，92% 的美国开发者在其首六个月内采用了此工具。这种趋势反映出，工具的便利性和开发者对 AI 提升工作效率的信念是他们尝试 AI 工具的关键驱动力。
例如，85% 的开发团队正在使用 GitHub，而 Copilot 的集成使他们减少了在不同上下文间的切换。尽管 Google 的 Duet AI for Developers 刚刚普及，但其在 Google 套件内提供的自然语言辅助，覆盖技术和协作方面的开发体验，正变得越来越吸引人。
12 月，Atlassian 在 Jira 和 Confluence 中集成了 AI 功能，预计我们将在 2024 年见证类似的 AI 应用 贯穿软件开发的各个生命周期。
不过，聊天机器人的帮助不止于此，它们所提供的背景理解同样重要。高级版的生成式 AI 产品不仅更安全——通常不会在私有数据上训练公共模型，而且它们更实用，因为它们是基于公司特定政策来训练的。
2024 年，GenAI 的应用将从满足个人需求，扩展到覆盖更广泛的软件开发生命周期 (SDLC)。
DX CTO Laura Tacho 对 2024 年最让人期待的 GenAI 升级之一是，通过 AI 技术提取应用程序的整个生命周期历史。她说：“你的应用已运行多年，有无数的拉取请求、Jira 任务和在 Notion 或 Confluence 中的设计文档。”
她向 The New Stack 表示，“你可以用这些资料来训练 AI 模型。这样一来，不论团队成员是在熟悉流程、开展新项目、调试问题，还是处理紧急宕机，AI 都能成为他们快速获取所需信息的有效工具。”
但是，与 McKinsey 那个众所周知的关于生产力的看法形成鲜明对比，Tacho 表示，“如果我们要提高生产力，大多数潜力其实在编程任务之外，因为编程并不占开发者所有工作时间的全部”，这表明到了 2024 年，AI 与开发者生产力的结合点还会进一步增加。
“随着我们对开发过程中的难点有了更深刻的了解，我们可以用非常有趣的方式将 AI 应用到这些问题上。”
虽然裁员依然存在，但大多数组织依然在寻找技术人才。缩短新员工培训时间仍然是提升生产力团队的一个目标。New Stack 今年早些时候报道，通过平台工程优化的最佳实践已经被证明可以显著缩短 Spotify 开发者的培训时间，从 110 天减少到 20 天。AI 将在这一过程中扮演越来越重要的角色。
不再是等待别人来培训你 — 或你的新开发者 — 而是通过与 AI 智能助手的互动学习来指导你，这会使新员工培训变得更加积极主动，Tacho 说。
“AI 让这个体验更加吸引人，帮助新员工更快地熟悉工作。”
