迭代和遞增類別中包括了使用合適的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們參加的機會。動機類別中的實踐可以提高集體所有制和和他人一起建模的效果，對問題的理解和溝通通�？梢约ぐl人們的協作精神，簡單類別的實踐也也坑達到激發協作效果，因為它降低了參與的門檻。公開展示模型的效果可以通過生產力類別中的實踐得到提高。遵循標準，應用模式的做法可以增加一致性和可讀性，而重用現有的資源（例如通用架構），則給別人開了一個好頭，使別人能夠在你模型的基礎上繼續。迭代和遞增類的實踐可以支持集體所有制的實行，特別是并行創建模型和切換到另外的artifact，它們使得人們在適當的模型上共同開發。
簡單類別的實踐由另外幾類的實踐來輔助。使用建模標準和逐漸應用模式這兩項實踐支持同一種建模語言（使用標準和容易理解的模式），從而支持了實踐簡單地建模。文檔類別的實踐也可以支持簡單類別的實踐－－只有到萬不得已才更新模型，這樣，你才不會給模型增加不必要的信息。才有可能創建簡單的內容以及簡單地建模。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
