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