之前介绍过，N 产品Sprint6有新Backlog开发和稳定产品两个目标，因此我们设置了两条燃尽图，截止到上周末的趋势如下。

 

关于Bug看板，我们有个非典型的Sprint4做过一次实践，详见《Sprint4最后一天，思考Bug看板的应用价值》

在Sprint6实践一周，有些和上次不同的实践可以描述下。

 

区别一：项目目标和持续时间
Sprint4是临时之举，不能说没有目标，但性不强。当时仅仅计划了3天时间。
Sprint6是稳定产品目标是Team几个Sprint反思后的决策，目标比前者更坚定。时间上也安排了两周，相对来说，预期比较充分，因此，工程师们心态更平和，不急于求成。

区别二：缺陷的量化
Sprint4，一开始只抄写最重要或优先的，但是燃尽图我们是不更新的。
Sprint6，测试人员每天把所有要改而未改/已改未验证的缺陷抄写出来，我们会统计剩余缺陷个数，并以此绘制燃尽图，（之前也考虑用严重程度来折算系数，比如严重的为1，一般的为0.5，不过考虑到这会增加SQA MM的工作量，而且能够得到的收益不多，因此没有采纳），量化的好处不言而喻。

－－－－－－－－－－－－－－－－－－－－－－－－

 

某天会后，我看着这个交错的燃尽图发呆，想如果真的按照严重程度来分是不是更合理，然后又想到还有那些元素影响对缺陷规模的度量，是基于预期修改的时间来量化，还是基于缺陷影响程度来量化。

于是想敏捷和传统的平衡，持续发呆……

然后，在白板上模拟数据画曲线，突然傻笑，乃至渐渐自惭形秽，混沌不堪。

 

所谓缺陷的燃尽图，不就是最简化的缺陷收敛趋势嘛

那所谓需求的燃尽图，不就是需求关闭的趋势嘛

 

大道至简，当我们陷入在繁复的度量中，当我们拿了一堆分门别类，逻辑严密、数据精确的报表给各个角色决策、评估、讨论，考核。当一些PM无奈地看着我们……

 

是我们想的多么，做的够好么？

我们是在解决问题，还是在创造问题？

也许某天，最简单的数个数，就可以解决这堆问题了。

 

这个很有意思，过程改进人员的want和need，分得清么？