局部調整. 你的軟件開發方法要能夠反映你的環境，這個環境包括組織特征，project stakeholder的特征，項目自身的特征。有可能受其影響的問題包括：你使用的建模技術（也許你的用戶堅持要看到一個細節的用戶界面，而不是初始草圖或基本原型）；你使用的工具（可能你沒有數字照相機的預算，或是你已經擁有某個CASE工具的license）；你遵循的軟件過程（你的組織采用XP的開發過程，或是RUP，或是自己的過程）。因此你會調整你的方法，這種調整可能是針對項目的，也可能是針對個人的。例如，有些開發人員傾向于使用某一類工具，有些則不用。有些人在編碼上花大力氣，基本不做建模，有些則寧可在建模上多投入一些時間。
開放誠實的溝通.人們需要能夠自由的提出建議，而且人們還應該能夠感受到他們是自由的。建議可能是和模型有關的想法：也許是某些人提出某部分新的設計方法，或是某個需求的新的理解；建議還可能是一些壞消息，例如進度延誤；或僅僅是簡單的工作狀況報告。開放誠實的溝通是人們能夠更好的決策，因為作為決策基礎的信息會更加準確。
利用好人的直覺.有時你會感覺到有什么地方出問題了，或是感覺什么地方有不一致的情況，或是某些東西感覺不是很對。其實，這種感覺很有可能就是事實。隨著你的軟件開發的經驗的增加，你的直覺也會變得更敏銳，你的直覺下意識之間告訴你的，很可能就是你工作的關鍵之處。如果你的直覺告訴你一項需求是沒有意義的，那你就不用投入大量的精力和用戶討論這方面的問題了。如果你的直覺告訴你有部分的架構不能滿足你的需要，那就需要建立一個快速技術原型來驗證你的理論。如果你的直覺告訴設計方法A要比設計方法B好，而且并沒有強有力的理由支持你選擇某一個方法，那就盡管選擇方法A。勇氣的價值就已經告訴你，如果未來證實你的直覺是錯的，你也有能力來挽救這種情況。你應該有這種自信，這很重要。
敏捷建模的實踐
敏捷建模（AM）在AM原則的基礎上定義了一組核心實踐（practice）和補充實踐，其中的某些實踐已經是極限編程（XP）中采用了的，并在Extreme Programming Explained一書中有詳細的論述，和AM的原則一樣，我們在描述這組實踐時，將會注重于建模的過程，這樣你可以從另外一個角度來觀察這些已或XP采用的素材。
核心實踐：
Stakeholder的積極參與.我們對XP的現場客戶（On-Site Customer）的概念做了一個擴充：開發人員需要和用戶保持現場的接觸；現場的用戶要有足夠的權限和能力，提供目前建構中的系統相關的信息；及時、中肯的做出和需求相關的決策；并決定它們的優先級。AM把XP的“現場客戶”實踐擴展為“使project stakeholder積極參與項目”，這個project stakeholder的概念包括了直接用戶、他們的經理、高級經理、操作人員、支持人員。這種參與包括：高級經理及時的資源安排決策，高級經理的對項目的公開和私下的支持，需求開發階段操作人員和支持人員的積極參與，以及他們在各自領域的相關模型。
正確使用artifact.每個artifact都有它們各自的適用之處。例如，一個UML的活動圖（activity diagram）適合用于描述一個業務流程，反之，你數據庫的靜態結構，最好能夠使用物理數據（physical data）或數據模型（persistence model）來表示。在很多時候，一張圖表比源代碼更能發揮作用，一圖勝千言，同樣，一個模型也比1K的源代碼有用的多，前提是使用得當（這里借用了Karl Wieger的Software Requirements中的詞匯）。因為你在研究設計方案時，你可和同伴們和在白板上畫一些圖表來討論，也可以自己坐下來開發一些代碼樣例，而前一種方法要有效的多。。這意味著什么？你需要了解每一種artifact的長處和短處，當你有眾多的模型可供選擇的時候，要做到這一點可沒有那么容易。
集體所有制.只要有需要，所有人都可以使用、修改項目中的任何模型、任何artifact。
測試性思維.當你在建立模型的時候，你就要不斷的問自己，“我該如何測試它？”如果你沒辦法測試正在開發的軟件，你根本就不應該開發它。在現代的各種軟件過程中，測試和質保（quality assurance）活動都貫穿于整個項目生命周期，一些過程更是提出了“在編寫軟件之前先編寫測試”的概念（這是XP的一項實踐：“測試優先”）。
并行創建模型.由于每種模型都有其長處和短處，沒有一個模型能夠完全滿足建模的需要。例如你在收集需求時，你需要開發一些基本用例或用戶素材，一個基本用戶界面原型，和一些業務規則。再結合實踐切換到另外的Artifact，，敏捷建模者會發現在任何時候，同時進行多個模型的開發工作，要比單純集中于一個模型要有效率的多。
創建簡單的內容.你應該盡可能的使你的模型（需求、分析、架構、設計）保持簡單，但前提是能夠滿足你的project stakeholder的需要。這就意味著，除非有充分的理由，你不應該隨便在模型上畫蛇添足－－如果你手頭上沒有系統認證的功能，你就不應該給你的模型增加這么一個功能。要有這樣的勇氣，一旦被要求添加這項功能，自己就能夠馬上做到。這和XP的實踐“簡單設計”的思想是一樣的。
簡單地建模.當你考慮所有你能夠使用的圖表（UML圖、用戶界面圖、數據模型等）時，你很快會發現，大部分時候你只需要這些圖表符號的一部分。一個簡單的模型能夠展示你想要了解的主要功能，例如，一個類圖，只要能夠顯示類的主要責任和類之間的關系就已經足夠了。不錯，編碼的標準告訴你需要在模型中加入框架代碼，比如所有的get和set操作，這沒有錯，但是這能提供多少價值呢？恐怕很少。
文章來源于領測軟件測試網 http://www.kjueaiud.com/