盡管零缺陷聽上去很動聽，但真有這種可能嗎？還是說這是一個無法實現(xiàn)的目標？很多組織采用“零缺陷的方法”。這是否真的有意義？

　　Jim Bird認為，100%完美的成本是異常高昂的。一旦團隊去除了90%的缺陷，到達了最佳水平，進一步去除缺陷所得的回報，相對于不成正比的成本而言，會明顯降低。Jim引用了Ken Beck和Martin Fowler在《規(guī)劃極限編程》中提到的觀點：

但是，對于大多數(shù)軟件，我們實際上并不期望它是零缺陷的。任何缺陷，一旦發(fā)現(xiàn)，要消除它就要花費時間和精力。這些時間和精力本可以投入到更有價值的新功能上。因此你必須決定做什么。

　　Michael Dubakov有類似的觀點，他認為相比零缺陷思想能帶來的好處，它產生的問題可能會更多。Michael說，不良的后果包括：

• 沒有足夠的勇氣去重構復雜、混亂、到處是缺陷的重要代碼。
• 無法做出重要的決策，而會做出風險相對較小的錯誤決定。
• 盡其所能不愿承擔責任，這會導致滑稽愚蠢的行為。

　　Michael認為在現(xiàn)實中，在生產系統(tǒng)中有缺陷是很正常的。這并不意味著團隊應該自滿，不去修正缺陷。但是，這并不代表所謂的“最后缺陷”是一個海市蜃樓。

　　Jim認為對于需要修正的缺陷，應該加以選擇。通過確認缺陷的嚴重程度和發(fā)生頻率，團隊首先應該確定缺陷對于業(yè)務運作的重要性。下一步，則是在修正缺陷前，考慮諸如“修正成本”和“對于系統(tǒng)其他部分的風險”這樣的技術因素。

零缺陷的觀點天真地假設：修正缺陷總是好的、正確的。但修正缺陷并不總是一件正確的事情，因為對于任何修正，都會有引入新問題的風險。

　　Joel Spolsky認為，零缺陷并不是字面上代表的意義。它是說在任何時候，在編寫新的代碼之前，最高的優(yōu)先級是消除缺陷。

　　那么減少缺陷的最佳途徑是什么？

　　Mark Windholtz認為測試驅動開發(fā)是至關重要的：

測試先行的編碼是實現(xiàn)零缺陷目標的基礎。測試先行的編碼方法，要求在編寫生產代碼之前，先編寫自動化的單元測試，而編寫測試代碼的時間周期是5～15分鐘。

　　同樣地，為了減少缺陷數(shù)目，Michael Dubakov建議結合使用TDD、持續(xù)集成、自動化回歸測試、根本原因分析和高水平的開發(fā)技能。

　　Rolf Gotz提到了開發(fā)零缺陷系統(tǒng)的十大原則。其中幾條包括：

• 客戶與軟件開發(fā)人員互敬互愛。
• 需求的范圍要小，要簡單，逐步增加。
• 優(yōu)先關注高價值的需求。
• 驗收標準是最重要的。
• 問題本身是第一位的（然后才是需求）。
• 優(yōu)先考慮性能需求。

　　因此，盡管系統(tǒng)應該只有極少數(shù)缺陷，但零缺陷是一個永無止境的追求目標。關鍵在于要了解何時應該停手。就像Jim建議的：

要了解何時停止修正缺陷，何時到達了收益逐漸降低的關口，何時應該把精力集中到更重要的工作上，并不是一件簡單的事情。知道哪些缺陷要修正，而哪些不要，或者哪些缺陷是目前不能或者不應該修正的，都不是簡單的事情。而且有時候你可能是錯誤的。

　　查看英文原文：The Holy Grail of Zero Defect Systems

it知識庫：零缺陷系統(tǒng)的圣杯，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。