公開展示模型.你應當公開的展示你的模型，模型的載體被稱為“建模之墻”（modeling wall）或“奇跡之墻（wall of wonder）”。這種做法可以在你的團隊之間、你和你的project stakeholder之間營造出開放誠實的溝通氛圍，因為當前所有的模型對他們都是舉手可得的，你沒有向他們隱藏什么。你把你的模型貼到建模之墻上，所有的開發人員和project stakeholder都可以看建模之墻上的模型，建模之墻可能是客觀存在的，也許是一塊為你的架構圖指定的白板，或是物理數據模型的一份打印輸出，建模之墻也可能是虛擬的，例如一個存放掃描好的圖片的inte.net網頁。如果你想要多了解一些相關的資料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。
切換到另外的Artifact.當你在開發一個artifact（例如用例、CRC卡片、順序圖、甚至源碼），你會發現你卡殼了，這時候你應當考慮暫時切換到另一個artifact。每一個artifact都有自己的長處和短處，每一個artifact都適合某一類型的工作。無論何時你發現你在某個artifact上卡殼了，沒辦法再繼續了，這就表示你應該切換到另一個artifact上去。舉個例子，如果你正在制作基本用例，但是在描述業務規則時遇到了困難，你就該試著把你的注意力轉移到別的artifact上去，可能是基本用戶界面原型、CRC模型，可能是業務規則、系統用例、或變化案例。切換到另一個artifact上去之后，你可能就立刻不再卡殼了，因為你能夠在另一個artifact上繼續工作。而且，通過改變你的視角，你往往會發現原先使你卡殼的原因。
小增量建模. 采用增量開發的方式，你可以把大的工作量分成能夠發布的小塊，每次的增量控制在幾個星期或一兩個月的時間內，促使你更快的把軟件交付給你的用戶，增加了你的敏捷性。
和他人一起建模.當你有目的建模時你會發現，你建�？赡苁菫榱肆私饽呈�，可能是為了同他人交流你的想法，或是為了在你的項目中建立起共同的愿景。這是一個團體活動，一個需要大家有效的共同工作才能完成的活動。你發現你的開發團隊必須共同協作，才能建立一組核心模型，這對你的項目是至關重要的。例如，為了建立系統的映像和架構，你需要和同組成員一起建立所有人都贊同的解決方案，同時還要盡可能的保持它的簡單性。大多數時候，最好的方法是和另一些人討論這個問題。
用代碼驗證.模型是一種抽象，一種能夠正確反映你正在構建的系統的某個方面的抽象。但它是否能運行呢？要知道結果，你就應該用代碼來驗證你的模型。你已經用一些HTML頁面建立了接受付款地址信息的草圖了嗎？編碼實現它，給你的用戶展示最終的用戶界面，并獲取反饋。你已經做好了表示一個復雜業務規則邏輯的UML順序圖了嗎？寫出測試代碼，業務代碼，運行測試以保證你做的是對的。永遠也別忘了用迭代的方法開發軟件（這是大多數項目的標準做法），也別忘了建模只是眾多任務中的一個。做一會兒建模、做一會兒編碼、做一會兒測試（在其它的活動之中進行）。
使用最簡單的工具.大多數的模型都可以畫在白板上，紙上，甚至紙巾的背面。如果你想要保存這些圖標，你可以用數碼相機把它們拍下來，或只是簡單的把他們轉錄到紙上。這樣做是因為大多數的圖表都是可以扔掉的，它們只有在你畫出模型并思考一個問題的時候才有價值，一旦這個問題被解決了它們就不再有意義了。這樣，白板和標簽往往成為你建模工具的最佳選擇：使用畫圖工具來創建圖表，給你重要的project stakeholder看。只有建模工具能夠給我們的編程工作提供價值（例如代碼自動生成）時才使用建模工具。你可以這樣想：如果你正在創建簡單的模型，這些模型都是可以拋棄的。你建模的目的就是為了理解，一旦你理解了問題，模型就沒有存在的必要了，因此模型都是可以丟棄的，這樣，你根本就不必要使用一個復雜的建模工具。
補充實踐：
使用建模標準.這項實踐是從XP的編碼標準改名而來，基本的概念是在一個軟件項目中開發人員應該同意并遵守一套共同的建模標準。遵守共同的編碼慣例能夠產生價值：遵守你選擇的編碼指南能夠寫出干凈的代碼，易于理解，這要比不這么做產生出來的代碼好得多。同樣，遵守共同的建模標準也有類似的價值。目前可供選擇的建模標準有很多，包括對象管理組織（OMG）制定的統一建模語言(UML)，它給通用的面向對象模型定義了符號和語義。UML開了一個好頭，但并不充分－就像你在Be Realistic About The UML中看到的，UML并沒有囊括所有可能的的建模artifact。而且，在關于建立清楚可看的圖表方面，它沒有提供任何建模風格指南。那么，風格指南和標準之間的差別在何處呢。對源代碼來說，一項標準可能是規定屬性名必須以attributeName的格式，而風格指南可能實說在一個單元中的一段控制結構（一個if語句，一段循環）的代碼縮進。對模型來說，一項標準可能是使用一個長方形對類建模，一項風格指南可能是圖中子類需要放在父類的下方。
逐漸應用模式.高效的建模者會學習通用的架構模式、設計模式和分析模式，并適當的把它們應用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那樣，開發人員應當輕松的使用模式，逐漸的應用模式。這反映了簡單的價值觀。換言之，如果你猜測一個模式可能適用，你應當以這樣的方式建模：先實現目前你需要的最小的范圍，但你要為日后的重構留下伏筆。這樣，你就以一種可能的最簡單的方式實現了一個羽翼豐滿的模式了。就是說，不要超出你的模型。舉一個例子，在你的設計中，你發現有個地方適合使用GoF的Strategy模式，但這時候你只有兩個算法要實現。最簡單的方法莫過于把算法封裝為單獨的類，并建立操作，能夠選擇相應的算法，以及為算法傳遞相關的輸入。這是Strategy模式的部分實現，但你埋下了伏筆，日后如有更多的算法要實現，你就可以重構你的設計。并沒有必要因為Strategy模式需要，就建立所有的框架。這種方法使你能夠輕松的使用模式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/