按照格式上報一下缺陷就叫缺陷管理嗎？沒有連招怎麼行？
問題痛點
軟體研發測試過程中的缺陷，是一個特殊的產物，它不會隨著研發模型的改變而變化，從一年一發布的瀑布模型，到一週一發布的 DevOps，“缺陷” 無法簡化，盲目的追求簡化，只不過是掩藏技術債的行為。
理想狀態下：一提一修復，驗完即上線，缺陷永不見
實際情況中：知否知否，缺陷修復，又豈只在朝朝暮暮
缺陷流技能乃經驗中之精品，無不聞之點頭，聽之驚歎。
那些我們曾經的痛：
修復未修復，傻傻分不清楚
踩坑再翻車，打臉沒商量
敏捷與
流程
，何以兼得
解決方案
用 JIRA 的好處在於能實現任何想實現的效果，難點在於需要一個很懂業務的 Atlassian 工具人。這裡我們以 JIRA 生態為例，推薦解決方案。
JIRA 組合拳：
工作流
+
欄位配置
+
介面
+
Automation for JIRA
，科學理論配合自動化，配置不簡單，使用不復雜。
1. 缺陷流
（工作流）
先看工作
流實圖
：
乍一看繁瑣且複雜，但實際上對於每一次的狀態變更
只有兩個選擇：同意 vs 不同意
。
所有狀態
貫穿缺陷的完整生命週期
，直到最終被驗收。
每個狀態清晰的表現了缺陷所處的階段及進展，如：修復中 -> 已修復 -> 已驗證
2. 專配專用
（欄位配置）
資訊不對稱在工作交流中帶來的弊端大家多少有感觸，對於缺陷型別的 JIRA 問題，如果也是用常規欄位方案明顯是不夠的，至少新增以下欄位，並且新增說明配上預設值，保證大家
認知統一且資訊齊全
。
3. 不同階段不同介面
（介面）
當然，不能讓使用者靠腦力去記憶上報缺陷的時候要填哪些資訊，應該是
選擇不同的問題型別，就展示對應的介面
。
除此之外，在狀態發生變化的時候，也應該彈出需要的介面，過濾掉那些不需要在當前階段再去考慮的多餘資訊，
只填必要項
。
4. 自動化協助
（Automation for JIRA）
JIRA 問題的標籤欄是個隨意性較高的欄位，但通常我們仍舊有一些約定好的格式和值，比如缺陷的最終狀態總會變為驗證，那麼它到底是個什麼結果，我們期望加上一些標籤作為標記，以方便一眼就能識別它，這些操作其實是有規律的，所以我們完全可以解放人力，透過自動化手段去完成，還杜絕了標籤新增錯誤的情況。除此之外，還有驗證即需要改變解決結果為完成，缺陷重現需要把解決結果改為進行中等等。
總結一下
管理是一系列的組合連招，僅僅會用個工具很難達到效果，這裡麵包含了很多業務經驗
，而質量管理之缺陷流，是比較容易落地的一種流派，還可以透過該方法收集一些資料，對質量管理可以起到一些意想不到的效果。
更多分享可關注公眾號：撩保星球
