为了最大限度地提高速度,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 应该知道的五个较大的非传统指标,
但为了确保保持竞争力,还应该回答以下几个问题:
- 开发人员每天向主干合并多少次?
- 代码库多久处于可发布状态?
- 代码测试测试覆盖率是多少?
- 是否优化了我的工具和基础设施?
- 通过替代工具(基础设施解决方案)的潜在速度增益和节省是什么?