为什么要度量指标？
度量在很多企业里落地的效果并不好。一是因为度量的前提是要有一套打通端到端的 DevOps 平台，否则再优秀的度量也只是局部度量。目前国内很多企业还都处于建设 DevOps 平台的基础阶段，因此落实下来也并不容易。二是，度量本身投入产出比并不像 CICD 效果明显。很多工程只是为了“给上面看看”而完成的任务，并没有从度量的本质上去考虑。
因为这两点原因，度量指标在企业内的落地还存在问题。
我认为“有哪些度量指标”“指标如何获取”这些问题是我们从一开始就要考虑的。原因有以下几点：
- 精益思想的核心理念是持续改进，只有清晰明确的度量指标作为指引，才能达到持续改进的目标。在持续改进这条路上，没有终点，永远在路上。
- 度量能够提供信息来帮助我们知道现在在哪里，距离目标还有多远，我们是在沿着目标前进，还是在倒退，程度如何。
- 度量指标是需要从 DevOps 平台获取的，一开始要考虑有哪些度量指标，如何获取，对 DevOps 平台的设计有指导意义。
这样要强调的是，度量指标不是目的，而是手段；不是控制，而是改进。“目的”容易给人以到达终点的错觉，“手段”是为了发现潜在的问题。“控制”容易给人以一种静态目标的心理暗示，“改进”则是以动态目标植入人心。这有助于我们能够不断地发现问题，改正问题。
什么样的指标是好指标？
关于寻找度量指标这块，在有些企业里都有一个误区，就是要“度量所有内容”。一些企业拍脑袋要度量几百个指标，以期望能从这么多的指标中找到一些重要信息。这种方式是不正确的，有以下几个问题：
- 更多的指标需要投入更多的资源来关注软件研发的各个方面，最终会导致每个指标的效果并不好；
- 以 KPI 的形式完成指标，最终完成的只是数量，不是质量。
那么，度量指标的质量是什么？什么样的指标是好指标？下面这 5 个标准希望能够帮到你。
- 可度量的：指标必须是可衡量的，即是一个定量的指标，而不是“非常好”，“非常快”这种定性的指标。
- 相关联的：指标必须能够度量对业务有重要影响的因素。
- 不可更改的：团队成员不能影响度量指标的结果。
- 可实施的：指标是能够通过技术的手段获取并且数值是真实可靠的。
- 可追溯的：指标必须是能够直接反映软件研发过程中存在的问题。
因此，我们不可能度量所有的指标，要选出哪些满足这些要求的指标，指标不在多，而在精。在找出要跟踪的 DevOps 指标之前，需要确定组织面临的挑战以及要解决的问题。好的指标是用来解决实际业务问题的。因此，应该避免那些不符合 DevOps 时代、对用户没有价值的指标，比如以下几点。
- 传统的工程指标：比如 MTBF（平均故障间隔时间）在 DevOps 时代意义就不大。系统的长期稳定性并不是首要目标，因为 DevOps 时代是通过快速部署来保证系统的稳定性的。基于虚拟化和基础设施即代码的工程实践，可以通过频繁的部署来进行线上测试，这些测试可能会经常失败，但有利于制定更好的方案。这种情况下，MTBF 对业务需求来说并不是好指标。
- 基于竞争的指标：切勿基于团队成员或团队之间的竞争来建立指标。比如按团队成员完成的需求数量进行排名、按开发人员出现的 Bug 数进行排名等。度量指标的目的是用来解决业务问题，不是用来晾晒团队成员技术水平的手段。
- 虚荣性指标：比如每周代码行的统计。不应该以代码行数这样无意义的指标评判开发人员工作量的指标。最终交付功能的及时性和质量才是最重要的。
在度量指标的时候，不要根据获取指标的难易来取舍指标。在一项重要的指标上哪怕花费更多的成本都是值得的，在一项无用的指标上投入再少的时间也是在浪费。
如何选择指标？
好的指标是用来解决问题的。当我们在选择指标时的依据也是要解决的问题。在软件开发过程中，需要解决的问题很多。代码质量、团队成员、发布效率的等都有可能成为问题的来源。这些指标中，有些是给上层领导做决策用的，有些是为了提升团队技能水平的，有些则是为了提升软件质量。不管用途是什么，衡量的标准就是解决或改善现有的问题。我举了下面几个例子。
- 缩短产品上市时间：用于衡量从用户需求被提出到最终交付给用户之间的时间，可以使用“前置时间”这个指标。因为更短的上市时间代表了企业在市场竞争中的反应速度越快。
- 提高软件开发的效率：可以使用“流动效率”这个指标，以查看瓶颈点，并将工作重心放在如何改善流动瓶颈的地方。等待的时间越少，软件开发的效率就越高。
- 解决团队正在处理的事项和计划外事项的冲突：可以使用“在制品数量”这个指标，以暴露工作内容过载的团队或团队成员，使得每个团队成员的工作更加均衡。
- 解决未完成的重要工作不被遗忘的问题：可以使用“停留时间”或“过期时间”等指标，来度量未完成的工作在系统里停留了多长时间，如果超过设置的阈值则进行预警以暴露风险。
- 减少生产环境中用户发现的问题数量：可以使用“缺陷逃逸率”这个指标，争取尽可能多的 Bug 是在测试环境或预生产环境中发现，以最大程度建设用户发现的缺陷数量。
如何使用指标？
当根据上面的标准选择好指标后，应该如何使用这些指标？反馈循环是有效改进的基础，通过度量指标的反馈，有助于更加精准的调整团队的行动，改善整个组织的沟通。下图是度量指标的反馈循环，需要有以下几个步骤：
STEP 1：收集数据。
收集关于软件研发过程中的数据，作为后续分析的原材料。在大多数企业，度量面对的问题不是数据准不准确，而是有没有数据的问题。如果要有效地收集数据，需要从两个方面入手。
- 平台方面：平台本身需要具备收集数据的能力。在设计平台时，要有针对度量指标方面的设计。比如每个任务都要有开始时间和结束时间，每个事件都应该有发生、处理、解决的时间记录，事物之间的关联（如代码提交与任务或缺陷的关联，代码库与产品线的关联，流水线构建与代码库的关联等）。平台具备收集这些数据的能力外，还可以提高统计报表，用更直观的方式进行展示。
- 人的方面：团队成员的有效参与能够充分发挥平台的能力。DevOps 平台中，虽然将研发流程中的操作尽可能自动化了，但有些内容还是需要人工配合。比如：在提交代码时按照规范提交，将需要关联的需求 ID 和缺陷 ID 添加到 message 里，从而建立提交的代码与需求和缺陷的关联。需求的拆解，任务的启动、过程跟踪以及完成后的关闭操作，都需要人工配合，才能使数据更加准确。
STEP 2 ：分析数据。
基于收集的数据进行分析，以便能发现当前存在的问题。举个例子，通过数据收集系统发现：需求完成的数量在减少，代码行数在增加，同时缺陷的数量在增长。下面通过这些数据进行分析：
- 需求完成的数量减少，说明团队花在需求上的时间减少了，是什么原因导致的呢？继续往下分析。
- 代码行数在增加，说明团队成员花费大量的时间在修改代码上。既然完成的需求在减少，可以断定代码不是为开发需求而写的。
- 缺陷的数量在增加，可以说明当前在测试阶段，并且测试出了很多问题。
通过分析得出结论：说明软件进入到测试阶段后，问题很多，导致团队成员需要花费大量的时间修复缺陷，从而影响了正常的需求开发。
STEP 3：调整流程。
根据上面的分析判断，开发人员在开发阶段对软件质量的控制效果并不好，可能的原因有：
- 开发人员没有进行有效自测；
- 开发人员没有编写单元测试或者覆盖率较低。
因此，我们可以采取一些措施改善流程，尽早发现软件中的问题。比如在持续集成流水线中集成单元测试，通过设置门限阈值来控制单元测试的有效性和覆盖率；通过自动化的API接口测试，验证服务以及服务之间调用的正确性等。
STEP 4：重复执行。
重复上面的步骤，再次收集指标，观察指标的变化，并根据指标的值调整流程，直到满足要求。
