关注个人开发者的效率指标。DevOps说我们应该关注软件团队的成功。以下是如何做到这一点。
译自 Software Delivery Enablement， Not Developer Productivity 。
Anna Daugherty 认为，我们不应该过分关注开发者的效率。这在上周的持续交付小型峰会上是一个大胆的观点。
“这是我在峰会上与几乎所有人讨论过的一个话题，”Opsera产品营销总监 Daugherty 向 The New Stack 表示。
“个人尽最大努力和责怪他们效率低下之间存在差异。但效率本身没有意义，”她继续说。“个人开发者的效率是否通过代码提交来确定？他们在 sprint 中完成了多少？团队中的个人并不能单独创造产品。”
Daugherty 认为，效率指标试图回答错误的问题，您真正应该关注的是:
- 您的客户和终端用户是否看到了加速交付的价值？
- 开发者是否对自己的工作更满意？他们感到自己的潜力得到了更好的发挥吗？
- 您是否创造了更多收入和投资机会？
Daugherty 认为，正如DevOps寻求加快软件团队交付软件的速度一样，您应该关注软件团队的实现能力，而不是个别开发者的效率。
最常见的DevOps指标并不是真正的指标。她说，DORA更像是一个框架，用于衡量速度——通过变更引导时间和部署频率——和稳定性——通过变更失败率和恢复服务时间。
Daugherty 解释说，“DORA允许您制定一些指标，您的团队可以努力达到这些指标，或者这些指标被认为代表高绩效的团队。”“但它并不是终极答案。它不是唯一的标准。它只是高绩效软件团队可以构成的指标示例。”
对于关键指标，您可以采用2021年的SPACE开发者效率框架，或者McKinsey最近的开发者效率研究，她说这“既包含了SPACE又包含了DORA，以及它们综合在一起的其他一些无关内容”。
但真正重要的是保持简单。对 Daugherty 来说，这归结为询问您为什么要开发软件，这归结为三个目标用户群:
- 用户。
- 开发它的人。
- 市场。
虽然DORA和SPACE可以指导方向，但她说，您应该衡量那些有助于衡量这三个软件开发原因满意度的结果。
这有助于回答您交付的软件是否可用并让客户满意，她解释说。这可以通过净推荐值(NPS)、G2和其他产品评论网站以及客户推荐来评估。
您需要定性数据，即与产品用户的紧密反馈循环，以及定量跟踪，如流失率。
关注回答: 您的开发人员是否喜欢开发和发布软件？您有高水平的开发者疲劳吗？这就是平台工程发挥作用的地方，它可以提高开发者的实现能力和减少发布的阻力。这可以通过平台采用率、定期开发者调查及其后续行动计划、Glassdoor评价以及他们公开的社交媒体情绪来衡量。
您交付的软件是否帮助获取期望的市场份额？它是否创造了投资和合作伙伴关系的机会？它是否真正推动了销售渠道，创造了可衡量的利润？Daugherty 解释说，业务指标通过衡量诸如销售渠道、投资和合作伙伴关系等指标来评估。
一些公司似乎只关注业务指标。但 Daugherty 强调，随着科技行业从“不惜一切代价追求增长”转向“注重投资回报”，如何提高开发者效率并不是应该问的正确问题。
部分原因是业务领导层和工程团队之间存在根本脱节。
“业务领导层总是衡量收入和渠道，但这并没有传达给工程团队，或者没有以他们可以理解的方式翻译给他们，”她说。“他们总是纠结收入、渠道、合作伙伴关系和投资，但这真的应该是整个业务的全面对话，工程应该是一个重要的考虑因素，因为他们也是关键受众。”
事实上，工程往往拥有最高的薪资，这使其成为一个重要的成本中心。平台工程的早期目标之一应该是促进一种共同语言，企业了解工程的价值，而工程师了解他们工作与创造商业价值之间的联系。
尽管如此，许多组织在这方面还存在不足。Daugherty 说，这种持续的鸿沟有时可以通过首席数字官或首席转型官的混合角色来弥合。
软件交付实现能力和2023年的平台工程趋势，不会仅通过关注人员和技术本身就能取得成功。在大多数公司，流程也需要从根本上改造。
一个团队“要么在一个领域工作，要么必须交付某项功能，”她说。“他们是否一起工作以交付这件事？如果不是，我们需要做些什么来改进呢？”
Daugherty 说，开发者实现能力应该集中在团队成果层面，这可以通过四个关键能力产生积极影响:
- 持续集成和持续交付(CI/CD)
- 自动化和基础设施即代码(IaC)
- 集成测试和安全性
- 即时反馈
Accelerate 这本关于DevOps和扩展高绩效团队的标志性、以指标为中心的指南发现，某些经验证的决策可以帮助团队加快交付。
一项决定是，当团队被授权选择使用哪些工具时，这已被证明可以提高绩效。当被问及这是否与平台工程及其建立最佳实践相抵触时，Daugherty 评论说，这种思维偏离了对实现能力的关注。
“平台工程与指导您使用哪些工具无关。这可能是在某些组织中被简化的，但这不是最有效的版本，”她说。“你就像复仇者联盟中的奇异博士，你看到更大的画面，看到事物如何汇聚和互相关联。”
平台团队不应该采取严格的、孤立的思维方式，即这个团队使用这个工具。
Daugherty 澄清，平台工程的目标是汇聚人员、产品和流程，以提高所有团队的效率和效果。“这是否意味着有时选择更好的工作流程或技术和架构？对您的业务来说，也许。但是如果这是您的整个平台策略，那么这就是一种过于狭隘的思考方式。”
尽管存在不同的工作角色，她强调DevOps和平台工程是一种工作方式，而不是您做或不做的事情。平台团队的目标是跟踪DevOps无限循环，以使交付途径更顺畅，Dev和Ops之间的交流更顺畅。
“很多人告诉我:‘我不喜欢你这样的人，因为你告诉我需要使用这个工具，我需要这样做’，”她说。毕竟，Opsera是一个针对任何规模工程团队的统一DevOps平台。
但她总是反驳，“我不是来告诉你任何事情的。我是来帮助你开展你想做的工作，因为你的工作很重要。并帮助您向那些想从您这里获得更多的业务领导解释您所创造的价值。他们会不断要求您做更多。”
Daugherty 说，她的角色是帮助团队——并通过扩展组成团队的个别开发者——找到如何交付更多而不增加开发者疲劳的方法。
DevOps关注促进正确类型的交流，以提高速度和协作——而不是在过程中制造更多需要人工参与的障碍。
Accelerate 引用的研究发现，“报告没有审批流程或使用同行评审的团队实现了更高的软件交付绩效。需要外部机构审批的团队实现了较低的绩效。”
这并不一定意味着零审批流程，而是更多关注在团队单元内做出决策。Accelerate 继续建议“使用轻量级的基于同行评审的变更审批流程，比如结对编程或团队内代码审查，然后结合部署流水线来检测和拒绝不好的变更。”
Daugherty 解释说，这可能是一个ops驱动的自动审批，如基础设施即代码中，或是一个集成测试，或者是人与人之间的知识共享机会。
“代码在通过同行评审后，团队成员都认同可以交付，然后它会自动部署到生产环境，而不是在某个门槛或瓶颈处等待。如果在整个流水线中都有集成测试和安全检查，那就可以实现自动部署。”
同行评审流程既可以确保代码的可读性和可维护性，也可以促进非正式的培训。Daugherty 回忆了爱立信的主设计师Andrew Fenner在持续交付小型峰会上关于开发者体验和生产力的小组讨论时所说的话。
“爱立信是一家较传统的公司，所以他们能实现轻量级的审批流程算是一个奇迹。” Daugherty 继续说，Fenner 谈到，有时他们最资深的开发者大部分时间都在帮助较初级的开发者，而不是自己提交代码。如果用传统的个人开发者生产力指标来衡量这些资深成员，他们的表现会很差。但实际上，他们虽然难以量化的影响力每天都在帮助提高爱立信初级开发者的能力。这也意味着知识不会仅掌握在一个团队成员手中，而是在整个团队中共享。
“我说的轻量级是指不期望你的开发者随时都知道所有答案，而是让他们有一些简单快速获取反馈的机制。并利用你团队中最有知识、最乐于助人的人快速提供反馈，” Daugherty 说。“这种轻量级的理念非常关注不阻碍人们。他们部署到生产的能力越强，根据速度和稳定性，他们的结果也越好。”