真的可以打造零缺陷系統(tǒng)么
盡管零缺陷聽上去很動聽，但真有這種可能嗎？還是說這是一個無法實現(xiàn)的目標(biāo)？很多組織采用“零缺陷的方法”。這是否真的有意義？
Jim Bird認(rèn)為，100%完美的成本是異常高昂的。一旦團隊去除了90%的缺陷，到達了最佳水平，進一步去除缺陷所得的回報，相對于不成正比的成本而言，會明顯降低。Jim引用了Ken Beck和Martin Fowler在《規(guī)劃極限編程》中提到的觀點：
但是，對于大多數(shù)軟件，我們實際上并不期望它是零缺陷的。任何缺陷，一旦發(fā)現(xiàn)，要消除它就要花費時間和精力。這些時間和精力本可以投入到更有價值的新功能上。因此你必須決定做什么。
Michael Dubakov有類似的觀點，他認(rèn)為相比零缺陷思想能帶來的好處，它產(chǎn)生的問題可能會更多。Michael說，不良的后果包括：
- 沒有足夠的勇氣去重構(gòu)復(fù)雜、混亂、到處是缺陷的重要代碼。
- 無法做出重要的決策，而會做出風(fēng)險相對較小的錯誤決定。
- 盡其所能不愿承擔(dān)責(zé)任，這會導(dǎo)致滑稽愚蠢的行為。
Michael認(rèn)為在現(xiàn)實中，在生產(chǎn)系統(tǒng)中有缺陷是很正常的。這并不意味著團隊?wèi)?yīng)該自滿，不去修正缺陷。但是，這并不代表所謂的“最后缺陷”是一個海市蜃樓。
Jim認(rèn)為對于需要修正的缺陷，應(yīng)該加以選擇。通過確認(rèn)缺陷的嚴(yán)重程度和發(fā)生頻率，團隊首先應(yīng)該確定缺陷對于業(yè)務(wù)運作的重要性。下一步，則是在修正缺陷前，考慮諸如“修正成本”和“對于系統(tǒng)其他部分的風(fēng)險”這樣的技術(shù)因素。
零缺陷的觀點天真地假設(shè)：修正缺陷總是好的、正確的。但修正缺陷并不總是一件正確的事情，因為對于任何修正，都會有引入新問題的風(fēng)險。
Joel Spolsky認(rèn)為，零缺陷并不是字面上代表的意義。它是說在任何時候，在編寫新的代碼之前，最高的優(yōu)先級是消除缺陷。
那么減少缺陷的最佳途徑是什么？
Mark Windholtz認(rèn)為測試驅(qū)動開發(fā)是至關(guān)重要的：
測試先行的編碼是實現(xiàn)零缺陷目標(biāo)的基礎(chǔ)。測試先行的編碼方法，要求在編寫生產(chǎn)代碼之前，先編寫自動化的單元測試，而編寫測試代碼的時間周期是5～15分鐘。
同樣地，為了減少缺陷數(shù)目，Michael Dubakov建議結(jié)合使用TDD、持續(xù)集成、自動化回歸測試、根本原因分析和高水平的開發(fā)技能。
Rolf Gotz提到了開發(fā)零缺陷系統(tǒng)的十大原則。其中幾條包括：
- 客戶與軟件開發(fā)人員互敬互愛。
- 需求的范圍要小，要簡單，逐步增加。
- 優(yōu)先關(guān)注高價值的需求。
- 驗收標(biāo)準(zhǔn)是最重要的。
- 問題本身是第一位的（然后才是需求）。
- 優(yōu)先考慮性能需求。
因此，盡管系統(tǒng)應(yīng)該只有極少數(shù)缺陷，但零缺陷是一個永無止境的追求目標(biāo)。關(guān)鍵在于要了解何時應(yīng)該停手。就像Jim建議的：
要了解何時停止修正缺陷，何時到達了收益逐漸降低的關(guān)口，何時應(yīng)該把精力集中到更重要的工作上，并不是一件簡單的事情。知道哪些缺陷要修正，而哪些不要，或者哪些缺陷是目前不能或者不應(yīng)該修正的，都不是簡單的事情。而且有時候你可能是錯誤的。
【編輯推薦】
