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