话题源于一位同事的提问：你认为用什么质量指标可以反映项目交付的一个质量？粗看之下有点蒙，质量指标，什么鬼？再思考一下，哦，原来是说交付质量的事，那不是有很多质量指标么？多数和BUG相关，例如BUG数量、Reopen BUG数、BUG解决时长等等，好像都能体现交付质量啊。仔细想想，草率了，我们衡量交付质量，不能只看这些，质量不应该简简单单地缺陷关联上就可以了。再想想，于是有了本文。
研发过程质量
既然不能只看结果，那我们就从源头开始看起吧。首先是需求质量，想要最终的交付质量高，那么源头的需求质量就不能太低，否则后续的研发活动做得再优秀，也不算好，很有可能一开始就跑偏了。我们需要在需求评审的阶段，从用户使用场景的角度出发，通过提问，把需求逐步澄清，并形成验收条件（以实例化的形式记录下来），产、研、测三方共同确认，形成共识，以保证大家对需求的认知不发生偏差，为后续团队正确的做事提供有价值的指导。根据用户故事的基本特性，做到业务可验收、研发可实现、测试可验证、部署可交付。
再来看看研发过程的质量体现，对于代码质量，开发自有一套玩法，这里不细说。我们主要从更宏观的角度来看，个人认为有两个指标需要关注：构建成功率和缺陷趋势图。
构建成功率能很大程度上反映研发的提交质量，如果经常性地编译失败或者自动化测试不能通过，那么就需要引起重视，尝试去了解原因并找出解决方案，因为构建失败意味着最基本的业务保障都出问题了。
缺陷趋势图可以很好地反映缺陷的整体变化趋势和处理缺陷的时效性问题。如下图，大体上可以看到迭代缺陷的变化过程，缺陷在迭代中期被集中消灭得比较多，没有拖延到迭代后期，有利于测试的回归和其他方式的验证，降低风险。
再来看看交付给用户的质量评估，这里主要提两个维度：交付时长和缺陷存留。交付时长体现了团队的交付能力，是否可以在用户期望的时间内完成交付，如果时长太长，用户的满意率下滑，你很难说本次交付的质量很高。因为最终评估标准是用户用上了，才能算好。
再来说说缺陷存留。曾经遇到过一个版本，遗留了30多个问题，测试报告也写测试通过，然后发布上线。虽然那些问题都是小问题，但是这么多的遗留问题，如果让用户遇上了，那会产生什么样的糟糕体验？我们可以允许有部分问题延期到下个迭代修复，但总要有个底线吧。
用户使用质量
如果仅仅从研发团队的角度来看，上面的那些指标好像也够了。但是，我们常说以终为始，交付增量功能并不是我们的终点，用户的使用才是迭代交付的终点。所以我们在评估团队交付质量的时候，也要把这方面的指标加上。
线上缺陷逃逸率：指的是线上发现的缺陷。不论你的研发过程再优秀，如果线上缺陷被较为轻易地发现，我们也很难说交付质量很好吧。虽然可以找很多的理由，但还是希望能够避免类似的情况出现。
用户反馈：这里指的是用户的真实反馈，有机会去听听用户的心声。不要总是自我感觉良好。如果用户反馈使用很不方便，或者难以接受，那么我们的交付质量也不可能太好。这点可以和前面提到的需求质量相关联，因为这是需求质量的最直观体现。
数据埋点：如果说用户反馈过于主观，那么必要的数据埋点，有利于我们更加客观地去分析交付质量，比如改版前后比较，新功能的点击率，关键路径转化率，错误率，等等。如果你迭代的功能没人用，谁会比较尴尬呢？要注意的是，埋点数据可能会有延迟，参考这类数据时，可以把时间线放长一些。
非业务特性指标
理论上来说，上面那些指标，已经能够比较客观地反馈出迭代的交付质量了。但是在敏捷的场景下，时间短，任务重。有些在瀑布模式下比较注重的东西被忽略了，那就是非产品特性的质量。最典型的，就是可维护性和可扩展性。在瀑布模式下，我们会比较关注这两类的问题，因为交付时间长，如果不注意，后期的运维难度会很大。而在敏捷的环境中，因为交付任务重，加上敏捷提倡重构，所以研发对于代码的维护性和可扩展性并不会考虑太多（都想着会重构，但往往都没有重构的时间），在迭代中也没有预留相应的时间做技术债务的偿还，日积月累，屎山代码就慢慢产生了。
小结
以上，从三个方面讲述了关于团队交付质量的一些个人思考。作为研发侧的人员，我们更多的可能关注的是过程质量，如果你对代码或者研发有些追求的话，还需要关注非业务特性的交付质量。对于结果质量，看团队的追求吧。
源自公众号 CKL的思考空间