经过了近2年的努力，多数研发团队都用上了技术质量部自主研发的Bug管理工具Kelude_Issues，告别了商业工具和其他的开源工具。这个过程中Bug跟踪流程也发生了比较多的变化，下图是现在Kelude_Issues的Bug跟踪流程图：
这个流程还是有着比较多的“淘宝特色”，我想可能很多用惯了其他Bug管理产品的同仁，看着这个图会感觉不太习惯，觉得状态比较多，箭头也多，有点绕。
在经典的Bug跟踪流程里面，对于“状态”概念的定义，是比较清楚的，一般来说这些状态会比较常见，当然由于工具的不同，所用的英文单词也会有些差别，这个不用纠结，领会精神。
New：新创建的Bug
Open：经过了PM的确认，确实是个Bug
Assigned：已经分配给开发工程师进行解决
Resolved：开发工程师解决了，等待测试工程师验证（注意是解决，不是fix）
Closed：通过了验证，关闭
这里最容易引起混淆的概念，就是“Resolved”——被解决过了。最常见的解决方式，就是Fixed，被修复了；有时因为一些原因，暂时无法修复，只能Later，其实Later也是一种解决方式，常见的解决方式有以下几个：
Fixed：被修复了
Later：暂时不修复，后面的版本再修复
Wont Fix：不修复了，其实是一种Later的特例，无限期Later
Invalid：根本不是Bug，往往由于对需求的误解
Duplicate：重复的，相同的Bug已经被提交过一次了
Not Reproducible：无法重现，在淘宝叫做Works for Me
严格来说，这一组“解决方式”，是属于同一层面的，它们都需要由测试或者PM来验证，如果验证不通过，那就回到Open状态，验证通过就Close。而在淘宝Bug流程中，这些“解决方式”都被设置成了“状态”，其实也挺好，更加直观。但是这里有一个很要命的问题，就是那个“wont fix”状态被刻意放大了，跳了出来成为了一个抽象的概念，这让很多开发工程师非常困惑，到底wont fix代表什么意思？
由于wont fix被错误的使用，引起了比较多的争议，记得当初优昙狠狠的挑战了一把，争论了很久，现在想来还是有道理的。也有很多开发表示，为什么我要Invalid，还要经过wont fix呢，多不方便，于是我们做了调整，变成了下面这个样子：
这样虽然解决了上面开发提出问题，但是这个流程依然有点不伦不类的，所以我们咬咬牙，继续改，彻底的改，成了这样的流程：
这个流程和经典的流程相比，还是有一些区别，我们依然选择把一些常用的“解决方式”，直接定义为“状态”，这样大家就不用理解那个抽象的“Resolved”了。当然，我们有一点跟经典Bug流程吻合，就是最后Bug都要回归Closed状态，之前大家都习惯了“只有Fixed才能Close”，这个习惯需要重新适应一下。
这里有人会问，最后都是Closed，怎么区分Later呢，我需要把Later的全翻出来，怎么找？这个问题还是比较好解决的，只要在Close Bug的时候，把当前的状态也记录下来就可以了，这样大家就能看到类似于Closed(Fixed)、Closed(Later)，这样就比较好区分了。
还有一个概念我们也比较常用，就是Reopen，目前Open和Reopen是两个独立的状态，但是它们的含义却是很接近的。由于我们把Reopen视为修复失败，是一种过错的表现，以后我们只要关注Fixed到Open和Closed到Open的记录即可，不用为了“度量”，单独定一个状态出来。