團隊成員協作，利用項目數據，分析根本原因，制定糾正措施，并立馬嘗試，判斷是否有效，是改善的“基本功”。10-12章會探索里面的注意事項，13章會看兩家公司的實施情況和常見問題。
如果已經獲得高層支持，她也贊同目前返工工作量太多并愿意投入資源進行過程改進，我們首先應該針對哪些方面進行改進呢？
軟件開發的特點是，超過95%的成本都是人力成本。因此，我建議利用二八(20/80)原則，繼續識別哪類工作的占比最高（詳見附件）。
請把過去一年的軟件開發項目，按照不同工種占項目總工作量的比例，從多到少排個序。
|
可以參考軟件開發度量專家卡鉑斯?瓊斯 (Capers Jones) 先生在2012年的研究（詳見附件中的“開發項目工作量(成本)分布”），看看你的選擇與典型分布有多大差距。
軟件開發項目最大的工作量通常是花在找出與修正缺陷上（開發里的“測試與評審”），Capers Jones 發現，對于一個超過10,000個功能點、計劃使用25年的大型系統來說，有接近一半的工作量是與找出并修正缺陷相關。
很多項目中的缺陷大部分還是到后期才發現，這導致了大量返工。如果能提前發現并解決這些缺陷，就可以大大降低研發成本(不僅僅是提升產品質量)。
對于一個軟件項目來說，發現缺陷最多的是在系統測試階段，其次是在驗收測試階段（很多公司都是如此）：
但很多開發人員誤以為編碼是項目的主要工作，卻忽視了大量因質量問題引起的返工。所以，只有當管理層意識到盡早發現并排除缺陷的重要性并引起重視，公司才有機會改進。
| 有些偏業務的領導可能會質疑，客戶不一定關注缺陷密度，只要達到可接受的水平就可以了。 我解釋：“在軟件開發中，減少后期測試才發現的缺陷，不僅僅能提升產品質量，更重要的是能降低研發的總工作量，所以最終能幫助公司省錢，減少開發人員加班。”（詳見附件“公司高層不一定關注質量”） |
怎樣開始
沒有度量便無法談改進，所以應先考慮如何采集修復缺陷相關的數據。然而，在探索數據收集與分析之前，我們更需要先確定度量分析的策略。
但在探索數據收集與分析之前，我們更需要先想好度量分析的策略。
| 請問你會使用以下哪種度量分析策略？
A：由公司的過程改進組（EPG）專員設計并執行過程改進的度量計劃，包括收集哪些數據、如何收集以及如何分析。然后按計劃收集各項目團隊的數據，進行總體分析，并制定公司的改進方案。 B：將數據收集與分析的任務下放到各團隊，讓團隊制定自己的改進方案。 |
如果你認為度量與分析需要專業知識，要由專人來做，就請選擇A，并考慮以下幾點：
- 提供數據的人需要很長時間才能收到反饋。例如，從團隊成員提交里程碑數據，到項目經理填報，再由度量分析人員收集、整理多個項目的數據，可能需要一到兩個月時間。再經過數據分析，管理層評審，最終到團隊成員收到反饋可能共兩三個月。由于每位提供數據者都希望盡快得到反饋，如果反饋的時間很長，那么團隊成員還會有動力繼續收集數據嗎？缺乏動力還會引發其他問題。
- 無法確保數據的準確性，導致分析沒有意義。如果這些指標用于公司考核KPI，情況會更糟。度量分析人員需要什么數據，提供數據的人都會按理想的指標填寫，反正公司級的總體分析人員也無法驗證數據的準確性。
- 假定各項目的特性或問題根因都是類似的。
| 與某質量部經理的對話： 經理：從去年開始我們進行度量分析以來，就發現員工會對數據造假，導致結果失真。度量什么，他們就造假什么，所以我們想通過工具代替人工，不僅能提升效率，還能幫助判斷數據是否合理。現在我們的主管很反感度量，因為每次度量就會有人造假——大家了解算法原理后，就開始造假。比如我們搞了紅黑榜，但很多人聰明得很，就會想辦法作弊。我們有很多數據統計分析，比如看測試用例與需求的比例。盡管客戶發現的缺陷比例降低了，但由于我們對質量特別注重，產品經過多年的逐步演化，過程很復雜，導致軟件缺陷的修復很耗時，客戶不太滿意。而且公司要求交付的頻率要比以前高了很多，我們團隊做這些分析都忙不過來，所以希望利用自動化工具加快速度。 |
但如果把數據分析下放到團隊自己做，便靈活多了；也正因為他們有參與收集和分析討論，過程改進組便可以節省很多溝通（數據收集）成本與失真。反而應該重新定位自己是內部老師，輔導團隊怎么做好數據分析，效果會更好。
你可能疑問：“團隊自己討論便可以得到改進嗎？不需要領導監督？”
如果團隊有能力，就應該放手讓他們自己收集數據、利用數據進行分析并做出改進。質量經理應把自己重新定位為團隊的教練，去輔導他們如何收集與分析數據。千萬不要以為這項工作會比以前自己做分析更輕松，其實需要更熟悉整個過程，才能真正輔導好團隊。要公司從定性管理提升到定量管理，最大的挑戰并非數據分析，反而是要讓管理層了解并贊同需要讓團隊自主分析數據，自己尋找糾正措施。
下一章會繼續探索團隊協作與分析根因；團隊如何利用迭代沖刺數據，在敏捷沖刺回顧，做好根因分析，得到提升。
附件
二八原則(80/20)
帕里托(Pareto) ，16世紀意大利威尼斯人，他發現雖然威尼斯很富有，但財富并非平均分布，80%財富在20%手里，他也發現很多其他分布都非平均。
因為過程改進需要公司額外的資源投入，必須有針對性地找出最容易取得改進效果的原因，才可能擁有最大的成功機會。所以，應該利用二八原則去識別影響最大的幾個因素. 以上圖為例，原本A類問題出現最多，針對這類問題做過程改進之后， A類問題就少了很多，下一輪便應針對最多的B類問題做改進。
有些人以為，只需要對某個維度做分析即可，并沒有從多個維度進行分析。例如，某紙制產品工廠會計數據顯示，8成的產品問題相關成本都歸屬于5類。
例如，某紙制產品工廠會計數據顯示，因紙質量問題被客戶退貨類的損失最大，共5560千美元，占總損失的61%。針對這類損失，發現里面八成是由6個產品引起（共有53個產品），共4480千美元，占5560的 80%。針對這6個產品把損失按缺陷種類細分，發現B產品容易斷裂缺陷(Tear)的占比最高，612千美元，我們就應該針對這一問題研究如何改善。
開發項目工作量（成本）分布
參考Capers Jones先生2012的例子，匯總成以下比例：
測試與評審一般占開發工作量的30%，測試與評審一般占總質量成本（包括發布后維護與改缺陷工作）的66%，把所有工作量都加起來，測試與評審還是占最大(26%)，編碼第二 (22%)。
| 注意：測試與評審包括所有與缺陷相關的成本，包括單元測試、靜態掃描、評審與相關的缺陷修正，而編碼只包括設計與編寫代碼部分。例如有些人會覺得比例應該是開發30%，測試和Bug修改25%，需求和設計20%，項目管理和溝通20%，文檔5%。但如果按上面的定義，開發部分很可能已包括單元測試、靜態掃描與改正缺陷工作，如把這些都歸到測試評審里會變回類似上圖的比例。 |
公司高層不一定關注質量
| Q&A 問：在傳統 IT的 公司，無論是 缺陷(Bug) 率還是其他質量指標對業務的影響的相關性都不容易度量，只有重大事件才會讓公司在客戶面前失去信任，所以高層不會真正的重視質量。
|
)
