1. 向質量要效率

很多客戶在軟件項目管理過程中，經常會出現測試兜底質量的情況，同時測試也是質量保障的最重要一環。但是只靠測試人員把控交付的質量是不夠的，質量是要嵌入到整個端到端的流程中的。

從精益敏捷的視角來看，是要建立質量內建機制，既要確保需求的質量，也要確保代碼的質量，具體表現為需要明確需求在各個不同狀態或階段間流動的質量。

本文主要介紹缺陷管理方案，通過缺陷統一收口、明確缺陷管理規范到通過缺陷數據分析，驅動質效提升。

2. 缺陷管理的目標

缺陷管理的首要目標是①零缺陷。

其次針對已發現的缺陷，需要②高質量快速地解決缺陷。

再是通過對缺陷數據的分析和反饋，在③提升交付過程的質量和效率基礎上，同步提升產品交付的質量和效率，最終走向零缺陷的目標。

3. 缺陷管理的方案與路徑

3.1. 缺陷統一收口，避免漏網之魚

云效為每一個項目空間提供缺陷服務，關于該項目或該產品的相關人員，發現缺陷，都可以把缺陷錄入到這個位置。確保缺陷都統一錄入這里。

3.2. 明確缺陷管理規范，促進缺陷高效解決

3.2.1. 明確缺陷修復的工作流

缺陷的正常狀態流轉為：待確認 -> 處理中 -> 已修復 -> 已關閉

3.2.2. 明確缺陷內容的填寫規范

各個企業需要填寫的規則各不相同，這里選擇幾個主要的闡述

• 缺陷內容的描述：缺陷描述、重現步驟、期望結果、實際結果、原因定位和修復建議。

• 嚴重程度：產品不可用、主要功能錯誤、普通問題和輕微問題

• 所屬模塊：模塊A、模塊B等

• 缺陷深度：很容易發現、正常發現、很難發現等；

• 發現階段：功能測試階段、UAT階段、預發階段等；

• 引入階段：需求階段、編碼階段、測試階段等；

• 引入原因：需求描述不清晰、需求變更、編碼錯誤、代碼編寫不規范等

上面這些字段，團隊或者項目可以根據自己的情況設定哈。

3.2.3. 明確缺陷響應的SOP

1. 缺陷及時響應率：缺陷發現后，需要及時處理，可是設定缺陷要在一個時間段做響應，譬如5分鐘、半個小時或1小時等，可驅動團隊及時對缺陷進行響應。

2. 缺陷日清率：缺陷發現后，如果能在24小時內修復缺陷并驗證通過，缺陷被清除，到關閉狀態。可驅動團隊及時對缺陷進行修復。

3.3. 缺陷數據分析，驅動質效提升

缺陷數據相對于需求數據來說，是更容易獲取的，而且產研團隊對缺陷的發現和解決也是比較重視的。

缺陷數據分析至少包括：分析缺陷及時響應率、缺陷及時解決率，缺陷的平均修復時長，缺陷的庫存趨勢、缺陷的引入原因分布、缺陷引入階段分布、缺陷的引入模塊分布、對引入原因和引入模塊進行二維正交分布分析。

這里分析一個用的比較多的缺陷趨勢圖。

如上圖所示，比較了兩種不同的交付模式，橫坐標是日期，豎坐標是數量。

• 橫坐標上方紅色柱子代表這一天發現缺陷數量；

• 橫坐標下方綠色柱子代表這一天解決的缺陷數量；

• 橙色曲線代表缺陷存量。

左半部分，團隊屬于小瀑布的開發模式。“迭代”前期，團隊集中設計、編碼，引入缺陷，但并未即時地集成和驗證。在1號到20號期間，團隊一直在引入缺陷（寫缺陷），而未能及時的發現它們。缺陷一直掩藏在系統中，直到項目后期，團隊才開始集成和測試，缺陷集中爆發，越到后期發現的缺陷，修復困難度大幅提升，修復成本大幅增加。

小瀑布模式下，過程質量差，帶來大量的返工、延期和交付質量問題。該模式下，產品的交付時間依賴于何時缺陷能被充分移除，當然不能做到持續交付，也無法快速響應外部的需求和變化。并且，這一模式通常都導致后期的趕工，埋下交付質量隱患。

右半部分，團隊開始向持續交付模式演進。在整個迭代過程中，團隊以小粒度的需求為單位開發，持續地集成和測試它們，及時發現和解決問題。缺陷庫存得到控制，系統始終處于接近可發布狀態。這一模式更接近持續發布狀態，團隊對外的響應能力隨之增強。

缺陷趨勢圖從一個側面反映了團隊的開發和交付模式。它引導團隊持續且盡早發現缺陷并及時移除它們。控制缺陷庫存，讓系統始終處于接近可發布狀態，保障了持續交付能力和對外響應能力。

下圖是一個團隊缺陷趨勢圖的實例，該圖在云效效能洞察上可自動生成

歡迎使用云效效能洞察，做更多的缺陷分析和討論。

4. 總結

缺陷發現的越早，修復成本就越低，發現的越晚，修復成本就越高，如果到了客戶現場，發現了嚴重的缺陷，可能要付出巨大的成本，還有可能帶來丟單或者給公司帶來負面的影響。

而不管在哪個階段，修復缺陷終究都是在返工。如果可以一次性把事情做好，那就沒有了返工的成本。所以我們要建立內建質量的機制，把缺陷消滅在源頭，做到防患于未然，走向零缺陷。