不管承認與不承認，IT項目開發(fā)過程中，開發(fā)人員每天都在生產(chǎn)缺陷，那些沒有自動化單元測試、功能測試、集成測試、驗收測試的團隊更是如此，簡直可以用開發(fā)人員每日努力在產(chǎn)生缺陷。
這個情況與是用傳統(tǒng)項目管理還是與敏捷過程管理無關(guān)，因為即使是用敏捷過程，只要沒有大力應(yīng)用自動化測試(TDD, XP), 也好不到哪去。
回顧我之前在的W公司，那是公司使用dotNet為銀行開發(fā)財富管理平臺，傳統(tǒng)項目模式的強矩陣管理，清晰的角色分工：
- BA做業(yè)務(wù)需求分析，輸出FRS
- Architect根據(jù)FRS, 輸出架構(gòu)設(shè)計指導
- DBA設(shè)計數(shù)據(jù)庫與DTS
- Dev Team(Team Leader, Senior Dev, Dev, Junior Dev) 編碼實現(xiàn)
- Test/QA Team 打包部署測試
項目周期內(nèi)部開發(fā)測試6個月，SIT 2個月，UAT 2個月，共10個月。上線后做項目評審，這個項目10個月的時間里，QA有記錄在案的大大小小的缺陷就有一千六百多個。上線后仍有將近一百來個作為已知缺陷Go Live~.
再后來的Z公司，三個多月趕出一個APP，Bug List上有兩百多個。上線后又持續(xù)花了三到六個月再改改改，大部分時間在改Bug，新功能僅占小部分。
這個事情也后來我一直努力推行測試驅(qū)動開發(fā)的一個主要原因。
一直以來我們都知道缺陷給項目造成巨大的影響，進度問題，返工問題.....甚至導致項目最終失敗。
但是我們也沒有清晰的去評估一個缺陷的成本到底是多少，直到前段時間在我們CSM聊天群里談?wù)摰竭@個問題，才有一個比較直觀的方式分享給大家參考。大部分信息來源出自我們的教練CST Ethan Huang。
缺陷的處理過程與時間成本:
發(fā)現(xiàn)一個bug后的活動至少有：
- 使用工具記錄bug+跟蹤； 2小時
- 本機修改bug； 2小時
- 開發(fā)環(huán)境驗證； 2小時
- 測試環(huán)境驗證； 2小時
- UAT回歸測試（可按單個bug驗證x10算）； 2小時 x 10 = 20小時
- 以及部署; 2小時
共6個環(huán)節(jié), 共30個小時, 約等于 4 人／天。
解釋一下，為何UAT回歸測試要按單個Bug驗證 x 10
回歸測試按水波效應(yīng)最少影響十個測試用例
那么做一次回歸測試等于做十遍單個測試用例
按照一次回歸解決所有問題，且問題不再重現(xiàn)的最美好情況
水波效應(yīng)是指從測試邏輯上講有影響到的功能
比如你在放入購物車這個功能產(chǎn)生了金額不對的功能
那么改掉后你光測購物車的金額是不夠的，還要測check out、付款等下游功能
一個人天的成本:
在北上廣深，人均月成本在5萬左右，人均月成本包括（工資、社保、福利補助、獎金、辦公場所、設(shè)備折舊、行政財務(wù)均攤等等），是在公司角度計算，而不是僅僅個人工資支出。
據(jù)說，這個水平是北上廣深的平均水平，有高于這個水平的公司，也有低于這個水平的公司。具體數(shù)字可以找公司的人事部門獲取。
兩個重要數(shù)據(jù)出來了，我們可以直接計算出一個缺陷的成本是多少了
平均一個月按照20個工作日來計算
一個缺陷 = 4人天 x (￥50,000 / 20天) = $10,000
也就是說，平均一個缺陷造成的成本就是
一萬塊, 一萬塊, 一萬塊
特震撼有木有？ 我剛計算時也被震驚了，居然有這么多。
然而，然而，如果再加上機會成本(時間用于改BUG，就無法用于開發(fā)功能)的話，這個數(shù)字就要翻倍。
大多數(shù)情況下，公司也不是按照這個方式在100%承擔這個成本，例如，
當團隊每周產(chǎn)生足夠多的BUG時，這個BUG總成本也就是降下來的，因為BUG批量處理起來效率也會比單個單個高。
又或者，當某個功能BUG太多時，有可能會把這個功能砍掉，BUG成本立馬為零了。或許，推到重來，也可以把BUG丟掉，只不過新實現(xiàn)還是繞不開這個問題啊。
還有一種更嚴重的情況，那就是需求缺陷，由于需求出現(xiàn)問題，導致某個功能甚至整個產(chǎn)品方向需要做重大調(diào)整，這個造成的成本更加巨大。
開發(fā)人員制造的缺陷，成本是以萬計；
產(chǎn)品經(jīng)理/產(chǎn)品負責人制造的缺陷，成本則是以十萬乃至百萬計。
在后面，我們推行敏捷過程，努力實行各種自動化測試與持續(xù)集成來確保質(zhì)量，對質(zhì)量問題不妥協(xié)，質(zhì)量與進度同等重要。我們也在享受著相應(yīng)的回報，開發(fā)人員不再疲于改bug，改一個bug的同時引入三個bug，有效將力量用于更有價值的功能開發(fā)。
不管敏不敏捷，都需要重視質(zhì)量問題，最好的辦法就是將所有數(shù)據(jù)轉(zhuǎn)換為相應(yīng)的錢的數(shù)額，既直觀又有動力。
最后，評估一下自己公司的情況，我們不妨做個生意，我?guī)湍銈兏倪M流程、提升開發(fā)質(zhì)量，一年時間至少減少100個Bug，按100個Bug成本100萬計算，省下來的這100萬，40萬給公司，10萬給團隊做獎金，50萬給我????????。 同時公司還收獲100萬的機會成本。
Win-Win-Win. 想想都美好，哈哈哈····
