段引入一個缺陷的話，那么在項目的分析階段發(fā)現(xiàn)這個缺陷會比允許這個錯誤直至進入設(shè)計階段才被發(fā)現(xiàn)節(jié)省約10倍資源。但是Boehm在此做了一個在新千年的頭十年中未必依然正確的基本假定：僅當該缺陷在生命周期某階段發(fā)生時可通過某種方式加以鑒別，那么這種數(shù)量級增長關(guān)系圖才是相關(guān)的。在今天的環(huán)境中，這個前提假定在許多商業(yè)條件下都是不成立的。比如，當Bill Gates闡明對于瀏覽器IE的需求時，可能他會說“就象Netscape Navigator那樣，但要更好”，可能Netscape的Marc Andreesen也會這樣想：“我希望使Navigator就象Mosaic一樣，但要更好。”但是當Tim BernersLee在構(gòu)建WWW的初始版本和瀏覽器的第一個草樣時又該如何考慮呢?讓他寫出詳細需求的意義何在呢?
與此同時，重方法的倡導(dǎo)者爭辯說，如果一個缺陷在開發(fā)階段就被發(fā)現(xiàn)，那么就不應(yīng)當責(zé)備引入該缺陷的個人，而應(yīng)重新檢查允許該缺陷發(fā)生的過程本身。但此處又有一個基本假設(shè)，也就是說，我們值得投入資源在鑒別一個過程中潛在缺陷的唯一理由是我們希望再次使用同樣的過程——因為我們的下一個項目將會與上一個項目足夠相似，很自然就應(yīng)使用同樣的過程。但是現(xiàn)在事物變化是如此之快，以至于完全不能保證第N+1個項目會與第N個項目有任何相似之處。因此，昨天的過程可能不得不為了明天的需求而發(fā)生實質(zhì)性變化，換言之，也許只有投資于過程中的重要缺陷才是值得的，因為一些細節(jié)僅針對某個特定項目才有意義。
當然，仍然有一些環(huán)境需要我們繼續(xù)依賴于舊的、基本的軟件工程原理，在這些環(huán)境中重方法被證實依然正確。但是我們應(yīng)當捫心自問，隱藏在這些原理背后的前提假定是否依然合理。對于許多今天的項目而言，一些根本性的前提假定需要加以改變，而輕方法將是具有最優(yōu)性能價格比的方法。
可以看出，輕方法的基本思路是試圖在項目范圍、成本、時間和質(zhì)量之間達成一種平衡，其關(guān)鍵是在足夠的管理可見度、足夠的靈活性和足夠快的開發(fā)速度以完成工作之間找到這種平衡，必須嚴格審查你想要對項目加入或刪除的控制手段的價值何在。
盡管我們可以將某個公布于眾的開發(fā)方法作為基礎(chǔ)進行裁剪，但必須深入理解你要執(zhí)行的每個步驟的理由，尤其在項目的初始規(guī)劃階段，就應(yīng)明確定義開發(fā)方法，確保項目團隊成員的參與和認可，并以滿足項目的商業(yè)需求為目標。