为了最大限度地提高速度，CTO 们应该考虑一些「非传统」的指标，比如：

• 代码变更前置时间（ commit-to-deploy time ）
  
• 构建时间（ build time ）
  
• 排队时间（ queue time ）
  
• 测试覆盖率（ test coverage ）
  

这些指标可以让 CTO 们更清晰地了解他们的软件开发的路线轨迹，以及可能阻碍他们前进的因素。

但是，在了解这些指标含义之前，需要记得以下五个提示。

1研发效能度量前的必要知识

• 度量（即便不考核）会带来人的行为改变
  

• 这种行为改变既可向「好」，也可向「差」。
  

• 度量数据的自身质量是非常关键的
  

• 统计学说：garbage in, garbage out。
  

• 组织的研发效能度量需要结合具体上下文
  

• 指标项可以作为参考，但不可停止思考。
  

• 研发效能度量是有成本的。
  

• 很多组织流程并不具备度量条件。
  

• 仅有度量数据无法产生改善
  

• 必须应用度量数据来指导改善。
  

2五个重要的研发指标

1、代码变更前置时间（CDT）

代码变更前置时间是指：一次代码变更从提交到部署所需的时间，即Commit-to-Deploy Time。

在这两点之间，它可能会经历集成、测试和预生产测试，当然，具体经历哪几个阶段取决于你的组织流程。

测量 CDT 的目的是了解代码从部署流水线的一端到另一端需要多长时间，以及遇到了哪些障碍（如果有的话）。

在理想情况下，如果您已经实现了持续集成（CI）最佳实践，并且您有足够的自动化测试覆盖率，你可以在几分钟完成从提交到部署就绪的状态。假如恰巧系统是微服务架构，甚至几秒钟内完成这一过程。

但是，假如你的研发过程是一个很强地依赖于手工验证的过程，这很可能意味着 CDT 部署时间会长一些，也意味着你的组织流程还有改进空间。

大多数快速发展（ fast-moving ）的组织（如 Facebook 、亚马逊）每天部署数百次。

对较小的组织来说，「每日部署」是个很好的目标。

每个提交的变更越小，它们投入到生产环境的速度就越快。

一旦发现它们出错了，修复的速度也就越快……

你总会有出错的时候。

更频繁的部署也会让你的团队习惯于这么做，这也可能让团队会做得更好更快。

那么，如何测量 CDT 呢？使用「时间戳」。

对于每一次通过代码审查并合入的代码变更提交，记录它发生的时间。使用 git 意味着您可以免费获得这种粒度的变更信息。在部署方面，你也会做同样的事情。

注意：部署意味着你的用户可以看到或使用它。

CDT 实际上还取决于应用程序的规模和复杂性。

「少即是多」，你需要尽可能做一些改进来缩短这个时间。

这些改进可能更多是在技术方面的的改进（例如，我们的测试是不稳定的），或者是面向过程（例如，我们在应该使用单元测试的时候却使用了更为复杂的集成测试），或者技术或流程这二者的某种组合。

无论如何，您的目标应该是逐步缩短变更前置时间。

2、构建时间（Build Time）

构建时间实际上包括测试的运行，以及运行这些测试所需的任何准备工作。

这些准备工作包括创建一个测试数据库，在该数据库中植入测试所需数据，以及在测试套件之间设置/回滚数据库。这样么就不会污染不同测试所需要的测试数据。

和 CDT 一样，「好」的构建时间取决于上下文，但这个时间几乎总是越短越好的。

将相关测试放在一起可以防止不必要的 预置环节「Setup」和清理环节「 Tear Down 」。

浪费时间最糟糕的情况之一（但有些不可避免）就是 SRE 工程师和开发人员坐在一起等待测试完成。

这些测试的工作量越大、内容越全面，花费的时间就越长。

无论你把这些测试工作堆积得有多厚，你也只能看着拿着高薪的员工在那里被微博或朋友圈，或者无聊的GIF分散注意力，而不是设计或编码。

让我简单估算一下成本：

假如有两个开发人员在等待测试。

他们每小时都要支付50元（每年约10万元），

那么10分钟的构建时间将使您损失大约17元的生产率。

虽然缩短这10分钟似乎是一个根本不值得的很蠢的改变，

但如果每个开发人员每天运行五次这种类似的测试工作，

那么每周总计833元（每年43000元）。

如果应用程度很复杂，有些测试很可能需要一个小时才能执行。

除了这些明显的直接成本外，

还有难以量化的「丧失机会」的成本，即：

不能更快地进入市场的成本，

以及开发人员先等待，再开发的「心理转换成本」。

「CI 最佳实践」还建议先运行那些运行比较快的测试，并且一旦有错误出现，尽快发现它们，并取消构建，马上修复它们。

3、排队时间（Build Queue Time ）

比构建时间更微妙的是代码变更在执行构建之前的等待时间，即：Queue Time for Build。

这个指标高度依赖于组织的规模，以及同时并行开发的特性的数量。

然而，「在每次提交时运行构建」恰恰是开发人员应该做的事情，而这可能会进一步加剧排队时间。

长时间排队，成本是非常昂贵的。

虽然开发人员可以在另一个项目上工作，

但这也冒着失去刚所编功能上下文的风险。

如果他们并没有将注意力转到下一个工作项目上，

而是将注意力集中在等待测试的这次变更上，

那么，比构建时间更糟糕的是，如果工程师因为发现测试失败而中断了这次构建，这就让“最大构建时间”缩短；然而BQT不允许这样的捷径。

对于每一个要被测试的变更，应跟踪它从队列尾到队列头部所需的时间。这可以简单到让工程师记录他们在构建开始执行之前等待的时间。

尽量保持较低的排队时间，让工程师的工作可以持续吧

4、主干变红的频率（How Often Master Is Red）

主干（ Master ）是真理之源。

开发人员应把「主干」作为所有新工作的起点。

所以，如果主干 CI 变成「红色」，就意味着每个人都陷入了困境，因为没人能发布代码，整个部署流水线要戛然而止。

假如变红时，恰好有人要发布一个密钥安全修复的代码变更，他们不得不等到主干被修复。

在很多组织中，如果主干上的代码出现故障，可能需要几个小时才能修复。这不是你想看到的情景。

如果组织不关注尽快修复红色的主干，这表明了以下几点：

• 可能是测试套件不稳定或者测试不可靠，主干就很容易会变红。
  
• 代码库的测试覆盖率也会影响主代码变红的可能性。
  

• 不良的测试覆盖率会导致构建失败。
  

• 长期存在的特性分支很可能会因最后的合并冲突而失败。
  

• 变更集合越大，你的代码就与其它地方的代码差异越大。
  
• 帮助避免这种情况的一个 CI/CI 原则就是：每次提交少量变更，而不是进行「大爆炸式」的合并。
  

让主干处于不良状态也可能仅仅表明了开发实践或开发文化不好，即：对于「在第一时间修复主干」，你的组织可能没有足够的紧迫感。当主干变红时，它为代码提交造成了瓶颈，让修复时间变长，而且让开发延迟了。

持续交付的一个原则是强调始终保持软件「绿色」，即：软件一直处于可部署状态。

如果它不是绿色的，你在它坏掉的那一刻就应该修复它，而不是让它流连忘返。

无论谁破坏了它，都应该全心专注于修复这个问题，如果需要，还可以从其他团队成员那里获得帮助。

这与看板方法中的「红色按钮（安灯）」类似，即：

任何人都可以而且应该在发现缺陷时按下红色按钮，以便尽快修复问题。也就是说，一旦按下红色按钮，每个人都需要尽快让「装配线」再次启动。

你如何衡量这个呢？

每次主干变红时，启动一个累积计时器。将这个数字除以今年迄今为止的剩余时间。这是主干花费在「红色」的时间百分比。要获得更详细的信息，您可以按月或按天细分。或者计算从红色回到绿色的平均时间。

让主干保持绿色就是为了防止瓶颈和保持公司的敏捷性。

5、工程开销（Engineering Overhead）

工程开销包括员工人数，以及一些工作支撑相关的花费，如购买软件 License 和 AWS 等，当然，也包括这些工具的维护成本。

虽然很多 CTO 会跟踪每个工具的席位成本，但他们并不关注配置、维护或监控这些工具需要多少时间。

• 你的工程团队中是否有人主要负责维护每个人都使用的工具？
  
• 工程师在这种类型的流程工作上花费了多少小时而不是构建功能？
  

如果一个工具需要一直花费大量时间和精力才能发挥其功能，你可能需要重新评估它的价值。

工程师花在工具上的时间减少了他们花在产品上的时间。

工程师希望使用最好的工具：不要以牺牲基础设施或工具的质量为借口。

3还有其它指标么？

以上就是 CTO 应该知道的五个较大的非传统指标，

但为了确保保持竞争力，还应该回答以下几个问题：

• 开发人员每天向主干合并多少次？
  
• 代码库多久处于可发布状态？
  
• 代码测试测试覆盖率是多少？
  
• 是否优化了我的工具和基础设施？
  
• 通过替代工具（基础设施解决方案）的潜在速度增益和节省是什么？