什么是软件工程指标

软件工程指标是用来评估、跟踪和改进软件开发流程、产品和团队的质量、效率与影响的定量度量。用得好，它们是一种系统性的诊断工具： 揭示运营瓶颈，为偿还技术债务提供依据，并让工程活动与具体的业务成果保持一致。用得不好，它们会扭曲行为，损害信任，并恰恰奖励错误的东西。

这本书之所以存在，是因为大多数团队在决定指标用来做什么之前，就先伸手去拿指标。仪表盘被所有容易计数的东西填满，领导层开始问“这个数字是涨了还是跌了”， 而不出一个季度，团队优化的就成了数字本身，而不是数字本应代表的成果。这种失败有个名字：古德哈特定律。 当一项度量变成目标，它就不再是好的度量。本书的每个主题都是在这条定律的背景下写成的。

两个基础框架

业界在衡量工程交付和团队健康方面，大体上汇聚到了两个以研究为基础的框架。

DORA 指标（来自 DevOps Research and Assessment 项目）衡量系统的吞吐量和稳定性： 部署频率、变更前置时间、变更失败率，以及从失败部署中恢复的时间。本书第 2 部分在一个专门的参考主题中讲解这四项，并配合流动框架（Flow Framework）使用， 后者用来更广泛地组织交付与流动指标，因为 DORA 能很好地衡量流水线的机制，却不说明流经其中的是什么样的价值。

SPACE 框架由微软、GitHub 和维多利亚大学的研究人员提出，它从五个维度，用开发者体验来平衡原始吞吐量： 满意度与幸福感、绩效、活动、沟通与协作，以及效率与流动。第 3 部分对它做了深入讲解。

在这两个框架之外，团队还会跟踪按领域分组的本地指标：代码与质量指标（第 4 部分）、产品与业务指标（第 5 部分），以及可靠性、运维与安全指标（第 6 部分）。 第 7 部分讨论已经在发生的转变：生成式 AI 工具让原始代码产出几乎免费，这意味着业界依赖了十年的某些指标，已经不再代表它们过去代表的意思。

这本书写给谁

主要读者是决定团队衡量什么以及为什么衡量的人：工程负责人、Staff 与 Principal 工程师、平台与 DevOps 团队，以及第一次搭建指标仪表盘或记分卡、 或者要修复一个已开始扭曲行为的仪表盘的项目与产品经理。次要读者是所有想弄明白自己的组织为什么要跟踪这些东西，以及当指标被滥用时如何提出异议的工程师。

如何阅读

从这里开始，然后阅读导言了解本书的组织方式，或者直接跳到目录。 每个主题都自成一体：它先陈述原则，给出具体建议，点明所讨论的指标会如何被操纵，最后以成熟度模型、讨论问题和参考文献收尾。你不必从头读到尾才能从中受益。