有目的的建模.對于自己的artifact，例如模型、源代碼、文檔，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或擔心它們是否足夠正確。你不應該毫無意義的建模，應該先問問，為什么要建立這個artifact，為誰建立它。和建模有關，也許你應該更多的了解軟件的某個方面，也許為了保證項目的順利進行，你需要和高級經理交流你的方法，也許你需要創建描述系統的文檔，使其他人能夠操作、維護、改進系統。如果你連為什么建模，為誰建模都不清楚，你又何必繼續煩惱下去呢？首先，你要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。一旦一個模型實現了目標，你就可以結束目前的工作，把精力轉移到其它的工作上去，例如編寫代碼以檢驗模型的運作。該項原則也可適用于改變現有模型：如果你要做一些改變，也許是一個熟知的模式，你應該有做出變化的正確理由（可能是為了支持一項新的需求，或是為了重構以保證簡潔）。關于該項原則的一個重要暗示是你應該要了解你的受眾，即便受眾是你自己也一樣。例如，如果你是為維護人員建立模型，他們到底需要些什么？是厚達500頁的詳細文檔才夠呢，還是10頁的工作總覽就夠了？你不清楚？去和他們談談，找出你想要的。
多種模型.開發軟件需要使用多種模型，因為每種模型只能描述軟件的單個方面，“要開發現今的商業應用，我們該需要什么樣的模型？”考慮到現今的軟件的復雜性，你的建模工具箱應該要包容大量有用的技術（關于artifact的清單，可以參閱AM的建模artifact）。有一點很重要，你沒有必要為一個系統開發所有的模型，而應該針對系統的具體情況，挑選一部分的模型。不同的系統使用不同部分的模型。比如，和家里的修理工作一樣，每種工作不是要求你用遍工具箱里的每一個工具，而是一次使用某一件工具。又比如，你可能會比較喜歡某些工具，同樣，你可會偏愛某一種模型。有多少的建模artifact可供使用呢，如果你想要了解這方面的更多細節，我在Be Realistic About the UML中列出了UML的相關部分，如果你希望做進一步的了解，可以參閱白皮書The Object Primer -- An Introduction to Techniques for Agile Modeling。
高質量的工作.沒有人喜歡爛糟糟的工作。做這項工作的人不喜歡，是因為沒有成就感；日后負責重構這項工作（因為某些原因）的人不喜歡，是因為它難以理解，難以更新；最終用戶不喜歡，是因為它太脆弱，容易出錯，也不符合他們的期望。
快速反饋.從開始采取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一共開發模型，你的想法可以立刻獲得反饋，特別是你的工作采用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客戶緊密工作，去了解他們的的需求，去分析這些需求，或是去開發滿足他們需求的用戶界面，這樣，你就提供了快速反饋的機會。
軟件是你的主要目標. 軟件開發的主要目標是以有效的方式，制造出滿足project stakeholder需要的軟件，而不是制造無關的文檔，無關的用于管理的artifact，甚至無關的模型。任何一項活動（activity ），如果不符合這項原則，不能有助于目標實現的，都應該受到審核，甚至取消。
輕裝前進.你建立一個artifact，然后決定要保留它，隨著時間的流逝，這些artifact都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，采納了一項新技術...），你就需要考慮變化對這7個模型產生的影響并采取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因為你是在輕裝前進。類似的，你的模型越復雜，越詳細，發生的改變極可能就越難實現（每個模型都更“沉重”了些，因此維護的負擔也就大了）。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處（所以才需要加強團隊之間，團隊和project stakeholder之間的溝通）。千萬不要小看權衡的嚴重性。一個人要想過沙漠，他一定會攜帶地圖，帽子，質地優良的鞋子，水壺。如果他帶了幾百加侖的水，能夠想象的到的所有求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎？同樣的道理，一個開發團隊決定要開發并維護一份詳細的需求文檔，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫源代碼上，而是花在了更新文檔上。
補充原則：
內容比表示更重要.一個模型有很多種的表示方法。例如，可以通過在一張紙上放置即時貼的方法來建立一個用戶界面規格（基本/低精度原型）。它的表現方式可以是紙上或白板上的草圖，可以是使用原型工具或編程工具建立和傳統的原型，也可以是包括可視界面和文本描述的正式文檔。有一點很有意思，一個模型并不一定就是文檔。它們通常作為其它artifact的輸入，例如源代碼，但不必把它們處理為正式的文檔，即使是使用CASE工具建立的復雜的圖表，也是一樣。要認識到一點，要利用建模的優點，而不要把精力花費在創建和維護文檔上。
三人行必有我師.你不可能完全精通某項技術，你總是有機會學習新的知識，拓展知識領域。把握住這個機會，和他人一同工作，向他人學習，試試做事的新方式，思考什么該做，什么不該做。技術的變化非常的快，現有的技術（例如Java）以難以置信的速度在改進，新的技術（例如C#和.NET）也在有規律的產生�，F存開發技術的改進相對會慢一些，但也在持續的改進中－－計算機產業屬于工業，我們已經掌握了其中的試驗基本原理，但我們還在不斷的研究，不斷的實踐，不斷的改進我們對它的了解。我們工作在一個變化是家常便飯的產業中，我們必須通過訓練、教育、思考、閱讀、以及和他人合作，抓住每一個機會學習新的處事之道。
了解你的模型.因為你要使用多種模型，你需要了解它們的優缺點，這樣才能夠有效的使用它們。
了解你的工具.軟件（例如作圖工具、建模工具）有各種各樣的特點。如果你打算使用一種建模工具，你就應當了解什么時候適合用它，什么時候不適合用它。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
