1.什麼28原則

8成BUG在2成的模塊。

2.怎麼安排你的工作時間

以任務為導向或者說以結果為導向的，每天有自己的目标，打算完成多少工作，做到今日事今日畢；遇到無法解決的問題，造成任務完成不了，應盡快反饋、協調解決問題，盡量保證當天可以完成，或調整的工作計劃。

3.項目發現Bug越多，質量越好

不一定，可能發現的越多，藏的也越多

4.上線前晚上發現嚴重Bug，第二天之前來不及修複

項目不能上線

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!