扔掉bug跟踪系统？！

这个标题很疯狂，让人感觉不是从一个开发的人口中说出的话，太激进、太左了。

在InfoQ上面看到这个标题（http://www.infoq.com/cn/news/2009/03/testobsessed-on-agile-bugs），一下子被抓住了眼球，仔细一读，说得有点道理。

 

作者Elisabeth Hendrickson认为，敏捷中bug的定义应该是

 

在“完成”的故事(story)中的某个行为，与产品负责人(prodcut owner)的正常的期待(expect)产生冲突 。

 

也就是说实现完一个故事行为之后将其交付，但是结果不符合product owner的期待，这算是一个bug。那么在没有交付故事前，所有一切的“非期待”都不是bug，不应该按照bug的方式来处理...。

 

如果按照bug处理，会产生一些常见问题，如1）bug泛滥，有些bug永远不得到修正 2) 不能及时从源头发现和解决问题，问题源头是不是需求做得太烂？跟客户沟通不够？...

 

另外令人想到的是，如果一个开发团队以bug num/kloc进行绩效考核的时候，如果bug滥用的问题没有很好解决，那么要求考核的公正是做不到的，会不会有冤打的大板？

 

看来Hendrickson的目的不是在于扔掉bug跟踪系统，而是对bug滥用提出另一种视角和对待方式。

 

有些意思，你怎么看？

 

 

按照作者的意思，BUG可以分为：
1，程序BUG；
2，Story BUG。

程序BUG绝对不能容忍吧。


Story BUG？我不大认为这是BUG。测试人员可以上报，但由story制定者裁定是否为bug。当然制定者意思和客户有偏差，但这肯定是难免的，人总是要犯错。但这是可行的。总不至于：1，让客户来裁定吧（有时制定者去请教客户）；2，让开发者直接找客户吧（开发团队和客户有个接口，这就是项目经理）。


-----------------------
权限管理圈子欢迎您加入：
http://accessmanager.group.iteye.com/

scrum涉及更多的团队开发（也就是楼上说的“没有技术含量”？），这可能也是它受到pm欢迎的一个理由。

xp讲最佳实践，比较针对programmer。

cmm除了一整套体系外，还有个体软件过程和组织软件过程两个实践指导，可惜国内的公司只追求一张纸的荣誉。

其实作者文章的内容是有启发性的，就是标题太过强烈了，可能和人的性格有关。