敏捷模型是足夠一致的。一個敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一個用例在它的一個步驟中顯式的調用了另一個用例，那么相應的用例圖需要用UML的 <
關于正確性和一致性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為“保管”），隨著時間的流逝，你需要投入資源來更新它。否則它很會就會過期，對你就沒用了。例如，我可以容忍一張地圖標錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都標錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正確。過多不必要的努力反而會減緩項目的進度，而投入不足就沒有辦法保證artifact的有效性。
敏捷模型有足夠的細節。一張路線圖并不需要標記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建筑、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖并不用標記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽眾有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。
考慮一個架構模型，可能一組畫在白板上的圖表就足夠了－－項目的進行中再對它們更新，也許你需要用CASE 工具來生成一些圖表，也許這些圖表還需要有詳細的文檔，這依賴于環境。不同的項目有不同的需要。在每一個例子中，實際上你都是在開發、維護一個有足夠的細節的架構模型，只是這個“足夠的細節”的概念和環境有關。
敏捷模型能提供正面價值。對項目中的任一artifact，一個基本的要求是它們能夠提供正面價值。一個架構模型給你的項目帶來的價值是不是能夠超過開發它、維護它（可選）的總成本？一個架構模型能夠堅定你們團隊為之努力的愿景，所以它當然是有價值的。但是，如果它的成本超過了這個價值，那就是說，它無法提供正面價值。投入100,000美元去開發一個詳細的、重量級的文檔化架構模型，而它的效用，只需一些畫在白板上的圖表就能夠達到，這些圖只需要花你5,000美元，看看，這是多么輕率的做法。
敏捷模型要盡可能的簡單。只要能夠達到目的，你應當努力讓你的模型盡可能保持簡單。模型的詳細程度會影響簡單性，而所使用的符號范圍也會影響簡單性。例如，UML的類圖就包括了無數的符號，包括對象約束語言 (Object Constraint Language OCL) ，但大多數的圖使用符號的一部分就能夠完成。所以你常常不需要使用所有的符號，你可以限制自己使用符號的一個子集，當然，這個子集是足夠讓你完成工作的。
因此呢，一個敏捷模型的定義就是一個實現它的目的，沒有畫蛇添足的模型；為你的預期聽眾所理解的模型；簡單的模型；足夠正確、足夠一致、足夠詳細的模型；創建和維護它的投資能夠給項目提供正面價值的模型。
一個普遍的哲學問題是源代碼是不是一個模型，更重要的，它是不是一個敏捷模型。如果你是在我們這篇文章之外問我這個問題，我會回答說，是，源代碼是一個模型，雖然是一個高度細節化的模型，因為它是軟件的一個抽象。同時我還認為，優秀的代碼是一個敏捷模型。但在這里，我還需要把兩者區分開來，源代碼和敏捷模型還是有區別的－－敏捷模型幫助你得到源代碼。
你是在敏捷建模嗎?
敏捷開發方法所面臨的最大的挑戰就是開發人員聲稱自己遵循了這種方法，而實際上他們并沒有這么做。當他們運作出了問題的時候，他們就會去責備方法不好，但其實他們根本就沒有真正遵循過這些方法。在極限編程(eXtreme Programming XP)就有這樣的例子，一些編程狂宣稱他們完全遵循XP所有的原則，但實際上僅僅是他們聽到的關于XP的一小部分內容，如你不需要這么多文檔。他們的產品要么質量低劣，要么根本就不能滿足實際用戶需求，但他們將這一切的失敗都歸罪于XP，真是不公平！
我很想避免此類問題在AM上出現，但這只是一個理想�，F實中，我力所能及的只是能指出你在什么情況下是在以敏捷的方式建模，什么情況下不是。
什么情況下，你是在敏捷建模?
你的客戶/用戶都能夠積極的參與需求建模，分析建模工作。
接受需求的變化，并遵照變化了的需求行事——不存在“需求凍結”。
根據Project Stakeholder定下的優先級順序，首先解決優先級最高的需求；在隨后的工作進展中，集中解決風險最大的問題。
你采用迭代、遞增的方法建模。
你的精力主要集中于軟件的開發，而不是文檔或模型本身。
注重團隊協作精神，歡迎任何人提出意見或建議。
盡可能地做到簡單——使用你可以獲得的最簡單的工具；使用能夠勝任的最簡單的模型。
隨著開發的進展，你的大部分（不是所有的）模型都會被丟棄（而不作為正式的文檔保存下來）。
客戶/業務組織擁有業務決定權，開發人員擁有技術決定權。
大家都一致認為模型的內容比內容的格式/表現手法要重要的多。
在你建模的時候，需要不斷考慮的一個關鍵問題是你該如何測試該模型所描述的內容。
什么情況下，你不是在敏捷建模?
你的目的是產生文檔，例如需求文檔，并且，這些文檔需要一個或幾個Project Stakeholder簽字認可。
你使用CASE工具進行軟件的架構搭建和設計，但卻沒有進一步在此基礎上自動地產生部分或全部的代碼。
你的客戶/用戶和你一起工作的時間很有限。比如，他們加入項目需求的初始開發階段，但時間非常有限，只是回答一些問題；然后就會撤出；然后在遲些時候再參加一個或幾個對你工作的接受審查。
你一次只專注于一種模型。最常見的例子就是“用例建模會議”，“類建模會議”或是“數據建模會議”。這種問題產生的最根本的原因就是“單一的artifact開發者”。例如專門進行數據建模的人，專門進行用戶界面建模的人。而在AM中，每個人都是多面手，都能夠勝任這項工作。
你工作的方式是做好一個模型以后再做下一個模型－也就是說，你是采取一種“serial”的方法工作。
你所在小組僅負責模型的設計或文檔的編寫，當完成這些模型或文檔后再將其交付給另外的小組進行下一步的開發工作。也就是說，你是以一種“serial”的方式來“傳出（handing off）”你的工作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
