软件交付效能度量——从吞吐量和稳定性开始

除了感性的工作体验外，我们还需要指标来度量改进措施是否对提升软件交付效能有帮助。过多的指标会对团队造成不必要的管理成本，也容易让团队失去关注焦点。从吞吐量和稳定性两个维度考量的四个关键指标是简单但有效的指标，建议优先度量。

为了提升软件交付效能，你的团队或组织可能已经开始采取行动，引入敏捷方法、DevOps实践甚至还有架构重构。但你如何知道这些改进措施起了作用呢，或者它们压根就水土不服呢？简单来说，除了感性的工作体验外，你需要一些指标来度量交付效能。

唯快不破

提升交付效能的最重要的目标之一就是能"快起来"，那么如何定义"快"呢？我们更倾向于度量吞吐量，吞吐量是指单位时间内团队完成的工作量。

• 变更前置时间

Lead Time for Changes，变更前置时间指的是开始编码到部署所耗费的时间。如果变更前置时间过长，可能意味着开发或部署过程的某些环节出现了问题或阻碍。这是一个典型的吞吐量指标，更强调的是对于单个用户故事/用例需要花费多长时间才能获得实际反馈。

我之前受邀参与某个项目，当时团队的直观感受是进度滞后。通过度量变更前置时间，我们发现用户故事从进入"开发中"到"准备QA测试"(意味着开发同事已经完成了开发并按照验收标准进行了自行验证)的中位数时间是4.5天，这意味着近一半的用户故事在一个工作周内都不会得到有效的反馈，而在一周之后往往可以"惊喜"地发现实现方案有问题，需要返工。