过程改进日记之学习Scrum2010-9-27：避免测试阶段的黑洞

直到今天的立会后，我才反应过来今天是Sprint3最后一天，燃尽图上最后的8Day全是测试任务，Unplanne倒是很多，那开发人员都在修改bug。

昨天的立会中，某工程师是这样介绍他的工作的：“昨天修改了一些bug，今天还要修改些bug”，集体厥倒

 

在传统模式中，系统测试阶段，大量的工作就是围绕Bug讨论、修改、验证，中间会插入一些调整UI的活动，从我们目前的情况看，这个并没有多大改善，这应该是前期测试还不是充分的，当然我们现有的能力和实践都还不够。

 

这两天的立会，墙上也没啥任务可以移动，都是测试这边先把昨天的情况讲一下，然后开发工程师口头承诺下大概会修改哪些，但这个承诺有些同学比较含糊，常见的句式包括“我去看看某类问题”、“怎么你这边会Crash”、“我会去问一下底层库这边”。

 

这是一个问题，没有任务，则工作无法明确，而测试人员也不能更精确的了解次日将会有哪些问题可以验证，按照QPM的话：“现在Build的频率高了，但解决问题的效率并不高”，而开发这边有可能在修改bug的过程中目标偏离，比如甲修改Bug N，发现某段关联代码有些地方可能逻辑不合理，然后他去找相关人乙讨论，而乙正在改另外的bug，他停下来和甲讨论，……

 

这样做也不是不可以，但应该能够被清楚的记录，也就是发现了新的Bug，并投入修改，或者发现了新的Bug。但优先级不高，可以等所有高优先级的做完再改。这样，大家能够知道修改进度。

 

值得担心的还不仅仅在此，以我们的经验和教训而言，最糟糕的结果可能是没完没了的陷入测试和开发围绕Bug的拉锯，使得项目剩下的时间变成不可估量的黑洞。修改的范围逐步扩大，到最后迫于时间压力，不得不屏蔽一些有问题的功能，匆匆交付。

 

在Scrum上有没有办法避免这个问题，答案是显然的，和SQA MM讨论了一下，觉得我们还是不辞辛苦，把禅道上所有的高优先级缺陷全部抄录到即时帖上，重新部署一张Sprint4的看板，周期预计三天，目标是“修改bug”，另外我们将来需要形成一个内部规则，确定S各print的质量目标，比如可执行、可递交内部测试、可DEMO、可评估、可正式发版。

 

上Sprint4的 “Bug修改看板”图片。一条条bug抄着手酸啊，也不知道工程师看着会不会觉得压力比较大，马上实践最重要，无所谓失败，发现一条走不通的路也是成果。