在Scrum迭代过程中，比较看重的一点是最后的验收质量，迭代是滚动的，如果迭代的质量不达标，就会导致质量债一直存在，这样就会像滚雪球一样，逐步积累起来，越来越大，最终导致Scrum只有形而已，而不是真正的敏捷。因为不能在任意阶段拿出可以发布的产品。

　　而产品质量这个词汇，又是一个比较虚的词汇，谁也不能保证产品没有bug了，谁也不能说产品的质量到达一个什么地步了。另外一点就是在Scrum迭代过程中存在着三种角色，产品经理，研发，测试。在高质量的敏捷素质要求里面，要求后两者合二为一了，成为一个全能人才。但是很多公司里面，研发和测试还是割裂开的。那么这三个角色之间也会面临着质量诉求，研发要求产品经理的输出是在合理的质量范围，而不能在研发，或者测试的过程中发现问题。测试对于研发的质量输入也是有一定的要求的，不能出现太多的低级bug。这样就面临了一个质量标准问题。

　　最早的时候，是由上游说了算的，需求人员把文档交给程序员，告知完成了，程序员研发完成告知测试人员写完了。因为没有约束，所以导致质量不是很好，测试人员总是抱怨质量太差，测试的都是低级错误。后来进行实践，做过checklist（自检列表），然后根据测试的反馈进行了调整自测列表，但是即使这样，测试人员的满意度也不是很高，认为研发的输出质量依然不是很高，导致测试这边的压力很大。另外一点就是，公司里面的测试人员的配比很低，只有8：1或者10：1的比例，这样也要求研发的输出质量要高一些，避免上一个迭代的测试还没有完成，下一次的迭代输出就已经到了。导致测试永远都是瓶颈，也是压力最大的人员，也避免作为最后的一道屏障因为前面的输出质量太差，而纠缠在普通的bug上无法自拔，导致质量水平偏低。

　　针对上面的这些问题，参考了对日软件的经验和标准，制定了一套Scrum迭代内的质量标准。在公司的研发体系内，Scrum迭代内包括以下内容，详细需求，研发，测试。这样根据本次迭代的条目挑选出详细需求，进行研发，成果进行交付测试人员测试。三个过程都进行了约束，制定了质量标准。按照之前的经验，约定Scrum迭代内的质量标准为16Bug/KL（每千行代码16个bug），约定详细需求为4Bug/KL，设计+CD为7Bug/KL，测试为3Bug/KL。

　　约定了这个标准之后，要求研发人员需要找出详细需求4Bug/KL，研发后研发人员需要测出7Bug/KL的标准才能交付给测试人员，测试人员必须测试出3Bug/KL之后才能认为本次迭代结束。因为需求文档还没有对应的代码行数，于是根据研发时间进行估算，按照50L/D的天数进行计算。（按照生产性来说，应该是20L/D，但是因为现阶段的重复代码的存在，所以制定上翻了一倍左右。）这样按照预言的研发天数进行需求文档的质量约束。

　　关于质量标准，不同的人给与了不同的看法，在这里根据大家的一些反馈进行一些补充。

　　1、全能人才的Scrum团队实际上也需要一个质量标准进行把关，只是需要汇总前面的研发bug数和测试人员的bug作为一个质量标准进行验收。

　　2、不同人员的能力不同，导致的质量目标是不尽相同的，但如果把这个质量标准放在一个团队内进行考量的时候，个体的偏差就会变得比较小了，这个时候，可以根据质量标准进行衡量整个迭代的质量，而不是个体的质量。另外就是，如果项目属于中型项目的话，也可以使用模块级别来衡量，也是可以消除一定的个体偏差，使用质量标准来进行决定是否达标。

　　3、前面的质量标准只是一个参考值，并不是一个恒定不变的值，是用来借鉴的。尽信书不如无书就是这个道理，每个团队可以根据自己的实际情况进行衡量，适配，初步的时候，可以使用这个标准进行参考，后面根据每次的反馈进行调整这个值。另外就是，这个标准也可以在Scrum的大迭代周期内进行调整，根据每次迭代的内容进行一定量的调整还是必要的，比如这次迭代主要是算法，以及框架部分，可能代码量不是很大，这个时候为了更好的保证质量，每千行的bug数可以适当的调高。根据情况，灵活使用，这样才能更加的适配实际情况，更能符合现实。

　　4、关于自动化测试部分，实际上是后期质量保证的一部分，并不属于质量标准的部分。所以没有涉及到相关内容。