不論是在傳統的軟體開發流程還是敏捷開發流程中，缺陷的統計與分析都是軟體質量保證的重要環節。
一些傳統的缺陷統計和分析往往把重點放在缺陷數量的統計上，用於衡量開發和測試人員的kpi。例如某個功能模組出現了重大的bug，那當時負責開發的開發和測試都要出來「背鍋」。
不能說這種方法是錯的，但是如果把目的放在真正提高**的質量上，缺陷的分析應該擺脫這種找人背鍋的思路，回到真正的目的上來。乙個缺陷的產生不能簡單歸結於開發的錯誤或者測試的漏測，還需要從產品設計，架構設計，使用者體驗等方面進行分析。
產品的質量是內建的，當**完成的時候，質量就已經確定了。缺陷分析的價值應該體現在如何幫助**開發過程中的持續改進中。
缺陷分析的前期準備工作主要體現在缺陷/bug的記錄上。
要做到後期有效的缺陷分析，很重要的部分其實是前期記錄bug時的資訊收集。
下面的一些資訊都是必須要在建立和修復缺陷的時候記錄下來的：
記錄下缺陷發生在哪乙個功能模。複雜的系統裡面有很多功能模組組成，我們需要記錄下盡可能準確的功能模組，也有可能缺陷發生在不同模組之間的互動中，例如不同微服務之間的業務通訊，在service的provider和consumer的互動**現問題。那這種互動也可以看作是乙個特別的模組。模組的定義並不是固定的，目的是定位缺陷發生的位置。
root cause可以理解為錯誤的根源。而這個根源指的是導致缺陷的原因。一些常見的root cause有：
乙個資訊記錄詳細的缺陷，也為後續的分析提供了足夠的資訊支援。
乙個深入的分析，可以從以下幾個角度切入：
缺陷分析可以以頭腦風暴的形式來展開，參與的人員也不僅僅限於開發和測試人員，產品經理或者ba（業務分析）也可以參與到討論中。
缺陷分析要深入，幾乎難以避免的要去深挖**，通過對**的重新審視，抽絲剝繭的分析問題發生的原因。是初期的設計缺陷，還是實現時場景考慮的不完整，又或是**結構的不合理，這些都是需要對**進行review才能知道。
同時修復這個缺陷的**也需要進行review。因為發生缺陷的地方，可能是乙個業務上的難點，也可能是**實現中的難點，缺陷的修復需要經過code review，這樣有助於降低再次引起其他缺陷的風險。
對於產品環境發現的缺陷，很有必要對相關的功能的測試用例進行重新審視。因為這個缺陷是測試活動的漏網之魚。
乙個在發布上線前沒有被發現的缺陷，一定程度上可以說是escape from test。當然其中的原因是很多的。有可能是測試用例設計時場景路徑考慮的不完全，又或者是團隊對於真實業務資料的預估偏差，導致測試時沒有把這個場景的優先順序提高。因為測試的資源是有限的，一些優先順序較低的場景並沒有能夠加入到regression的自動化測試中。
如果缺陷發生的場景沒有測試用例覆蓋，那需要針對這個缺陷增加測試用例，對於線上的嚴重缺陷，還需要增加相應的自動化測試用例加以覆蓋。
經過了前期的準備和深入的分析，終於到了輸出的時候。乙個缺陷分析沒有得到有價值的輸出，前面做的再好也是浪費。乙個針對缺陷分析的解決方案，就是這個有價值的輸出。
缺陷分析的輸出不是對缺陷的修復，而是避免同類缺陷再次出現的解決方案，這是乙個內涵很廣的東西，它可以包括，但是不限於以下的內容：
對產品業務需求/設計層面的改進
對系統架構層面的改進
對**設計實現層面的改進
對測試用例設計方面的改進
對持續整合流程方面的改進
對於敏捷團隊日常工作實踐的改進
缺陷分析的解決方案是乙個**於缺陷，但是又能站的更高走的更遠的，並且可以操作和追蹤的解決方案。缺陷分析的整個過程中不用把思維侷限在缺陷本身，而是可以從多個角度來看待乙個缺陷。
最後，給大家乙個小小的提示，缺陷分析要避免走向為缺陷找人背鍋的方向，分析和討論的過程中要關注事件本身，而不是強調某個人在過程的責任。因為質量是團隊的責任，基於分析過程中發現的具體問題，大家一起提出建設性的意見，這樣的持續改進才是敏捷的正確實踐。
敏捷團隊如何進行績效考核？
兩個考核方向 團隊績效考核，個人績效考核 目的 促使團隊成員對整體質量負責 考核內容 1.每次迭代的交付物可否被接受。團隊採用的敏捷開發，每一階段會制定乙個產出計畫和產出目標 2.每次迭代的生產率是否理性增長。架構是否合理，後期擴充套件，修改是否容易 目的 考察個人能力，責任心等的不同來體現出每個團...
敏捷團隊如何進行績效考核？
兩個考核方向 團隊績效考核，個人績效考核 目的 促使團隊成員對整體質量負責 考核內容 1.每次迭代的交付物可否被接受。團隊採用的敏捷開發，每一階段會制定乙個產出計畫和產出目標 2.每次迭代的生產率是否理性增長。架構是否合理，後期擴充套件，修改是否容易 目的 考察個人能力，責任心等的不同來體現出每個團...
敏捷團隊如何進行績效考核？
兩個考核方向 團隊績效考核，個人績效考核 目的 促使團隊成員對整體質量負責 考核內容 1.每次迭代的交付物可否被接受。團隊採用的敏捷開發，每一階段會制定乙個產出計畫和產出目標 2.每次迭代的生產率是否理性增長。架構是否合理，後期擴充套件，修改是否容易 目的 考察個人能力，責任心等的不同來體現出每個團...