开发人员体验
“帮助开发人员实现更多目标的最佳方法不是期望他们做更多,而是改善他们的体验。”
–Nicole Forsgren, Founder of DORA metrics and former Partner Research Manager at Microsoft
什么是开发人员体验(DevEx)?
为开发人员提供支持
多年来,各组织一直致力于提高开发人员的工作效率以加速其业务发展。但是,仅关注开发人员工作效率可能会产生负面影响,例如倦怠、错误和保留率下降。
范例已改变。突出对话不再涉及开发人员工作效率或开发人员速度等结果,而是介绍如何使用开发人员体验(DevEx)以可持续的方式实现这些结果。
DevEx 不仅帮助开发人员编写代码,而且还可在针对编写代码进行了优化的环境中编写代码。
Nicole Forsgren, former Partner Research Manager at Microsoft
为什么 DEVEX 很重要?
优化 DevEx 可改善业务成果
衡量 DevEx
SPACE 框架简介
The SPACE framework offers a new holistic way of understanding and assessing the developer experience. “Productivity is about more than the individual or the engineering systems; it cannot be measured by a single metric or activity data alone... The SPACE framework was developed to capture different dimensions of complex concepts like productivity and developer experience.”
–Nicole Forsgren, Founder of DORA metrics and former Partner Research Manager at Microsoft
-
满意度: 开发人员对其工作、团队、工具或文化的满意度如何?
幸福感: 开发人员的健康和快乐程度如何?
示例指标• 开发人员满意度
• 留住开发人员
• 用户参与
• 倦怠
-
评估系统或进程的结果。由于变量太多,绩效很难量化。
示例指标代码质量:
• 可靠性
• 无 bug
• 持续服务运行状况代码的影响:
• 客户满意度
• 客户采用和保留
• 功能使用情况
• 降低成本
-
了解在执行工作的过程中完成的操作或输出数量。
示例指标
• 已完成的代码评审数
• 编码时间
• 提交次数
• 代码行
• 故事点已完成
• 部署频率
-
捕获人们和团队如何沟通和合作。
示例指标• 代码评审分数(质量或周到)
• 拉取请求合并时间
• 会议质量
• 文档和专业知识的可发现性
-
衡量开发人员和团队在工作中取得进展或者在没有中断或延误的情况下完成工作的情况。
示例指标• 开发人员保持在流程中并完成工作的感知能力
• 代码评审时间
• 流程中人员/团队之间的交接次数
• 中断次数
最新 DevEx 研究
了解如何帮助开发人员成长
DevEx 工具
用于优化 DevEx 的新式开发人员工具
使用开箱即用、协同工作的工具简化开发。
DevEx 快速检查
DevEx 成熟度快速检查
使用此测验来确定组织的 DevEx 成熟度并获得有关如何改进的指导。
-
如果为是:
移动到 02。如果为否:
了解开发人员的痛点是改进 DevEx 的第一步。建议的后续步骤:
针对开发人员运行一项调查,向他们询问以下问题:
- 工作中最困难的部分是什么? 为什么?
- 在思考开发工具和流程时,生产力的最大阻碍是什么?
- 如果你能更改团队构建软件的方式的一个方面,你会更改什么?
-
如果为是:
移动到 03。如果为否:
DevEx 是多方面的,因此需要一个多方面的框架来理解它,这就是我们发明 SPACE 框架的原因。它考虑了 DevEx 的五个维度: 满意度和福祉、绩效、活动、沟通和协作,以及效率和流程。若要评估 DevEx,建议跟踪至少三个 SPACE 维度的指标/KPI。
若要详细了解 SPACE 框架并查看每个维度的示例指标,请阅读研究论文。
建议的后续步骤:- 了解 SPACE 框架。
- 选择 SPACE 的三个维度来在组织中确定优先级(它们应该与开发人员的痛点相一致)。
- 为这三个维度中的每个维度选择或创建指标。
- 实现随时间推移跟踪这些指标的方法(例如,DevEx 仪表板),并使用它们来评估 DevEx 工作的影响。相应地调整你的方法。
-
如果为是:
移动到 04。如果为否:
请务必为每个指标定义明确、现实的目标。此外,这些目标应务必与开发人员的痛点保持一致。设置目标可能具有挑战性。有些人选择参考其他高绩效团队或公司的指标,有些人则参考行业基准。另请注意,目标可能会随时间变化,以体现持续改进。
若要详细了解如何量化 DevEx 的影响和可能的 ROI,请阅读我们的博客和研究论文。
建议的后续步骤:- 为每个 DevEx 指标设定了明确、现实的目标。
- 召开季度会议,以检查这些指标并查看你的 DevEx 进度。
- 根据你看到的影响,调整你的 DevEx 工作和投资。
-
如果为是:
移动到 05。如果为否:
改进 DevEx 的唯一方法是改进开发人员的工作方式。通常,这意味着投资于让开发人员生活更轻松或简化关键流程的工具。为了提高效率,建议使用已确定的指标来关注和跟踪 DevEx 改进工作。下面是指导 DevEx 投资的一些提示:- 消除工作流程中的繁琐工作。将“工作流程效率低下”列为首要工作挑战的开发人员感到工作效率低下的可能性是其他开发人员的 2 倍,寻找其他工作的可能性则高出 67%。要减少开发人员承担的繁琐工作,一种高效的方式是简化规划和工作管理流程并改进合规工作流程。
- 获取新式开发工具。这还可以减少工作量。GitHub Copilot 等新式工具可帮助开发人员将任务完成速度最多提高 55%,并减少在文档等日常任务上花费的时间。
- 安全左移。通过在软件开发生命周期的早期优先考虑安全性,组织可以在问题进入生产环境之前就解决它们,从而降低成本并节省开发人员的时间。新式开发人员工具可通过在代码创建期间扫描漏洞来帮助做到这一点。
建议的后续步骤:- 通过投资新工具或根据开发人员的痛点和你的 DevEx 指标来简化流程,开始改进开发人员工作的方式。
-
如果为是:
移动到“继续你的旅程”。如果为否:
有时,组织会犯下让开发人员对其 DevEx 负责的错误,但这并不公平,因为公司的工具链或流程的设计者不是开发人员,而是领导团队。DevEx 计划应由领导团队主导,其明确目标是改善开发人员的体验,并且领导团队应对这些计划的成功负责。
这并不是说开发人员不应该参与 DevEx 计划。这些计划旨在解决开发人员的痛点,因此当然应该在整个过程中咨询并邀请开发人员参与,但最终,应该由领导团队负责在组织中改进 DevEx。
建议的后续步骤:- 在领导团队中设立 DevEx 倡导者,引领 DevEx 工作的推进。
- 进行季度回顾,以检查你的 DevEx 指标并评估你的进度。
- 包括 DevEx 旅程所有阶段的开发人员,他们的投入是无价的。
开始
立即开始 DevEx 之旅
通过为开发人员提供融合 AI 能力的新式工具,加速业务发展并帮助开发人员成长。
观看 DevEx 网络研讨会
了解如何通过改进 DevEx 来推动组织中的业务影响。
使用 AI 提升 DevEx
了解 GitHub Copilot 如何跨 SPACE 框架的所有五个维度改进 DevEx。
获取专家帮助
如果希望获得 Microsoft 在 DevEx 优化方面的指导,请联系我们的销售团队,他们将为你联系适当的资源。