一提起度量，各家都是满腹苦水。在推动 DevOps 的过程中，为保障产品或项目质量，质量度量往往被视为通用的考核方式，受产品、项目、开发阶段、行业属性、企业文化的影响，度量指标构成都有所不同。本次闭门会议，嘉宾也对所属企业的度量质量建设以及面临的问题进行了讨论。相比理论，实际工作中，一方面产品、项目很多内容难以被量化，另一方面即使定义清晰的指标，由于“人”的参与，会被过分关注，再加上度量往往和绩效关联，这让度量变得愈发敏感与复杂。
会上，大家也分享了一些优质实践。
由于每个团队的能力水平不同，建议在团队正常运行半年后，再设立团队考核指标的基准。提倡自我纵向对比，不暴露和批评差的团队，通过趣味、奖励等方式鼓励大家提升整体的产品质量。
在过程中，可以通过逃逸、质量事故进行度量。在研发阶段，主要以低级质量缺陷为依据，再通过提测打回率、缺陷密度、漏测率等综合指标评判代码质量。
度量指标的制定应该结合业务价值、测试及需求覆盖率等关键因素，并划分优先级。为避免副作用，不建议单独地以局部指标为考核标准，度量指标应整体综合运用。
其实，度量的最终目的是服务产品、项目和客户，带来全局的正向改变。因此，希望大家以终为始，不要盲目做度量。
通过大家的交流我们发现其实每个企业对于 DevOps 都有不同的理解，也正是这样，各行各业围绕 DevOps 催生出一系列优质的实践。相信借助 DevOps 的力量，企业将在数字化时代实现更高速的发展与更大的业务价值。