AM的價值觀包括了XP的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。
溝通. 建模不但能夠促進你團隊內部的開發人員之間溝通、還能夠促進你的團隊和你的project stakeholder之間的溝通。
簡單. 畫一兩張圖表來代替幾十甚至幾百行的代碼，通過這種方法，建模成為簡化軟件和軟件（開發）過程的關鍵。這一點對開發人員而言非常重要－它簡單，容易發現出新的想法，隨著你（對軟件）的理解的加深，也能夠很容易的改進。
反饋. Kent Beck在Extreme Programming Explained中有句話講得非常好：“樂觀是編程的職業病，反饋則是其處方�！蓖ㄟ^圖表來交流你的想法，你可以快速獲得反饋，并能夠按照建議行事。
勇氣. 勇氣非常重要，當你的決策證明是不合適的時候，你就需要做出重大的決策，放棄或重構（refactor）你的工作，修正你的方向。
謙遜. 最優秀的開發人員都擁有謙遜的美德，他們總能認識到自己并不是無所不知的。事實上，無論是開發人員還是客戶，甚至所有的project stakeholder，都有他們自己的專業領域，都能夠為項目做出貢獻。一個有效的做法是假設參與項目的每一個人都有相同的價值，都應該被尊重。
敏捷建模的原則
敏捷建模（AM）定義了一系列的核心原則和輔助原則，它們為軟件開發項目中的建模實踐奠定了基石。其中一些原則是從XP中借鑒而來，在Extreme Programming Explained中有它們的詳細描述。而XP中的一些原則又是源于眾所周知的軟件工程學。復用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重于它們是如何影響著建模工作；這樣，對于這些借鑒于XP的原則，我們可以從另一個角度來看待。
核心原則：
主張簡單. 當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟件。用AM的說法就是，如果你現在并不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要基于現有的需求進行建模，日后需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。
擁抱變化. 需求時刻在變，人們對于需求的理解也時刻在變。項目進行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著項目的進行，項目環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。
你的第二個目標是可持續性. 即便你的團隊已經把一個能夠運轉的系統交付給用戶，你的項目也還可能是失敗的－－實現Project stakeholder的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日后的擴展。就像Alistair Cockburn常說的，當你在進行軟件開發的競賽時，你的第二個目標就是準備下一場比賽�？沙掷m性可能指的是系統的下一個主要發布版，或是你正在構建的系統的運轉和支持。要做到這一點，你不僅僅要構建高質量的軟件，還要創建足夠的文檔和支持材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。
遞增的變化. 和建模相關的一個重要概念是你不用在一開始就準備好一切。實際上，你就算想這么做也不太可能。而且，你不用在模型中包容所有的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，然后慢慢的改進模型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。
令Stakeholder投資最大化. 你的project stakeholder為了開發出滿足自己需要的軟件，需要投入時間、金錢、設備等各種資源。stakeholder應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。并且，他們還有最后的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
