隨著信息技術(shù)的迅猛發(fā)展，今天的IT從業(yè)人員正處于這樣一種進(jìn)退兩難的境地：一方面，根據(jù)以往的痛苦開發(fā)經(jīng)歷，他們知道如果采用雜湊的作坊模式來開發(fā)復(fù)雜的、高質(zhì)量的信息系統(tǒng)具有太大的風(fēng)險(xiǎn)；另一方面，他們也同樣知道，形式化的、戒律森嚴(yán)的軟件工程方法（典型情況下是與ISO9000和SEI-CMM相關(guān)的）又常常是官僚主義和耗費(fèi)時(shí)間的，不可能滿足目前高度競爭的“Internet時(shí)代”環(huán)境下對于進(jìn)度方面不斷增長的挑戰(zhàn)性要求。顯然，如何使得企業(yè)在保證軟件質(zhì)量的前提下，同時(shí)又能夠適應(yīng)快速變化的市場需求，無疑是業(yè)內(nèi)人士關(guān)注的焦點(diǎn)。為此，本文從市場驅(qū)動(dòng)的IT開發(fā)特點(diǎn)分析入手，對目前國際上正日趨成熟的“輕”方法和滿意質(zhì)量的內(nèi)涵和操作加以討論，同時(shí)以快速應(yīng)用開發(fā)為實(shí)例介紹了具體操作及注意事項(xiàng)，為讀者進(jìn)一步深入理解現(xiàn)代軟件工程實(shí)踐工作提供幫助。 一、市場驅(qū)動(dòng)的IT開發(fā)工作
當(dāng)今的IT企業(yè)正處于一種前所未有的競爭環(huán)境之中，無論是作為獨(dú)立軟件供應(yīng)商還是增殖服務(wù)商，也無論是開發(fā)直接面向市場的軟件產(chǎn)品如游戲、工具、多媒體等等，還是為用戶定制軟件如電子商務(wù)應(yīng)用、MIS等等，市場競爭都無處不在，IT開發(fā)工作被迫在市場驅(qū)動(dòng)的狀態(tài)進(jìn)行，具有以下典型特征：
快速演變升級的基礎(chǔ)技術(shù)，必須及時(shí)跟蹤基礎(chǔ)技術(shù)的革新并調(diào)整策略。
持續(xù)的競爭，必須不斷推陳出新來滿足用戶需求。
時(shí)間就是金錢——需要在時(shí)間、質(zhì)量、費(fèi)用之間達(dá)成折衷。
從業(yè)人員聰明且教育程度高，能夠在一定范圍內(nèi)進(jìn)行自我管理。
以往流行于IT行業(yè)的設(shè)計(jì)—評審—構(gòu)造模型已過時(shí)。IT業(yè)最新的技術(shù)和工具改變了以前項(xiàng)目運(yùn)行所必須遵循的邏輯順序。比如：現(xiàn)在一些工具允許“即時(shí)”創(chuàng)建屏幕，使得冗長的設(shè)計(jì)—評審—構(gòu)造模型不再適用，而要求一種更難于計(jì)劃的原型—審核—構(gòu)造—再審核—再構(gòu)造的過程。
角色重疊：現(xiàn)代技術(shù)和工具使原來專門的設(shè)計(jì)、分析、編碼人員之間嚴(yán)格的區(qū)分界限變的模糊。
以往的IT開發(fā)人員相對于當(dāng)前市場驅(qū)動(dòng)下的開發(fā)人員而言，至少擁有以下優(yōu)勢：控制他們的應(yīng)用開發(fā)技術(shù)。在傳統(tǒng)的企業(yè)應(yīng)用開發(fā)中，機(jī)器配置和其他系統(tǒng)元素在實(shí)現(xiàn)階段就被指定?，F(xiàn)在，這種優(yōu)勢不復(fù)存在，很少有哪個(gè)系統(tǒng)被實(shí)現(xiàn)為在專用機(jī)器上的孤立應(yīng)用。相反，他們經(jīng)常是企業(yè)用戶機(jī)器上的另一種應(yīng)用，必須與其他商業(yè)應(yīng)用程序聯(lián)合使用，這使得IT開發(fā)人員不得不為保持與CORBA、Internet、或數(shù)據(jù)庫標(biāo)準(zhǔn)的變化相一致而疲于奔命。同時(shí)，持續(xù)的競爭、緊迫的進(jìn)度和嚴(yán)格的預(yù)算讓IT開發(fā)經(jīng)理不得不經(jīng)常根據(jù)銷售人員或客戶的要求而調(diào)整開發(fā)工作。
顯然，市場驅(qū)動(dòng)的新環(huán)境給IT開發(fā)帶來新的挑戰(zhàn)，如果照搬套用以往的成功經(jīng)驗(yàn)和開發(fā)模式并非明智之舉，必須適應(yīng)新形勢的要求，重新思考和定位。
二、“輕”方法浮出水面
隨著軟件工業(yè)不斷發(fā)展，各種各樣的模型不斷涌現(xiàn)或退出歷史舞臺。早期從不同角度提出的各種設(shè)計(jì)表示方法（常常以發(fā)明者的名字來命名）目前似乎已經(jīng)聚合成為UML這種被廣泛接受的標(biāo)準(zhǔn)，結(jié)構(gòu)化設(shè)計(jì)方法也正在讓位于面向?qū)ο笤O(shè)計(jì)等更受歡迎的方法學(xué)，這種變化在更高層次的全局性開發(fā)方法學(xué)方面同樣進(jìn)行著。
傳統(tǒng)意義上的軟件方法學(xué)描述通?！澳軌颉碧幚砣魏未笮〉捻?xiàng)目，而實(shí)際上真正的困難就來自于如何對這些方法加以裁剪以適合較小的項(xiàng)目。針對這種理論與實(shí)際的脫節(jié)現(xiàn)象，國際上一些的軟件工程專家提出所謂“重（heavy）”方法和“輕（light）” 方法之分，試圖為快速發(fā)展的軟件工業(yè)探尋更切合實(shí)際的解決方法。
所謂“重”方法，就是指形式化的、戒律森嚴(yán)的軟件工程方法學(xué)——不僅指這些方法所生成紙文檔重量，還意指管理資源投入、QA評審的程度和開發(fā)人員被要求遵守的嚴(yán)格流程。相對的，諸如快速應(yīng)用開發(fā)（Rapid Application Development，簡記為RAD)和原型方法等則可以被稱為“輕”方法——不僅是因?yàn)檫@些方法傾向于產(chǎn)生最小數(shù)量的紙文檔，還因?yàn)槠鋵⒐芾碣Y源投入最小化。不幸的是，1990年代的許多RAD項(xiàng)目在方法學(xué)上采取了過“輕”的處理以至于幾乎不存在什么方法，這些項(xiàng)目常常退化為雜湊式作坊開發(fā)，實(shí)質(zhì)上根本沒有任何文檔。 顯然，需要在兩種極端方法之間找到平衡點(diǎn)。
輕方法代表了一種有意識的風(fēng)險(xiǎn)防護(hù)方法，依據(jù)不同風(fēng)險(xiǎn)在與開發(fā)相關(guān)的各種活動(dòng)中投入相應(yīng)時(shí)間、資金和資源。例如，進(jìn)行多少需求分析工作才算是過多，擬或過少？針對一個(gè)幾百個(gè)需求的開發(fā)項(xiàng)目而言，一個(gè)需求分析“輕”方法（requirements-light approach）可能是由將每一個(gè)需求通過一個(gè)簡潔的句子加以文檔化的行為所組成，一個(gè)需求分析“中”方法（requirements-medium approach）可能要求對每個(gè)需求通過一段描述性文本來文檔化，而一個(gè)需求分析“重”方法（requirements-heavy approach）則可能要求詳細(xì)的UML模型、數(shù)據(jù)元素定義和每個(gè)對象方法的形式化描述。
究竟選擇需求分析的“輕”方法還是“重”方法很大程度上受到公司產(chǎn)品上市時(shí)間或合同期限壓力的影響。同時(shí)，公司雇員的流動(dòng)率也是一種影響因素：作為形式化開發(fā)過程的理由之一認(rèn)為，如果有一份詳細(xì)的文檔來記錄需求、設(shè)計(jì)和編碼，那么一旦在項(xiàng)目進(jìn)行中關(guān)鍵開發(fā)成員離職所造成的混亂將會被盡量減小。然而，盡管1970年代和1980年代的系統(tǒng)生命周期預(yù)期為十年或二十年，也許Interbet時(shí)代的網(wǎng)絡(luò)公司更愿意正式承諾其電子商務(wù)應(yīng)用僅持續(xù)一年，然后被廢棄或完全重寫。如果正是這種情況，并且如果下一代應(yīng)用預(yù)期與當(dāng)前應(yīng)用存在質(zhì)的差異，那么僅僅為了達(dá)到SCM-CMM三級就遵循需求分析“重”方法還真的有意義嗎？
同樣地，針對設(shè)計(jì)和測試工作采用什么樣的形式化和嚴(yán)格程度才是合適的呢？與項(xiàng)目管理有關(guān)的時(shí)間匯報(bào)、進(jìn)展匯報(bào)、狀態(tài)會議及其他常見活動(dòng)又如何呢——尤其針對那些僅持續(xù)一周或兩周的項(xiàng)目？這些問題總是相互關(guān)聯(lián)的，但是一些傳統(tǒng)上被接受的答案卻需要至少每隔幾年重新審視一下，因?yàn)槌杀?收益參數(shù)正在隨著商業(yè)環(huán)境、技術(shù)和軟件開發(fā)人員的變化而不斷變化。
輕方法還重新審視了歷有關(guān)投入資源在需求分析的假定，以及投入資源在過程改進(jìn)的假定。1981年Barry Boehm在他的經(jīng)典著作“軟件工程經(jīng)濟(jì)學(xué)”（Software Engineering Economics）中指出了一項(xiàng)驚人發(fā)現(xiàn)，即如果我們在項(xiàng)目的系統(tǒng)分析階段引入一個(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)目而言，一些根本性的前提假定需要加以改變，而輕方法將是具有性能價(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)。
當(dāng)今的IT企業(yè)正處于一種前所未有的競爭環(huán)境之中，無論是作為獨(dú)立軟件供應(yīng)商還是增殖服務(wù)商，也無論是開發(fā)直接面向市場的軟件產(chǎn)品如游戲、工具、多媒體等等，還是為用戶定制軟件如電子商務(wù)應(yīng)用、MIS等等，市場競爭都無處不在，IT開發(fā)工作被迫在市場驅(qū)動(dòng)的狀態(tài)進(jìn)行，具有以下典型特征：
快速演變升級的基礎(chǔ)技術(shù)，必須及時(shí)跟蹤基礎(chǔ)技術(shù)的革新并調(diào)整策略。
持續(xù)的競爭，必須不斷推陳出新來滿足用戶需求。
時(shí)間就是金錢——需要在時(shí)間、質(zhì)量、費(fèi)用之間達(dá)成折衷。
從業(yè)人員聰明且教育程度高，能夠在一定范圍內(nèi)進(jìn)行自我管理。
以往流行于IT行業(yè)的設(shè)計(jì)—評審—構(gòu)造模型已過時(shí)。IT業(yè)最新的技術(shù)和工具改變了以前項(xiàng)目運(yùn)行所必須遵循的邏輯順序。比如：現(xiàn)在一些工具允許“即時(shí)”創(chuàng)建屏幕，使得冗長的設(shè)計(jì)—評審—構(gòu)造模型不再適用，而要求一種更難于計(jì)劃的原型—審核—構(gòu)造—再審核—再構(gòu)造的過程。
角色重疊：現(xiàn)代技術(shù)和工具使原來專門的設(shè)計(jì)、分析、編碼人員之間嚴(yán)格的區(qū)分界限變的模糊。
以往的IT開發(fā)人員相對于當(dāng)前市場驅(qū)動(dòng)下的開發(fā)人員而言，至少擁有以下優(yōu)勢：控制他們的應(yīng)用開發(fā)技術(shù)。在傳統(tǒng)的企業(yè)應(yīng)用開發(fā)中，機(jī)器配置和其他系統(tǒng)元素在實(shí)現(xiàn)階段就被指定?，F(xiàn)在，這種優(yōu)勢不復(fù)存在，很少有哪個(gè)系統(tǒng)被實(shí)現(xiàn)為在專用機(jī)器上的孤立應(yīng)用。相反，他們經(jīng)常是企業(yè)用戶機(jī)器上的另一種應(yīng)用，必須與其他商業(yè)應(yīng)用程序聯(lián)合使用，這使得IT開發(fā)人員不得不為保持與CORBA、Internet、或數(shù)據(jù)庫標(biāo)準(zhǔn)的變化相一致而疲于奔命。同時(shí)，持續(xù)的競爭、緊迫的進(jìn)度和嚴(yán)格的預(yù)算讓IT開發(fā)經(jīng)理不得不經(jīng)常根據(jù)銷售人員或客戶的要求而調(diào)整開發(fā)工作。
顯然，市場驅(qū)動(dòng)的新環(huán)境給IT開發(fā)帶來新的挑戰(zhàn)，如果照搬套用以往的成功經(jīng)驗(yàn)和開發(fā)模式并非明智之舉，必須適應(yīng)新形勢的要求，重新思考和定位。
二、“輕”方法浮出水面
隨著軟件工業(yè)不斷發(fā)展，各種各樣的模型不斷涌現(xiàn)或退出歷史舞臺。早期從不同角度提出的各種設(shè)計(jì)表示方法（常常以發(fā)明者的名字來命名）目前似乎已經(jīng)聚合成為UML這種被廣泛接受的標(biāo)準(zhǔn)，結(jié)構(gòu)化設(shè)計(jì)方法也正在讓位于面向?qū)ο笤O(shè)計(jì)等更受歡迎的方法學(xué)，這種變化在更高層次的全局性開發(fā)方法學(xué)方面同樣進(jìn)行著。
傳統(tǒng)意義上的軟件方法學(xué)描述通?！澳軌颉碧幚砣魏未笮〉捻?xiàng)目，而實(shí)際上真正的困難就來自于如何對這些方法加以裁剪以適合較小的項(xiàng)目。針對這種理論與實(shí)際的脫節(jié)現(xiàn)象，國際上一些的軟件工程專家提出所謂“重（heavy）”方法和“輕（light）” 方法之分，試圖為快速發(fā)展的軟件工業(yè)探尋更切合實(shí)際的解決方法。
所謂“重”方法，就是指形式化的、戒律森嚴(yán)的軟件工程方法學(xué)——不僅指這些方法所生成紙文檔重量，還意指管理資源投入、QA評審的程度和開發(fā)人員被要求遵守的嚴(yán)格流程。相對的，諸如快速應(yīng)用開發(fā)（Rapid Application Development，簡記為RAD)和原型方法等則可以被稱為“輕”方法——不僅是因?yàn)檫@些方法傾向于產(chǎn)生最小數(shù)量的紙文檔，還因?yàn)槠鋵⒐芾碣Y源投入最小化。不幸的是，1990年代的許多RAD項(xiàng)目在方法學(xué)上采取了過“輕”的處理以至于幾乎不存在什么方法，這些項(xiàng)目常常退化為雜湊式作坊開發(fā)，實(shí)質(zhì)上根本沒有任何文檔。 顯然，需要在兩種極端方法之間找到平衡點(diǎn)。
輕方法代表了一種有意識的風(fēng)險(xiǎn)防護(hù)方法，依據(jù)不同風(fēng)險(xiǎn)在與開發(fā)相關(guān)的各種活動(dòng)中投入相應(yīng)時(shí)間、資金和資源。例如，進(jìn)行多少需求分析工作才算是過多，擬或過少？針對一個(gè)幾百個(gè)需求的開發(fā)項(xiàng)目而言，一個(gè)需求分析“輕”方法（requirements-light approach）可能是由將每一個(gè)需求通過一個(gè)簡潔的句子加以文檔化的行為所組成，一個(gè)需求分析“中”方法（requirements-medium approach）可能要求對每個(gè)需求通過一段描述性文本來文檔化，而一個(gè)需求分析“重”方法（requirements-heavy approach）則可能要求詳細(xì)的UML模型、數(shù)據(jù)元素定義和每個(gè)對象方法的形式化描述。
究竟選擇需求分析的“輕”方法還是“重”方法很大程度上受到公司產(chǎn)品上市時(shí)間或合同期限壓力的影響。同時(shí)，公司雇員的流動(dòng)率也是一種影響因素：作為形式化開發(fā)過程的理由之一認(rèn)為，如果有一份詳細(xì)的文檔來記錄需求、設(shè)計(jì)和編碼，那么一旦在項(xiàng)目進(jìn)行中關(guān)鍵開發(fā)成員離職所造成的混亂將會被盡量減小。然而，盡管1970年代和1980年代的系統(tǒng)生命周期預(yù)期為十年或二十年，也許Interbet時(shí)代的網(wǎng)絡(luò)公司更愿意正式承諾其電子商務(wù)應(yīng)用僅持續(xù)一年，然后被廢棄或完全重寫。如果正是這種情況，并且如果下一代應(yīng)用預(yù)期與當(dāng)前應(yīng)用存在質(zhì)的差異，那么僅僅為了達(dá)到SCM-CMM三級就遵循需求分析“重”方法還真的有意義嗎？
同樣地，針對設(shè)計(jì)和測試工作采用什么樣的形式化和嚴(yán)格程度才是合適的呢？與項(xiàng)目管理有關(guān)的時(shí)間匯報(bào)、進(jìn)展匯報(bào)、狀態(tài)會議及其他常見活動(dòng)又如何呢——尤其針對那些僅持續(xù)一周或兩周的項(xiàng)目？這些問題總是相互關(guān)聯(lián)的，但是一些傳統(tǒng)上被接受的答案卻需要至少每隔幾年重新審視一下，因?yàn)槌杀?收益參數(shù)正在隨著商業(yè)環(huán)境、技術(shù)和軟件開發(fā)人員的變化而不斷變化。
輕方法還重新審視了歷有關(guān)投入資源在需求分析的假定，以及投入資源在過程改進(jìn)的假定。1981年Barry Boehm在他的經(jīng)典著作“軟件工程經(jīng)濟(jì)學(xué)”（Software Engineering Economics）中指出了一項(xiàng)驚人發(fā)現(xiàn)，即如果我們在項(xiàng)目的系統(tǒng)分析階段引入一個(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)目而言，一些根本性的前提假定需要加以改變，而輕方法將是具有性能價(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)。