補充實踐
◆使用建模標準
這項實踐是從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年了，5年來我自己街道並沒有改
變位置，因此這張地圖對我來說還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但爲什麼要這麼麻煩呢？缺少一些街道並沒有讓我痛苦到不得不投
資買一份新地圖。簡單的說，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。爲了保持模型、文檔和源代碼之間的同步，已經浪費了太多太多的時間和
金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟件上不是更好嗎？
確實不錯的主意
以下的實踐雖然沒有包括在AM中，但是可以做爲AM的一份補充：
◆重構
這是一項編碼實踐。重構，就是通過小的變化，使你的代碼支持新的功能，或使你的設計儘可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計乾淨、清楚。重構是XP的一個重要部分。
◆測試優先設計
這是一項開發實踐。在你開始編寫你的業務代碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫代碼之前先通盤考慮你的設計，所以你不再需要細節設計建模了。測試優先設計是XP的一個重要部分。
4、敏捷建模是（不是）什麼？
我堅信當在描述事物的範圍時，你需要說明它是什麼，它不是什麼。不管你談論的是系統還是案例中的AM都一樣。以下就是我對AM的範圍的觀點：
AM是一種態度，而不是一個說明性的過程。AM是敏捷建模者們堅持的價值觀、敏捷建模者們相信的原則、敏捷建模者們應用的實踐組成的集合。 AM描述了一種建模的風格。當它應用於敏捷的環境中時，能夠提高開發的質量和速度，同時能夠避免過度簡化和不切實際的期望。 AM可不是開發的“食譜”，如果你尋覓的是一些細節的指導，如建立UML順序圖或是畫出用戶界面流圖，你可以看看在建模Artifacts中列出的許多建 模書籍，我特別推薦我的書The Object Primer 2/e(儘管這有失公允)。
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 (http://www.ronin-intl.com) 的同事將大量的AM技術應用於實踐已經很多年了，我們琢磨的這些技術應用於非常廣泛的客戶，他們遍佈各個不同的工業領域。而且，從2001年2月開始，就有數百位的建模專家通過“敏捷建模郵件列表”(http://www.agilemodeling.com/feedback.htm) 對這些技術進行過充分的檢查和討論。