效能度量平台

目录

一、背景

二、开发度量指标

 需求设计质量

研发过程质量

用户使用质量

三、研发效能平台指标解读

度量指标

四、度量平台架构

五、平台开发度量样例

六、度量指标后端接口开发 

七、度量指标平台化

八、质量度量要注意哪些方面？

一、背景

  为了提升研发部各部门或各业务线的研发效率和交付质量，我们开发了效能度量平台。没有度量，就无法高效的管理。

二、开发度量指标

我们谈软件质量，不可避免要从它的源头说起，而源头就是需求和设计阶段要做的事情。这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物，当然他们有一定的前后依赖关系。

 需求设计质量

在需求设计阶段，我认为比较重要的有如下几点指标：

•  需求评审通过率（是否有遗漏、描述不清、存在逻辑漏洞等）； 
•  设计评审通过率（设计是否满足需求要求、是否合理美观友好）；
•  方案评审通过率（方案实现难易程度、可测性、是否需要更多资源）；  
•  用例评审通过率（场景是否尽可能覆盖、和技术方案实现是否吻合）；

注意，这里我提到的都是评审，为什么要做大量的评审工作呢？因为如果源头存在问题，那么研发过程和后面的用户使用质量，就无从谈起。方向错了就全错了。
评审的价值在于从用户使用场景角度出发，通过评审提问，把需求逐步澄清并形成验收条件，产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。

研发过程质量

软件质量是构建出来的，不是测试出来的。测试的本质是验证研发交付的产出物是否达到需求设计及预期的标准。并不能直接带来质量的提升，只能通过种种手段多维度的去验证是否达标，并通过流程规范、度量标准等去保障最终的交付物达标。
因此，我们常说的各种测试技术手段，都是验证和保障交付质量的手段，而不是构建质量的手段。当然，开发有自己的一套体系，比如编码规范、单元测试覆盖率等，这里不做详细描述，我们重点关注测试维度。

在研发过程阶段，我认为比较重要的有如下几点指标：

•  提测准时率（便于评估进度、资源投入和风险）；
•  构建成功率（构建成功率很大程度能反映出研发提测质量。如果经常编译构建失败或自动化测试通过率较低，因为这意味着最基本的需求实现出了问题）；
•   缺陷收敛率（反映缺陷在研发过程阶段的变化趋势和缺陷修复的时效性问题。一般在测试阶段的中前期即单测&集成测试阶段会暴露大量缺陷，到系统测试和回归阶段缺陷就应该有明显下降和收敛，降低产品验收和交付风险）；
•  缺陷reopen率（问题修复可能会带来新的问题，reopen指标可以从一定程度上评估缺陷修复的质量。如果reopen率比较高，那么很可能研发侧出现了问题，需要引起重视和寻找原因，尽快解决）；

用户使用质量

用户使用质量，指的是软件线上发布后，我们对用户使用过程进行追踪并采集数据进行评估度量的过程。常见的度量指标有：

•  线上缺陷逃逸率（线上发现的缺陷）； 
•  线上问题留存率（线上发现的缺陷留存时长，可以用来评估修复的时效和对线上质量的重视程度）；
•  用户反馈建议量（这里仅针对的是用户针对功能的反馈或者客诉，不包含业务活动的范围）；

三、研发效能平台指标解读

度量指标

指标定义：按交付效率和交付质量来分类。

四、度量平台架构

五、平台开发度量样例

以QA部门为例：

六、度量指标后端接口开发 

 按照需求文档，对度量指标进行后端开发：

七、度量指标平台化

八、质量度量要注意哪些方面？

质量保障是一个体系化和长期建设的过程，而质量度量作为最重要的一环之一，在落地过程中需要持续跟进和优化。从我个人的工作经历和实践出发，我总结了下面几点，供大家参考。

•  质量保障不仅仅是QA同学的事情，因此质量度量也不能只关注测试维度；
•  度量指标需要根据团队特性和业务具体情况来制定，并且需要评估是否合理，而不是强行制定强行执行；
•  质量度量是为了保障最终交付质量能更好的满足用户需要，进一步达成业务目标，而非为了度量而强行度量；
•  质量度量并非一蹴而就，在软件不同的生命周期和团队成熟度阶段，度量的范围和执行严格程度要灵活变通；