2012年8月28日星期二

Scrum迭代中的质量标准

Scrum迭代中的质量标准

       在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,但是因为现阶段的重复代码的存在,所以制定上翻了一倍左右。)这样按照预言的研发天数进行需求文档的质量约束。


TAG: