經過了近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的記錄即可，不用為了“度量”，單獨定一個狀態出來。