價值觀
AM的價值觀包括了XP的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。
◆溝通 建模不但能夠促進你團隊内部的開發人員之間溝通、還能夠促進你的團隊和你的project stakeholder之間的溝通。
◆簡單 畫一兩張圖表來代替幾十甚至幾百行的代碼，通過這種方法，建模成為簡化軟件和軟件（開發）過程的關鍵。這一點對開發人員而言非常重要－它簡單，容易發現出新的想法，随着你（對軟件）的理解的加深，也能夠很容易的改進。
◆反饋 Kent Beck在Extreme Programming Explained中有句話講得非常好：“樂觀是編程的職業病，反饋則是其處方。”通過圖表來交流你的想法，你可以快速獲得反饋，并能夠按照建議行事。
◆勇氣 勇氣非常重要，當你的決策證明是不合适的時候，你就需要做出重大的決策，放棄或重構（refactor）你的工作，修正你的方向。
◆謙遜 最優秀的開發人員都擁有謙遜的美德，他們總能認識到自己并不是無所不知的。事實上，無論是開發人員還是客戶，甚至所有的 project stakeholder，都有他們自己的專業領域，都能夠為項目做出貢獻。一個有效的做法是假設參與項目的每一個人都有相同的價值，都應該被尊重。
管理工具
8Manage 敏捷管理支持增量式産品開發的短叠代管理和滿足競争格局和産品需求動态變化的管理需求。也可靈活擴展以滿足傳統項目監控的管理需求（如時間管理，成本管理）。
一個頁面管理整個項目
8Manage 敏捷管理非常簡單易用，用戶可在一個頁面管理整個項目。敏捷管理中的産品需求像展示在故事闆上的場景或故事，來龍去脈清晰明了，一目了然。在同一頁面可把産品需求和需求負責人分配到對應的用戶故事，有根有據，可随時追蹤。
叠代與待開發項
當産品需求越來越多，超過當前叠代的範圍，系統會自動把超過範圍的需求存儲在待開發項列表。用戶可随時查看在以往的叠代已經發布了哪些需求，哪些需求還在待開發項中，可幫助用戶更好地安排工作和作出決策。
溝通
敏捷管理提供方便易用的溝通工具可自動采集與每個需求相關連的郵件溝通。
審批與驗收
提供簡單審批與驗收機制。
燃盡圖
8Manage 支持用戶随時查看任一叠代或整個項目的燃盡狀态（工作完成情況）。
一體化
8Manage的所有模塊如CRM 、采購、PPM 、财務、人力資源、辦公自動化、商業智能、 O2O 、智力機構ERP及生産ERP, 都可以實時整合來提供企業所需的1體化管理功能。實時并非重點, 這些模塊隻需零時間便能完全整合在一起提供一體化管理功能，這意味着這些模塊原來就是基于一體化管理模式設計而成的，絕非不同的模塊有不同的設計而用EAI技巧表面把它們連上。
所有模塊的設計是先有一個整體一體化的設計，然後由同一個具有豐富的中外企業管理經驗的主計設師及同一個研發團隊花了10年的時間逐一完成。
原則
敏捷建模（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年了，5年來我自己街道并沒有改變位置，因此這張地圖對我來說還是有用的。不錯，我可以買一張新地圖，地圖是每年出一次的，但為什麼要這麼麻煩呢？缺少一些街道并沒有讓我痛苦到不得不投資買一份新地圖。簡單的說，當地圖還管用的時候，每年花錢買新地圖是沒有任何意義的。為了保持模型、文檔和源代碼之間的同步，已經浪費了太多太多的時間和金錢了，而同步是不太可能做到的。時間和金錢投資到新的軟件上不是更好嗎？
确實不錯的主意以下的實踐雖然沒有包括在AM中，但是可以做為AM的一份補充：
◆重構 這是一項編碼實踐。重構，就是通過小的變化，使你的代碼支持新的功能，或使你的設計盡可能的簡單。從AM的觀點來看，這項實踐可以保證你在編碼時，你的設計幹淨、清楚。重構是XP的一個重要部分。
◆測試優先設計 這是一項開發實踐。在你開始編寫你的業務代碼之前，你要先考慮、編寫你的測試案例。從AM的觀點來看，這項實踐強制要求你在寫代碼之前先通盤考慮你的設計，所以你不再需要細節設計建模了。測試優先設計是XP的一個重要部分。
是（不是）什麼？
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是面向一般的開發人員的，但并不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多内容，可能你都已經采用或期待多年了。應用AM技術并不是要你去練水上飄，但你需要有一些基本的軟件開發技能。AM最難的就是它逼着你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試着一次學習一樣技術來完成你的學習。
AM并不是要反對文檔。文檔的創建和維護都會增大項目涉衆的投資。敏捷文檔盡可能的簡單，盡可能的小，目的隻集中在和目前開發的系統有直接關系的事情上，充分了解受衆的需要。
AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。
何時是敏捷的？
要想了解AM，你需要了解模型和敏捷模型之間的區别。模型是一個抽象的概念，它描述了一個的問題的一個或多個方面，或是處理這個問題可能的解決方案。傳統意義上，模型被認為是圖表加上相應的文檔。然而那不夠直觀的artifact，也可以被視為模型，例如CRC卡片集，單條或多條業務規則的文字描述，或是業務流程的一段結構化英文描述。一個敏捷模型就是一個剛剛足夠好的模型。但是你怎麼知道什麼時候模型才是剛剛足夠好呢？當敏捷模型顯現出如下的特性時，它就是剛剛足夠好的：
敏捷模型實現了它們的目的。有時你為溝通而建模，或許你需要把你工作的範圍告訴高級經理；有時你為理解而建模，或許你需要确定一個設計策略，實現一組Java類。一個敏捷模型是否足夠好，要看它是不是滿足了創建它時的初衷。
敏捷模型是可理解的。敏捷模型要能為其預期聽衆所理解。使用用戶能夠理解的業務語言來描述需求模型，反之，技術架構模型則需要使用開發人員熟悉的技術術語。你所使用的建模符号會影響易懂性－－如果你的用戶不了解UML用例圖中的符号的含義，那用例圖對用戶就沒有任何價值。這樣的話，要麼使用另一種方法，要麼教授用戶學習建模技術。風格問題同樣也會影響易懂性，例如避免交叉線。雜亂的圖表比清晰的圖表難懂。模型的細節程度（見下文），也會影響易懂性，因為相較一個不那麼詳細的模型來說，一個過于詳細的模型要難于理解。簡單（見下文）同樣是影響易懂性的一個因素。
敏捷模型是足夠正确的。模型通常都不需要100%正确，隻要足夠正确就行了。舉個例子，如果一張街道地圖漏畫了一條街道，或是它标示某條街道是通行的，但你發現它已經關閉維修了，那你會不會扔掉你的地圖開始在城裡飙車犯罪呢？不太可能。你會考慮更新你的地圖，你可能會拿出筆來自己做修改或是去當地的商店買一張最新版的地圖（你原來的那張過期了）。也許你還是會接受那張雖不完美仍可使用的地圖，因為它對你來說已經足夠好了。你還是可以用這張地圖四處轉轉，因為它還是個正确的模型，标記出了大部分街道的位置。你在發現這張地圖不正确的時候，你沒有立刻扔掉它，原因是你根本不在乎它是否完美。類似的，當你在需求模型、數據模型中發現錯誤的時候，你也會選擇更新或是接受－－雖不完美但已經足夠好了。有些項目成員能夠容忍這種不正确而有些則不能：這取決于項目的特性，每個團隊成員的特性，組織的特性。充分正确性既和模型的聽衆有關，也和你要處理的問題有關。
敏捷模型是足夠一緻的。一個敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一緻。如果一個用例在它的一個步驟中顯式的調用了另一個用例，那麼相應的用例圖需要用UML的 <> 版型來标記這兩個用例之間的關系。然而，你看了看圖表，發現它們并沒有這樣做，天哪！用例和圖之間不一緻！危險！太危險了！紅色警報！快逃命呀！等一下，你的用例模型是有不一緻的地方，但也沒到世界末日啊。是的，理想情況下，你的所有artifact最好是能夠完全一緻，但這通常是不可能的。當我開發一個簡單的商用系統時，我通常都可以容忍部分的不一緻。但有時我是不能容忍這種不一緻的。最有力的佐證就是1999年 NASA發射火星太空探測器時采用了精密的測量系統。要樹立一個觀點，敏捷模型隻要足夠一緻就行了，你通常不需要使用那麼完美的模型。
關于正确性和一緻性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為“保管”），随着時間的流逝，你需要投入資源來更新它。否則它很會就會過期，對你就沒用了。例如，我可以容忍一張地圖标錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都标錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正确。過多不必要的努力反而會減緩項目的進度，而投入不足就沒有辦法保證artifact的有效性。
敏捷模型有足夠的細節。一張路線圖并不需要标記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建築、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖并不用标記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽衆有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。
考慮一個架構模型，可能一組畫在白闆上的圖表就足夠了－－項目的進行中再對它們更新，也許你需要用CASE 工具來生成一些圖表，也許這些圖表還需要有詳細的文檔，這依賴于環境。不同的項目有不同的需要。在每一個例子中，實際上你都是在開發、維護一個有足夠的細節的架構模型，隻是這個“足夠的細節”的概念和環境有關。
敏捷模型能提供正面價值。對項目中的任一artifact，一個基本的要求是它們能夠提供正面價值。一個架構模型給你的項目帶來的價值是不是能夠超過開發它、維護它（可選）的總成本？一個架構模型能夠堅定你們團隊為之努力的願景，所以它當然是有價值的。但是，如果它的成本超過了這個價值，那就是說，它無法提供正面價值。投入100,000美元去開發一個詳細的、重量級的文檔化架構模型，而它的效用，隻需一些畫在白闆上的圖表就能夠達到，這些圖隻需要花你 5,000美元，看看，這是多麼輕率的做法。
敏捷模型要盡可能的簡單。隻要能夠達到目的，你應當努力讓你的模型盡可能保持簡單。模型的詳細程度會影響簡單性，而所使用的符号範圍也會影響簡單性。例如，UML的類圖就包括了無數的符号，包括對象約束語言 (Object Constraint Language OCL) ，但大多數的圖使用符号的一部分就能夠完成。所以你常常不需要使用所有的符号，你可以限制自己使用符号的一個子集，當然，這個子集是足夠讓你完成工作的。
因此呢，一個敏捷模型的定義就是一個實現它的目的，沒有畫蛇添足的模型；為你的預期聽衆所理解的模型；簡單的模型；足夠正确、足夠一緻、足夠詳細的模型；創建和維護它的投資能夠給項目提供正面價值的模型。
一個普遍的哲學問題是源代碼是不是一個模型，更重要的，它是不是一個敏捷模型。如果你是在我們這篇文章之外問我這個問題，我會回答說，是，源代碼是一個模型，雖然是一個高度細節化的模型，因為它是軟件的一個抽象。同時我還認為，優秀的代碼是一個敏捷模型。但在這裡，我還需要把兩者區分開來，源代碼和敏捷模型還是有區别的——敏捷模型幫助你得到源代碼。
AM的實踐是如何組合的
AM的實踐之間是相互促進的，因為他們彼此支持，彼此激發。為了使AM更有效率的工作，你需要了解它的實踐是如何組合的。圖1顯示了AM的實踐之間的關系，它們被分為七類。AM的核心實踐集中在頭四種類别中－驗證，叠代和遞增，團隊協作，和簡單，你需要完全接受它們才能真正理解敏捷建模。然後，才輪到屬于輔助實踐的文檔，動機，生産率這三個類别。我們先針對核心實踐的四個類别，讨論各類中的實踐之間的關系，然後我們再針對輔助實踐的三個類别，研究各類中實踐之間的關系，最後我們來讨論類别之間的關系。
核心實踐
在團隊協作類别中有四項實踐－－stakeholder的積極參與，和他人一起建模，公開展示模型，和集體所有制。stakeholder的積極參與對你的成功至關重要，因為你正是為了這些project stakeholder開發系統，正是為了了解和實現他們的需求。換言之，你需要和你的甲方們密切合作，這就自然的想到了和他人一起建模－－這個“他人” 也包括你的stakeholder。當你的建模工作有多人參加時（至少一個project stakeholder和一個除你之外的開發人員），你就需要和衆人共同協作，相互促進，取長補短。一個擅長于業務過程建模和業務規則定義的敏捷建模者看不到的方面，一個精通結構化建模技術（例如UML類圖或數據模型）的人極有可能看得到。一樣的道理，系統的直接用戶給你的團隊提供的信息極可能是高級經理提供不了的。所以，要有這樣的觀點：你要在項目甲方和開發團隊中營造一種積極參與的氛圍，隻有這樣，才能夠收集各種不同的觀點和經驗。集體所有制能夠提升協作性，因為一個人單獨的進行建模的工作，他很快就會遇到瓶頸，而如果每個人都能夠為建模工作獻計獻策，那麼你們就能夠成為一個團隊，輕易的解決問題。公開展示模型能夠使得人們對模型“瞻前顧後”變得容易了，能夠立刻考慮模型傳達的信息，從而提高團隊的協作性。當然，我們是假設模型都在衆人的視線之内，或者這些模型都是大家目前正在開發或相關的。這方面的主題我在Organizing an Agile Modeling Room中有詳細的讨論。
叠代和遞增類别中包括了使用合适的artifact，并行創建模型，切換到另外的artifact，小增量建模這幾項實踐。不論哪一個 artifact，都有它的長處和短處，任何一個單獨的模型都不足以充分的描述你的項目的各個主要方面（如需求、架構）。例如你會發現你為了識别系統的需求，常常需要組合使用用例、業務規則定義、和技術需求定義。單單靠用例就能令project stakeholder立馬告訴你他們所有的使用需求嗎？這恐怕不太可能。你可以試試換用諸如業務規則之類的artifact來捕獲他們的所有業務政策，再換用諸如技術需求的artifact來捕獲他們的非功能需求。否則，他們會想起點什麼就告訴你什麼，還會返回去讨論先前提過的細節，甚至是改變他們的原來的主意。你的需求識别工作通常是一個動态的過程，分析、架構、設計工作也是一樣。我相信物力論中指出了人們以此種方式思考的原因，我們思考的方式明顯是雜亂的。敏捷建模者要認識到人們是以一種動态的方式在思考，特别是人們處于群體行為時，這樣才能制定對策。敏捷建模者并行創建模型，從而能夠最廣泛的收集信息。這項實踐又是由實踐切換到另外的artifact和小增量建模來支持的－－你可能正在使用用例來捕獲使用需求的相關信息，而當stakeholder開始讨論他們對編輯屏幕的要求時，你最好是使用基本用戶界面原型或是傳統用戶界面原型來記錄這些需求。你需要在不同的artifact之間來來回回，每一個artifact最好都需要編碼來驗證，這種方式可以由小增量建模的實踐來實現－－最典型的方式就是在這個artifact上做一會兒工作，再換一個artifact，依此類推。
簡單這個類别包括了創建簡單的内容，簡單地建模，使用最簡單的工具這幾項核心實踐。創建簡單的内容和簡單地建模這兩個實踐集中于模型的簡單性，在建模過程中這兩項實踐通産是密不可分的。把精力集中在如何簡單描述，建模者常常會發現一些使得你手頭的模型簡單化的方法。舉個例子，我曾經參加了一項存儲層軟件的開發工作，軟件的概念類似于EJB的persistence container，封裝了領域對象的一些存儲操作。結果我們架構和設計非常的複雜，我們試着找到一種辦法：建立一張簡單的圖表，幫助開發人員理解如何使用存儲層來工作。其間我們還發現重構能夠使我們的設計易于理解。實踐使用最簡單的工具能夠使得過程變得簡單。工具越簡單就越容易使用，這就降低了他人在你的模型上工作的門檻，也就增加了實際中别人去這麼做的機會，這也包括了你的project stakeholder。通過使用最簡單的工具，簡單描述模型也變得更自然了。此外，當你使用一些簡單/低精度的工具，例如索引卡片，即時貼，白闆的時候，你就能親身體驗這些簡單工具的效力，你在不知不覺中已經強化了一些概念：最簡單的解決方法實際上也能非常有效，對你正在開發的系統采用簡單的設計。
驗證類别包含了兩個核心實踐：測試性思維和用代碼驗證。有一條哲學，我常從中受益：“如果你無法測試它，你就不應該建立它，而你建立的一切都應該加以測試。”這使得我在系統建模時就考慮測試，也使得我積極的去獲取我的模型的反饋－－實際上，我把該條哲學歸納為“考慮你創建的所有artifact的可測試性，以及驗證所有種類的artifact。”但這并不僅僅局限于AM的範圍之内。通過這種可測試性的考慮，在我建模時，我能夠建立起可測試的模型，而且積極的通過編碼來驗證模型，這樣，我就能夠盡快的證實我的模型是真正可以測試的。
輔助實踐
文檔類别包括了三項輔助實踐：丢棄臨時模型，合同模型要正式，非到萬不得已不更新。在項目的進行中，需求、對需求的理解、以及對可能的解決方案的理解，都在不斷變化（回憶一下原則擁抱變化）。為了反映這種變化，你需要同步改進你大部分的項目artifact，包括模型和文檔。就像在敏捷文檔讨論的那樣，比較好的方法是，不到萬不得已不要更新你的模型和文檔，這種做法才算是敏捷方法。遵循這項實踐，如果你發現一個模型如果不再需要更新，那就是說這個模型對你的團隊已經沒什麼價值了，一個沒有價值的模型就可以視為臨時模型，可以丢棄。不過，要注意合同模型。它定義了你的系統和其他系統之間的接口，不太可能經常改變，因為它們的重要性是勿庸置疑的。一言以蔽之，如果你有個非合同模型不再更新，那就意味着它已經沒有用了。
為溝通建模和為理解建模這兩項實踐屬于動機類别。實際上，這兩項實踐并沒有太多的聯系，有時候你創建模型的目的是為了研究和理解問題，有時候你的目的是為了和其他人交流你的想法，有時候你的目的包括了上述兩者。就像你在圖1中看到的，這兩項實踐常常會一起引出另兩類的實踐，這是下文要讨論的主題。
最後，生産率類别中包括使用建模标準，逐漸應用模式，以及重用現有的資源這幾項實踐。重用現有資源這個實踐要求你盡量利用他人的工作成果并從中受益，這有很多種思考方向：一種是應用模式，根據經驗，我認為它是所有重用方法中最有效率的一種，因為你重用的都是其它開發人員久經驗證的解決方案 (Ambler, 1999)；另一種是遵循建模标準和指南，實際上，不論是标準還是指南，都能夠提高你工作的一緻性。是的，你可以自己寫指南，有時你必須要這麼做，因為你的實際環境中會有一些特别的情況。但是你隻需要在Internet上稍做搜索就可以找到很多的開發指南。例如，你可 javaCodingStandards找到Java的開發指南。
類别間的聯系
讓我們考慮團隊協作類别。簡單類别中的實踐增強了實踐stakeholder的積極參與的效果，因為簡單性消除了參與的代溝。叠代和遞增類别中的實踐也使得參與成為可能，尤其是并行創建模型，因為它增大了stakeholder們參加的機會。動機類别中的實踐可以提高集體所有制和和他人一起建模的效果，對問題的理解和溝通通常可以激發人們的協作精神，簡單類别的實踐也也坑達到激發協作效果，因為它降低了參與的門檻。公開展示模型的效果可以通過生産力類别中的實踐得到提高。遵循标準，應用模式的做法可以增加一緻性和可讀性，而重用現有的資源（例如通用架構），則給别人開了一個好頭，使别人能夠在你模型的基礎上繼續。叠代和遞增類的實踐可以支持集體所有制的實行，特别是并行創建模型和切換到另外的artifact，它們使得人們在适當的模型上共同開發。
簡單類别的實踐由另外幾類的實踐來輔助。使用建模标準和逐漸應用模式這兩項實踐支持同一種建模語言（使用标準和容易理解的模式），從而支持了實踐簡單地建模。文檔類别的實踐也可以支持簡單類别的實踐－－隻有到萬不得已才更新模型，這樣，你才不會給模型增加不必要的信息。才有可能創建簡單的内容以及簡單地建模。
現在再來看叠代和遞增類别。很明顯，團隊協作類别的實踐支持該類的實踐，由于團隊的參與，針對目前的情況選用正确artifact的機會就增大了，你就可以根據需要來切換使用不同的artifact。驗證類實踐能夠賦予你使用遞增方法的勇氣，特别是在你用代碼驗證的時候。保證你想法的易測性，你就更有把握同時操作多個artifact，并在它們之間切換，因為測試問題要求你從多個方面來看待它。文檔類實踐同樣可以促進遞增方法，特别是非到萬不得已不更新。但是合同模型要正式這個實踐抑止了遞增方法的應用，因為你總是希望能夠盡早的建立和其他系統間的接口标準。切換到另外的artifact和丢棄臨時模型之間也能産生正面的效果，因為一個模型完成目的之後就把工作切換到另一個模型上去。簡單類實踐對這個類别也很重要，通過使用最簡單的工具，你在不同的 artifact間來回切換就變得更容易了，你節省了熟悉工具的時間，隻把精力集中在簡單的内容和描述上，你也可以較容易記住模型要傳達的信息。最後，動機類實踐可以令你同時進行多個建模工作，因為對于複雜的系統，你需要從多個方面去溝通，去理解，因此你需要在适當的artifact間來回切換，這樣才能有效的做到這一點。
驗證類實踐可由簡單類實踐來支持－－創建簡單的内容和簡單地建模能使你更容易進行測試性思維。叠代和漸增類實踐也能提高驗證類實踐。例如，在你切換到另外的Artifact時，就可能切換到源代碼，這樣你就可以看到模型确實可以運行。
簡單類實踐可以推進生産力類實踐。當你使用簡單模型工作時，逐漸應用模式就更容易一些；當你簡單地建模時，使用建模标準也會容易一些，而模型的簡單、易懂，也會使你比較容易的重用現有的資源，例如企業需求模型或通用的架構模型。
簡單類實踐以及叠代和漸增類實踐可以支持文檔類實踐的進行。文檔越簡單就越容易使用－－如果你的文檔容易理解，這樣你就有把握萬不得已才更新你的文檔，因為你知道做到這一點很簡單；文檔如果很複雜，你的項目風險就很大，因為沒有把握什麼時候文檔需要更新。很明顯，非到萬不得已不更新和丢棄臨時模型的運作環境可以其它的實踐來改善，例如切換到另外的artifact、小增量建模。
合格的敏捷建模者
敏捷建模者的個性
Alistair Cockburn指出：很多的方法學都定義了軟件開發項目中開發人員所擔任的角色，同時還定義個各個角色執行的任務，盡管入席，這些方法并沒有定義這些角色最适合的人選。一個人要想成功的擔任某個角色，他應當很好的适應它－－雖然這并不需要人們掌握所有的技能，但人們必須要慢慢的熟悉這些技術。我的經驗告訴我，要成為一個成功的敏捷建模者，下面的列出的個性是必要的：
◆團隊競賽 第一點，也是最重要的一點，敏捷建模者總是積極的尋求協作，因為他們意識到他們不是萬事通，他們需要不同的觀點，這樣才能做到最好。軟件開發可不是遊泳，單幹是非常危險的。在敏捷的字典中沒有“我”這個詞。
◆暢所欲言 敏捷建模者都有良好的溝通技巧－－他們能夠表達出他們想法，能夠傾聽，能夠主動獲取反饋，并且能夠把需要的寫出來。
◆腳踏實地敏捷建模者應當腳踏實地 他們的精力都集中在滿足用戶的需求上，他們不會在模型上畫蛇添足，即便那雙足是多麼的好看。他們滿足于提供可能的方案中最簡單的一種，當然，前提是要能夠完成工作。
◆好奇 敏捷建模者樂衷于研究問題，解決問題。
◆凡是都問個為什麼 敏捷建模者看問題從不會至于表面，而是會打破沙鍋問到底。他們從不會就想當然的認為一個産品或一項技術和它們的廣告上說的那樣，他們會自己試一試。
◆實事求是 敏捷建模者都非常的謙遜，他們從不認為自己是個萬事通，所以他們會在建立好模型之後，用代碼來小心的證明模型的正确。
◆勇氣 敏捷建模者應當願意去計劃一個想法，然後做出模型，再想辦法用代碼來驗證。如果結果不理想，他們就會返工，檢查他們的方法，或是放棄原先的想法。把你的想法告訴你的同伴，再來驗證它的正确，這是需要很大的勇氣的。
◆根據實驗 敏捷建模者應當願意嘗試新的方法，例如一項新的（或是已有的）建模技術。一般而言，他們也會接受敏捷建模開發技術，必要時，為了驗證想法，他們願意同傳統的思想做鬥争，例如在一個項目中減少文檔數量。
◆有紀律 要堅持不懈的遵循敏捷建模的實踐。對你來說，你可能會在不經意間說，“加上這個功能吧！無傷大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏離方向，是需要一定的紀律性的。
通才還是專才?
當你要增加團隊成員時，所要處理的一個至關重要的問題是你希望保持的通才和專才的比率。要回答這個問題，你需要考慮現代軟件開發環境。圖1是企業統一過程（Enterprise Unified Process EUP）的生命周期。（譯注：原文中并沒有提供這副圖，根據我的猜測，應該就是RUP的概述部分的那張生命周期圖，但是因為沒有取得瑞理公司的授權，所以我暫時也不便引用這張圖，大家可以參閱RUP的相關資料。）圖左邊的EUP的工作流程暗示着軟件開發的複雜－－你需要進行業務建模，收集需求，分析和設計系統等等－－而這還隻是冰山一角。就像圖中列出的那樣，從先啟到産品化的各個階段，預示着在項目的過程中，不同的時間需要你集中于不同的地方，這需要不同的技能。有一個觀點是很明确的，軟件開發非常的複雜，任何一項工作都需要高超的技能和豐富的經驗。首要的，要認識到這種複雜性是軟件開發與身俱來的，而不是EUP使然的，即便你的團隊采用的是XP方法，抑或是DSDM（Stapleton, 1997）方法，或是SCRUM （Beedle & Schwaber, 2001）方法，這種複雜性也還是存在的。盡管這些方法的生命周期看上去并不像EUP那樣的複雜，但它們仍然需要配置管理活動，需要管理活動等等，隻是它們處理問題的态度不同而已。
很多的組織對此的第一反應就是建立一個專才的團隊。專才的最基本的含義是指那些特别精通某一項任務的人，因此他們的效率也特别的高。這樣一支團隊，要想高效率的運作，你需要組合這些專才，讓每人負責一塊任務，解決之後就把手頭的工作傳給另一個人。這個概念就類似于“流水線”的想法，如果你是在大量的生産汽車，這種方式會非常的有效，但是以我的經驗，在手工的軟件中采用這種方式并不是太合适。而且，這種方式需要一個大團隊的支持－－如果軟件開發中有N中不同的任務，你至少就需要N位專才才能滿足這種方法的要求。但N是多大？20？50？100？這取決于你對專業定義的細節程度，是吧？如果你傾向于每位開發人員隻處理一種artifact，那單單處理建模工作，就需要20多位的專才，在modeling artifacts essay列出了各種的artifact。如果你傾向于每位開發人員隻負責一種角色，那再一個EUP的項目中也需要11中角色才能完成所有的工作流程。專才通常都很難同人合作，他們缺少謙遜的品質，意識不到其它人的專項技能能夠為他的工作增添價值，他們也意識不到他們的所作所為可能為給後續的工作造成麻煩，也許他們需要返工，也許他們現在的努力會白費。關于專才的另一個問題是，即使是在他們擅長的領域，他們的技能也可能根本就沒有那麼精熟。IT産業的技術高變動率，導緻了開發人員使用了幾個月的新技術，開始熟悉它，就聲稱自己已經是這方面的專家了，因為和他具有同樣層次經驗的人畢竟不多。要建立一個專才組成的團隊，這也是一個很明顯的問題。
那麼，建立一支僅有通才的團隊會怎樣呢？每個人都對軟件開發有不錯的了解，但是都缺乏足夠詳細的必需知識，完成不了工作。項目需要那些對現階段使用的技術和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans (EJB)，那你既需要對Java編程精通的人，也需要對EJB開發精通的人。一個使用Oracle的團隊，幕後肯定有一位Oracle數據庫管理專家。一個開發經紀人業務軟件的團隊，就需要一位能夠了解股票和債券之間的細微差别的人。
我的經驗是，兩種極端的方式都不可取，你應該取它們的中間點。一種方法是團隊中一部分人是通才，一部分人是專才。通才能夠起到團隊的連接劑的作用，通才注重遠景，專才注重項目的具體的難點。這樣做的好處是通才的長處能夠彌補專才的短處，反之也是一樣，由于這種平衡性，通才和專才組對能夠發揮出極大的優勢。一個更好的方法是團隊中主要是通才，僅有一兩個專才。例如，我認為我應該算是一個通才，我擅長于處理項目中各項技能之間的配合，而且還精通業務應用軟件建模，以及對象存儲和Java編程。我的另一位同事也是位通才，特别擅長建模，EJB開發，以及測試。還有一位堪稱通才的同事則精于網絡通信和Java編程。這樣一支由通才組成，但又有一項或多項特技的團隊，優勢是很明顯的，他們能夠迅速的找到共同點，因為他們畢竟都是通才，而且他們之間有能夠做到優勢互補。它的劣勢在于這種人才一般都比較稀缺，動辄都需花費10年甚至20年的時間才能夠培養出這種通才，因此是很難得到的。如果你的團隊中有一些這種人，那你的運氣真是太好了。要認識到新手通常一開始都是專才，這很重要。軟件開發的新手面對着需要消化的大量知識，往往不知所措，這很正常。大多數人一開始一開始會把精力集中在開發的一兩個方面，也許是Java編程，也許是獲取用戶需求，然後以這方面的經驗為基礎，再逐漸的拓展知識的覆蓋面。随着時間的增長，經驗在不斷的累積，他們會慢慢的完善自己的技能樹，他們會軟件開發中各個技能如何配合會更加了解，同時，他們還擅長于一兩門特技。
還有一點也很重要，要明白很多的開發人員的專精反而害了這些人。由于軟件開發的與身俱來的複雜性，開發人員經常會落入一個名為單一artifact開發者的陷阱中去，他們把自己定位為僅僅從事一種artifact的開發工作，例如代碼，用例模型，或數據模型；開發人員還可能遇到的一個陷阱名為單一角色開發者，他們的定位是專門從事一種工作的人，例如建模，測試，或編碼。換言之，這些人專精于某一個角色，這種傾向在一些的采用傳統過程的大型組織中特别顯著，問題就出現了，這些陷阱的落入者的視野往往過于狹窄，難以在一個采用敏捷方法的軟件開發項目中作到高生産率。當然，如果他們原意擴展自己的視野，這個問題就容易得到解決。
建模的誤區
走出一般性的設計誤區，邁向成功之途 無論你遵從的是重量級的方法，比如Enterprise Unified Process(EUP)，還是輕量級的開發過程，如Extreme Programming(XP)，建模在軟件開發中都是不可或缺的。但不幸的是其中充斥着各種謬誤與迷思。這來自于各個方面，有從理論家錯誤的研究、數十年來信息技術領域内的文化沉積、軟件工具開發商天花亂墜半的市場宣傳以及象Object Management Group (OMG)和IEEE這類組織的标準。這個月，我要揭示建模中的誤區，指出其相應的事實真相。
誤區一：建模就等于是寫文檔
這很可能是其中最具破壞力的一條，因為開發人員可以此為借口而完全放棄建模。許多優秀的軟件開發人員會說他們不想把時間浪費在這些“無用的“文檔上。他們沉溺于編碼之中，制造着一些脆弱而劣質的系統。另外，甚至于許多盡責的開發人員現在也認為建模是一件讨厭的事，而不願去學習相應的建模技術。
事實分析：“模型”與“文檔”這二者在概念上是風馬牛不相及的—你可以擁有一個不是文檔的模型和不是模型的文檔。一幅設計圖就是一個模型，而不論是被畫在餐巾紙的背面，或寫在一塊白闆上，或在Class Responsibility Collaboration(CRC)卡片中，還是根據記錄在報紙和便簽紙上的流程圖而生成的一個粗略的用戶界面原型。雖然這些都不能說是文檔，但他們卻都是有價值的模型。
建模很象是作計劃：作計劃的價值在于計劃編制的過程中，而非計劃本身；價值體現在建模的活動中，而非模型本身。實際上，模型不是你系統中的一部分正式的文檔，而且在完成它們的使命後可以被丢掉。你會發現值得保留的隻有很少的模型，而且它一定是非常完美。
誤區二：從開始階段你可以考慮到所有的一切
這種說法流行于二十世紀七十年代到八十年代早期，現今的許多經理都是在那個時候學習的軟件開發。對這一點的迷信會導緻在前期投入可觀的時間去對所有的一切建模以期把所有一切都弄正确，試圖在編碼開始前就“凍結”所有的需求（見誤區四），以緻于患上“分析期麻痹症” – 要等到模型非常完美之後才敢向前進。基于這個觀點，項目組開發了大量的文檔，而不是他們真正想要得到的—開發滿足需要的軟件。
事實分析：怎麼才能走出這個誤區呢？首先，你必須認識到你不能考慮到所有的細枝末節。第二，認識到編碼員可能會對建模者的工作不以為然（這是可能的，事實上建模者所作的工作在實際價值中隻占很少的部分），他們或許會說模型沒有反應出真實的情況。第三，認識到不管你的最初所作的規格說明書有多好，但注定代碼會很快地與之失去同步，即便是你自己建模自己編碼。一個基本的道理就是代碼永遠隻會和代碼保持一緻。第四，認識到叠代法（小規模地建模，編一些代碼，做一些測試，可能還會做一個小的工作版本）是軟件開發的準則。它是現代重量級的軟件開發過程（如EUP），以及輕量級（如XP)的基本原理。
誤區三：建模意味着需要一個重量級的軟件開發過程
走入這個誤區（經常與誤區一有聯系）的項目組常常是連建模都徹底地放棄了，應為這樣的軟件開發過程對他們來說太複雜太沉重了。這不亞于一場天災。
事實分析：你可以用一種敏捷的方式取而代之。關于用簡單的工具進行簡單地建模的詳細内容可參看Agile Modeling(AM)。而且，你可以丢棄你的模型當使命完之後，同樣也可以很基本的方式進行建模（比如，從辦公桌起來，來到白闆前就開始構略草圖）。隻要你願意，你就可以輕松地建模。
誤區四：必須“凍結”需求
這個要求常常來自高級經理，他們确切地想知道他們從這個項目組能得到什麼東西。這樣的好處就是在開發周期的早期确定下需求，就可以确切地知道所要的是一個什麼樣的東西；缺點就是他們可能沒有得到實際上所需要的。
事實分析：變化總會發生的。由于優先級的變化和逐漸對系統有了更進一步的理解，都會引起需求的變化。與凍結需求相反，估計項目成功的風險，盡量去接受變化而且相應地采取行動，就象XP所建議的一樣。
誤區五：設計是不可更改的
如同誤區四，要求每一個開發人員必須嚴格遵從“設計“，導緻開發人員為了符合“設計“而作了錯誤的事情或以錯誤的方式作正确的事情。或者是簡單地忽略了設計，否定了所有設計可能帶來的好處。凍結了設計，你就不能從在項目進程中所學到知識進一步獲益。另外一個很大的趨勢就是開發出大量的文檔而不是實際的軟件，使用面向文檔的CASE工具而不是能給項目帶來實際價值的面向應用的工具。
事實分析：事實上，設計會經常根據開發人員和數據庫管理員的反饋進行修改，因為他們是最接近實際應用的人，通常他們對技術環境的理解要好于建模者。我們必須的面對這樣一個事實：人無完人，他們所作的工作也不可能盡善盡美。難道您真的想将一個并不完善的設計固定下來而不再去修改其中的錯誤嗎？另外，如果需求并沒有被凍結，其實就意味着你不能凍結你的設計，因為任何需求的修改勢必影響設計。對之，正确的态度是：隻要你的代碼還在改動，涉及就沒完。
誤區六：必須使用CASE工具
建模常常被認為是一項複雜的工作，因此需要大量地使用CASE工具輔助進行。
事實分析：是的，建模可以是很複雜的。但你完全可以建立一個有效而簡單的模型表述其中關鍵的信息，而不是将一些無關緊要的細節包括進來。
比如，我經常使用UML建立模型來表示類、它們的屬性及一些關鍵的業務操作，但并不畫出屬性的存取操作(get和set)，以及維護與其它類關系的框架代碼，或者其他一些瑣碎的實現細節。我通過建模尋找解決問題的方法，讓我和我的同事能繼續前進去實現這個模型。以這樣靈活的方式，大多數情況下我并不需要一個CASE工具來支持建模工作，一塊白闆，或者一台數字相機足以。這樣，我就不用花時間去評估CASE工具，不用去和工具供應商讨論許可證的問題，也免去了人員培訓開銷。CASE工具隻有當它能體現最佳性價比時（相對你自己的情況而言），才值得購買。大多數情況下，我都能不用它而達到目的（完成建模）。我經常使用的工具有Together/J(http://www.togethersoft.com/) – 因為它能産生數目可觀的Java框架代碼；還有ERWin（http://www.cai.com/） -- 因為它能規劃數據庫。這兩個工具真正地幫助我實現了軟件開發的目的 – 制造滿足用戶要求的軟件。但我絕大多數得建模工作仍然使用的是簡單的工具，而不是CASE工具。
誤區七：建模是在浪費時間
許多新手都這樣認為，這主要是因為他們所接受的教育僅僅局限于如何編寫代碼，對于完整的開發流程鮮有接觸。而且他們的經驗也僅限于如何實現代碼，就如初級程序員。他們放棄了提高效率和學習技能的機會，這些技能能夠使他們很容易地适應不同的項目或組織。他們應該為此感到羞愧。
事實分析：在大多數情況下，在開始編碼之前畫一個草圖、開發一個粗率的原型或者制作一些索引卡片都能提高你的生産效率。高效的開發者在編碼之前都要進行建模工作。另外，建模是一種很好的在項目組成員與項目負責人之間溝通途徑。你們在這個過程中探讨問題，從而對所要的是一個什麼樣的東西可以得到更好的理解，涉及到該項目中的每個成員也可得到對該項目有一個從分的了解。
誤區八：數據模型(Data Model)就是一切
許多組織基于數據模型就蹒跚啟動新的開發工作，也許正如你所在的組織：IT部門對于數據有非常嚴格的規定，控制着你的開發項目；或者你以前的數據庫是一團糟，别無選擇。
事實分析：數據模型是一個重要的但不是最重要的建模，它最好是建立在另外的模型之上。（參見“Extreme Modeling”，Thinking Objectively，Nov.2000）。這即使在象數據倉庫這類面向數據的項目中也如此。如果沒有很好的理解用戶是如何使用該數據倉庫的（在數據模型中沒有表示出來），這些項目經常是以可悲的失敗而告終。你可以使用的模型有很多 – 使用案例（use cases），業務規則（business rules），activity diagrams，類圖（class diagrams），component diagrams，用戶界面流程圖（user interface flow diagrams）和CRC，等等。數據模型僅僅是其中的一種。每種模型都有其長處和短處，應該正确地使用。
誤區九：所有的開發人員都知道如何建模
我們現在面臨照這樣一個嚴重的問題：許多不是開發人員的人，包括高級經理和用戶，不知道軟件是如何建成的。其結果，他們不能夠區分開熟練的開發者和一般的程序員（當然也分不清高級程序員和一般程序員），他們想當然地認為所有的開發人員都具備從頭到尾開發整個系統的技能。
事實分析：這肯定是不正确的。建模的技能，是隻有當一個開發者通過學習它，并經過長期的實踐才能夠掌握。一些非常聰明的程序員常常相信自己無所不能，畢竟他們終究隻是程序員。正因為這樣的狂妄自大，他們承當的一些任務是他們根本就沒有相應的技能去完成的。軟件開發是如此的複雜，單單一個人是很難具備所有的技能去成功地進行開發，甚至也不可能去配置有一定複雜程度的系統。開發這應該有自知之明，明白他們自己的弱點，學無止境。通過互相取長補短，建模者可從程序員身上學到一項技術的具體細節，程序員也可從建模者那裡學到有價值的設計和體系結構的技術。我個人認為所有的人，包括我自己，都是新手。
