AM（敏捷建模）是一種態度，而不是一個說明性的過程。AM是敏捷建模者們堅持的價值觀、敏捷建模者們相信的原則、敏捷建模者們套用的實踐組成的集合。 AM描述了一種建模的風格。當它套用于敏捷的環境中時，能夠提高開發的質量和速度，同時能夠避免過度簡化和不切實際的期望。 AM可不是開發的“食譜”，如果你尋覓的是一些細節的指導，如建立UML順序圖或是畫出用戶界面流圖，你可以看看在建模Artifacts中列出的許多建模書籍。
基本介紹
- 中文名：敏捷建模
- 簡稱：AM
- 性質：一種態度
- 價值：敏捷建模的價值觀
簡介,價值,原則,實踐,注意,
簡介
AM是對已有方法的補充，而不是一個完整的方法論。 AM的主要焦點是在建模上，其次是文檔。也就是說，AM技術在你的團隊採用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基礎上能夠提高建模的效果 。AM同樣也可以用於那些傳統過程（例如Unified Process），儘管這種過程較低的敏捷性會使得AM不會那么成功。
AM是一種有效的共同工作的方法，能夠滿足Project Stakeholder的需要。敏捷開發者們和Project Stakeholder進行團隊協作，他們輪流在系統開發中扮演著直接、主動的角色。在“敏捷”的字典中沒有“我”這個單詞。
AM是有效的，而且也已開始有效。當你學習到更多的AM知識時，有件事對你來說可能不好接受，AM近乎無情的注重有效性。AM告訴你：要使你的Project Stakeholder的投資最大化，當有清晰的目的以及需要了解產品需求時要建立模型或文檔，運用合適的工具來記錄手頭的情形，不論何時都應儘可能創建簡單的模型。
AM是來自於實踐中，而不是象牙塔般的理論。AM的目標就是以一種有效的態度描述系統建模的技術，它有效率，足夠勝任你手頭的工作。我和我在Ronin International的同事將大量的AM技術套用於實踐已經很多年了，我們琢磨的這些技術套用於非常廣泛的客戶，他們遍布各個不同的工業領域。而且，從2001年2月開始，就有數百位的建模專家通過“敏捷建模郵件列表”對這些技術進行過充分的檢查和討論。
AM不是靈丹妙藥。敏捷建模是改進眾多專家軟體開發成果的有效技術，充其量也就是這樣了。它並不是什麼了不得的靈丹妙藥，能夠解決你開發中的所有問題。如果你努力的工作；如果你專注其上；如果打心眼兒里接受它的價值觀、它的原則、它的實踐；你就可以改進你做為一個開發人員的效果。
AM是面向一般的開發人員的，但並不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多內容，可能你都已經採用或期待多年了。套用AM技術並不是要你去練水上飄，但你需要有一些基本的軟體開發技能。AM最難的就是它逼著你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試著一次學習一樣技術來完成你的學習。
AM並不是要反對文檔。文檔的創建和維護都會增大項目涉眾的投資。敏捷文檔儘可能的簡單，儘可能的小，目的只集中在和開發的系統有直接關係的事情上，充分了解客群的需要。
AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。
AM並不適合每一個人。
價值
一、敏捷建模的價值觀
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常說的，當你在進行軟體開發的競賽時，你的第二個目標就是準備下一場比賽。可持續性可能指的是系統的下一個主要發布版，或是你正在構建的系統的運轉和支持。要做到這一點，你不僅僅要構建高質量的軟體，還要創建足夠的文檔和支持材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想像到未來。
遞增的變化. 和建模相關的一個重要概念是你不用在一開始就準備好一切。實際上，你就算想這么做也不太可能。而且，你不用在模型中包容所有的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，然後慢慢的改進模型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。
令Stakeholder投資最大化. 你的project stakeholder為了開發出滿足自己需要的軟體，需要投入時間、金錢、設備等各種資源。stakeholder應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。並且，他們還有最後的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。
有目的的建模.對於自己的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）也在有規律的產生。現存開發技術的改進相對會慢一些，但也在持續的改進中－－計算機產業屬於工業，我們已經掌握了其中的試驗基本原理，但我們還在不斷的研究，不斷的實踐，不斷的改進我們對它的了解。我們工作在一個變化是家常便飯的產業中，我們必須通過訓練、教育、思考、閱讀、以及和他人合作，抓住每一個機會學習新的處事之道。
了解你的模型.因為你要使用多種模型，你需要了解它們的優缺點，這樣才能夠有效的使用它們。
了解你的工具.軟體（例如作圖工具、建模工具）有各種各樣的特點。如果你打算使用一種建模工具，你就應當了解什麼時候適合用它，什麼時候不適合用它。
局部調整. 你的軟體開發方法要能夠反映你的環境，這個環境包括組織特徵，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操作，這沒有錯，但是這能提供多少價值呢？恐怕很少。
公開展示模型.你應當公開的展示你的模型，模型的載體被稱為“建模之牆”（modeling wall）或“奇蹟之牆（wall of wonder）”。這種做法可以在你的團隊之間、你和你的project stakeholder之間營造出開放誠實的溝通氛圍，因為當前所有的模型對他們都是舉手可得的，你沒有向他們隱藏什麼。你把你的模型貼到建模之牆上，所有的開發人員和project stakeholder都可以看建模之牆上的模型，建模之牆可能是客觀存在的，也許是一塊為你的架構圖指定的白板，或是物理數據模型的一份列印輸出，建模之牆也可能是虛擬的，例如一個存放掃描好的圖片的internet網頁。如果你想要多了解一些相關的資料，你可以看看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模式需要，就建立所有的框架。這種方法使你能夠輕鬆的使用模式。
丟棄臨時模型.你創建的大部分的模型都是臨時使用的模型－－設計草圖，低精度原型，索引卡片，可能架構/設計方案等等－－在它們完成了它們的目的之後就再不能提供更多的價值了。模型很快就變得無法和代碼同步，這是正常的。你需要做出決定：如果“同步更新模型”的做法能夠給你的項目增添價值的話，那就同步更新模型；或者，如果更新它們的投入將抵消它們能夠提供的所有價值（即負收益），那就丟棄它們。
契約模型要正式.在你的系統需要的信息資源為外部組織所控制的時候，例如資料庫，舊有系統和信息服務，你就需要契約模型。一個契約模型需要雙方都能同意，根據時間，根據需要相互改變。契約模型的例子有API的細節文檔，存儲形式描述，XML DTD或是描述共享資料庫的物理數據模型。作為法律契約，契約模型通常都需要你投入重要資源來開發和維護，以確保它的正確、詳細。你的目標是儘量使你系統的契約模型最少，這和XP的原則traveling light是一致的。注意你幾乎總是需要電子工具來建立契約模型，因為這個模型是隨時需要維護的。
為交流建模. 建模的次要原因是為了和團隊之外的人交流或建立契約模型。因為有些模型是給團隊之外的客戶的，你需要投入時間，使用諸如文字處理器，畫圖工具包，甚至是那些“被廣告吹得天花亂墜”的CASE工具來美化模型。
為理解建模.建模的最重要的套用就是探索問題空間，以識別和分析系統的需求，或是比較和對照可能的設計選擇方法，以識別可能滿足需求的、最簡單的解決方案。根據這項實踐，你通產需要針對軟體的某個方面建立小的、簡單的圖表，例如類的生命周期圖，或螢幕順序，這些圖表通常在你完成目的（理解）之後就被丟棄。
重用現有的資源.這是敏捷建模者能夠利用的信息財富。例如，也許一些分析和設計模式適合套用到系統上去，也許你能夠從現有的模型中獲利，例如企業需求模型，業務過程模型，物理數據模型，甚至是描述你用戶團體中的系統如何部署的模型。但是，儘管你常常搜尋一些比較正確的模型，可事實是，在大多數組織中，這些模型要么就不存在，要么就已經過期了。
非到萬不得已不更新.你應當在你確實需要時才更新模型，就是說，當不更新模型造成的代價超出了更新模型所付出的代價的時候。使用這種方法，你會發現你更新模型的數量比以前少多了，因為事實就是，並不是那么完美的模型才能提供價值的。我家鄉的街道圖已經使用了5年了，來我自己街道並沒有改變位置，因此這張地圖對我來說還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但為什麼要這么麻煩呢？缺少一些街道並沒有讓我痛苦到不得不投資買一份新地圖。簡單的說，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。為了保持模型、文檔和原始碼之間的同步，已經浪費了太多太多的時間和金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟體上不是更好嗎？
注意
以下的實踐雖然沒有包括在AM中，但是可以做為AM的一份補充：
重構.這是一項編碼實踐。重構，就是通過小的變化，使你的代碼支持新的功能，或使你的設計儘可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計乾淨、清楚。重構是XP的一個重要部分。
測試優先設計.這是一項開發實踐。在你開始編寫你的業務代碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫代碼之前先通盤考慮你的設計，所以你不再需要細節設計建模了。測試優先設計是XP的一個重要部分。
四、敏捷建模是（不是）什麼？
我堅信當在描述事物的範圍時，你需要說明它是什麼，它不是什麼。不管你談論的是系統還是案例中的AM都一樣。以下就是我對AM的範圍的觀點：
