之前介绍过,N 产品Sprint6有新Backlog开发和稳定产品两个目标,因此我们设置了两条燃尽图,截止到上周末的趋势如下。
在Sprint6实践一周,有些和上次不同的实践可以描述下。
区别一:项目目标和持续时间
Sprint4是临时之举,不能说没有目标,但性不强。当时仅仅计划了3天时间。
Sprint6是稳定产品目标是Team几个Sprint反思后的决策,目标比前者更坚定。时间上也安排了两周,相对来说,预期比较充分,因此,工程师们心态更平和,不急于求成。
区别二:缺陷的量化
Sprint4,一开始只抄写最重要或优先的,但是燃尽图我们是不更新的。
Sprint6,测试人员每天把所有要改而未改/已改未验证的缺陷抄写出来,我们会统计剩余缺陷个数,并以此绘制燃尽图,(之前也考虑用严重程度来折算系数,比如严重的为1,一般的为0.5,不过考虑到这会增加SQA MM的工作量,而且能够得到的收益不多,因此没有采纳),量化的好处不言而喻。
------------------------
突然的领悟--大道至简
2010-11-16,特别补上
某天会后,我看着这个交错的燃尽图发呆,想如果真的按照严重程度来分是不是更合理,然后又想到还有那些元素影响对缺陷规模的度量,是基于预期修改的时间来量化,还是基于缺陷影响程度来量化。
于是想敏捷和传统的平衡,持续发呆……
然后,在白板上模拟数据画曲线,突然傻笑,乃至渐渐自惭形秽,混沌不堪。
所谓缺陷的燃尽图,不就是最简化的缺陷收敛趋势嘛
那所谓需求的燃尽图,不就是需求关闭的趋势嘛
大道至简,当我们陷入在繁复的度量中,当我们拿了一堆分门别类,逻辑严密、数据精确的报表给各个角色决策、评估、讨论,考核。当一些PM无奈地看着我们……
是我们想的多么,做的够好么?
我们是在解决问题,还是在创造问题?
也许某天,最简单的数个数,就可以解决这堆问题了。
这个很有意思,过程改进人员的want和need,分得清么?
借用一句话:实迷途其未远,觉今是而昨非
又是事后有感而发改题目