《Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations》
使用专注于结果而不是输出的衡量指标。
使用针对全局或整个团队成果而不是局部或个人成果而进行优化的衡量指标。- 代码行数
将代码行数作为生产力衡量指标违反了指导原则，因为这样关注的是产出而非成果。
它只衡量了人们做了什么（代码行数）——通常是因为这样做更容易——但通常忽略了真正的目标，
因为目标难以表达和衡量。但目标不是我们应该真正关心的吗？- 速度
将速度作为衡量指标是源自敏捷运动——问题被分解为故事（story）点数，然后开发人员为故事点数分配相应的工作量。
在截止工作时，完成的故事点数就是团队的速度。但是，这只是团队的容量规划工具。
使用速度作为生产力衡量指标有几个不足:
首先，速度是一种依赖于团队的度量，具有相对性。团队通常具有不同的背景，所以在团队间进行速度比较并不合适。
其次，当速度被用作生产力衡量标准时，团队很可能会做出一些与事实不符的事情：
他们会夸大他们的估算，并想尽可能多地完成故事点数，疏于与其他团队合作
（这可能会降低他们自己的速度并加快其他团队的速度，反而会让他们看起来很糟糕）。
这不仅会破坏速度原本的意义，还会抑制团队之间的协作。将速度作为生产力衡量指标也违反了指导原则，因为它更关注局部指标而非全局指标。
为了优化自己的速度，团队通常不会与其他团队合作。
这通常会导致组织采用次优的解决方案，因为他们没有关注全局指标。- 利用率
将利用率作为生产力衡量指标违反了指导原则，因为它侧重于产出而非结果。它还侧重于个人而非全局。
这让我们看起好像在压榨员工，实际上，我们正把自己推向无法完成任何工作的境地。” Accelerate “一书把我们在软件开发和交付方面使用的度量叫作软件交付绩效。
它可以分为两个类别，每个类别包含两项指标：- 节奏
交付周期：从提交代码到代码在生产环境中成功运行所需的时间。
部署频率：团队部署代码的频率。- 稳定性
恢复服务的时间：当服务发生服务事故（例如计划外中断、服务损害）时，恢复服务通常需要多长时间。
变更失败率：他们对主要应用程序或服务做出的变更有多少（百分比）会导致服务降级或随后需要进行修复
（例如导致服务受损或中断，需要修补程序、回滚或补丁）。这些衡量指标既是面向结果的指标又是全局的指标——也就是说，
它们专注于让软件对组织和客户产生价值，而不是把注意力放在无法给整体目标带来帮助的局部问题上。我们发现节奏和稳定性可以放在一起实现，高绩效企业在两个方面都表现良好。我们的研究发现，通过关注这些指标可以提升组织绩效，高绩效企业可成倍实现盈利能力、生产力和市场份额，以及效率和客户满意度。“质量”——无论在什么样的背景下——通常都是一种良好的生产力衡量标准，因为它侧重于全局指标和结果。我们发现，在新工作、计划外工作或返工以及其他工作上花费的时间在高绩效者和低绩效者之间存在显著差异。
高绩效者要提升质量，因此必须花更少的时间来修复错误。