，甚至要求客戶參與開發(fā)過程。但原型方法和XP也有區(qū)別。XP是分批交付，先做一個幾個功能點的版本，完成后再每個開發(fā)周期往上面加其它功能點，而原型法一般要求做出比較完整，能覆蓋主要功能點的粗略的版本。XP方法仁者見仁，智者見智，不一而舉。
5.5 如何避免項目團隊做原型的時候出現(xiàn)部分人員閑置？
在項目管理中，對人力資源的調(diào)配應(yīng)和項目進展相匹配。實際上在用戶接觸到原型制作的同時，可以進行項目計劃、架構(gòu)設(shè)計、技術(shù)培訓(xùn)以及技術(shù)難點攻關(guān)等等。
如果從廣義上理解原型的話，架構(gòu)設(shè)計者甚至可以設(shè)計出一種用戶開發(fā)團隊使用的所謂框架原型，包含了主要的設(shè)計成分、模板和示例。
比較理想的結(jié)果是，當(dāng)原型完成后，需求分析、架構(gòu)設(shè)計和界面風(fēng)格設(shè)計都趨于完成，從這一點可以看到，原型方法可以作為快速軟件開發(fā)的重要手段。
5.6 如果避免項目在原型上停滯不前？
應(yīng)使用有經(jīng)驗的開發(fā)人員，避免因為程序員不熟悉業(yè)務(wù)而延誤進度；不要在界面設(shè)計上猶豫不決而占據(jù)時間；如果用戶對原型提出了很多意見，其中部分比較明確的意見可以在開發(fā)過程中進行實現(xiàn)；和客戶的交流應(yīng)該簡潔明了，而不是似是而非；另外，原型方法在項目過程中占據(jù)的時間應(yīng)該在項目計劃中保留出來，而不僅僅是隱含在需求調(diào)研與分析的一個部分。
5.7 如何避免用戶看了原型后漫無邊際地提要求？
首先，應(yīng)該充分尊重客戶，想想其它行業(yè)的服務(wù)質(zhì)量吧。有沒有聽說過這樣的說法，項目管理也是客戶滿意度的管理；軟件是一種對客戶的關(guān)懷，等等。確實，客戶提出的思路可能和你已經(jīng)形成的思路不同，一下子打亂了你的思路，也許項目經(jīng)理并不介意，但這確是讓設(shè)計者特別心煩的事情。如果確有把握，或者你可以不做到原型中去。有時候，即使原型很完美，用戶也會額外地提出一些意見，這也是人之常情。但不管怎樣，你不能認(rèn)為用戶根本不懂軟件，讓他們到時用就行了，抱這樣想法的多半會付出代價。
其次應(yīng)該進行坦誠協(xié)商，多數(shù)用戶其實都是通情達理的。如果你在簽訂合同時答應(yīng)滿足任何要求，而此時又無法忍受用戶的要求，那么孰是孰非應(yīng)是題外之意了。一般來說，比較合理的做法可以通過增加費用、延長進度或者把需求實現(xiàn)分階段來提交，以保持工作的延續(xù)性。對有些軟件，尤其是信息管理系統(tǒng)來說，客戶的實施時間其實并不是主要的，客戶最需要的不是及時，而是合用。
其實，客戶有著很多種類型，確實，個別客戶會參考同類產(chǎn)品來提要求，極個別用戶并不真正懂得計算機技術(shù)而對技術(shù)路線、技術(shù)手段等提出其意見，等等。但我們?yōu)槭裁催€可以反過來想一下，如果是等到軟件全部提交的時候，這部分用戶仍有會提出同樣的意見。提早暴露并解決分歧，對雙方睹是有利的。如果軟件公司明知可能存在矛盾，仍然先做好，然后等到用戶提出反對后，再提出補充收費，如果喜歡，也無話可說。
總之，原型應(yīng)本著對軟件需求的基本理解來做，這樣才能預(yù)防不一致性的發(fā)生。尤其應(yīng)該針對不清楚的地方制作原型，從而盡量暴露問題，引發(fā)用戶的聯(lián)想，不能回避問題，掩蓋問題（以免用戶提出太多的想法），很多問題雖然一時掩蓋了，但最終還是要發(fā)生的。
5.8 如何避免在原型基礎(chǔ)上繼續(xù)開發(fā)時的可維護性降低？
問題是這樣的，制作原型時常希望快速提供原型，往往不及對軟件結(jié)構(gòu)或者數(shù)據(jù)庫進行細(xì)致設(shè)計。所以在此基礎(chǔ)上繼續(xù)設(shè)計和開發(fā)的話，有必要在開發(fā)前先進行調(diào)整。同時，在設(shè)計原型前就有必要確定，該原型是要拋棄的，還是要演化要繼承的。對于要演化的原型，其設(shè)計不能過于粗略，顯然這直接影響到今后的開發(fā)成本。
6 小結(jié)
原型方法是可視化的方法，已成為快速軟件開發(fā)常用的手段。軟件公司或部門一旦得到了原型方法的回報，就會堅持使用。原型不是絕對必要，但非常有意義。