立会之后，想着燃尽图没有更新，去作战室数一下，发现感觉少了好些，某工程师名下寥寥几张，于是跑他座位上去问下，不过走进一看，不用问了，他把机箱放桌上的，侧面朝外，贴了好多即时帖，敢情这位老兄不看系统了，他把今天checkout的任务都拿来贴自己机箱上了。

这倒好，一个机箱迷你看板。

 

这个应该比较接近精益生产kanban的原貌了。

 

昨天的日志中光顾着感慨和自我批评了，因为最近在思考测试方面的事情，于是多思考了些。

缺陷收敛趋势是个非常好的东西，他直观的反应了项目中后期的进展。

再好的东西还需要正确地使用，有些测试负责人仅仅是把缺陷收敛趋势作为邮件发送出去后就没有下文了，开发负责人或产品经理也许就是习惯性打开看一下，很容易变成一个例行工作，甚至有些Team缺陷收敛趋势只是最后项目质量分析的一部分。

 

 

测试负责人可能希望开发人员多关注缺陷，但即使每天都将最新更新的缺陷收敛趋势，邮件发送给开发负责人甚至工程师全体，但如果没有充分的沟通，或不能达成一致理解，那实际上还是测试人员自己的意愿。

 

显然对整个项目进度是否可控这件事情上，影响因素不仅仅是缺陷数量，因此，测试人员希望自己给予了项目组足够的信息，而开发负责人未必有心思来关注缺陷情况。让他头痛的事情很多，比如还有不知道怎么实现的新功能，还有需要核实的需求，乃至还有人要离职。

在信息不对称的情况下，很容易滋生彼此的不信任以及抱怨，测试和开发的关系也容易僵化，太多的强调缺陷的重要程度和优先级也许反而干扰开发人员注意力。

在我们的Scrum实践中，同样的，燃尽图之所以成为Scrum框架的重要元素，是因为这根简单的线条能够让Team成员对目前的进度达成一致的理解。燃尽图本身的价值在慢慢减弱，每天都有固定的时间来讨论，能够有充分的机会对项目进度达成一致的认知。

目前N Team测试人员每天都要在立会上针对Tobe verified区域的所有bug做说明，并且对项目测试进展做最扼要的说明。

这种情况下，Team已经足够了解缺陷情况，各种形式的报表的价值就很低了。

（当然，为了积累需要，度量数据应该还有价值，这个有机会另外阐述。）