AM不是靈丹妙藥。敏捷建模是改進眾多專家軟件開發成果的有效技術，充其量也就是這樣了。它并不是什么了不得的靈丹妙藥，能夠解決你開發中的所有問題。如果你努力的工作；如果你專注其上；如果打心眼兒里接受它的價值觀、它的原則、它的實踐；你就可以改進你做為一個開發人員的效果。
AM是面向一般的開發人員的，但并不是要排斥有能力的人。AM的價值觀、原則和實踐都簡單易懂，其中的很多內容，可能你都已經采用或期待多年了。應用AM技術并不是要你去練水上飄，但你需要有一些基本的軟件開發技能。AM最難的就是它逼著你去學習更廣泛的建模技術，這是個長期的、持續性的活動。學習建模在一開始可能很難，但你可以試著一次學習一樣技術來完成你的學習。
AM并不是要反對文檔。文檔的創建和維護都會增大項目涉眾的投資。敏捷文檔盡可能的簡單，盡可能的小，目的只集中在和目前開發的系統有直接關系的事情上，充分了解受眾的需要。
AM也不是要反對CASE工具。敏捷建模者使用那些能夠幫助開發人員提高效果，提升價值的工具。而且，他們還盡力使用那些能夠勝任工作的最簡單的工具。
AM并不適合每一個人。這一點在下面的列出的文章中會進一步討論。
模型何時是敏捷的？
要想了解AM，你需要了解模型和敏捷模型之間的區別。模型是一個抽象的概念，它描述了一個的問題的一個或多個方面，或是處理這個問題可能的解決方案。傳統意義上，模型被認為是圖表加上相應的文檔。然而那不夠直觀的artifact，也可以被視為模型，例如CRC卡片集，單條或多條業務規則的文字描述，或是業務流程的一段結構化英文描述。一個敏捷模型就是一個剛剛足夠好的模型。但是你怎么知道什么時候模型才是剛剛足夠好呢？當敏捷模型顯現出如下的特性時，它就是剛剛足夠好的：
敏捷模型實現了它們的目的。有時你為溝通而建模，或許你需要把你工作的范圍告訴高級經理；有時你為理解而建模，或許你需要確定一個設計策略，實現一組Java類。一個敏捷模型是否足夠好，要看它是不是滿足了創建它時的初衷。
敏捷模型是可理解的。敏捷模型要能為其預期聽眾所理解。使用用戶能夠理解的業務語言來描述需求模型，反之，技術架構模型則需要使用開發人員熟悉的技術術語。你所使用的建模符號會影響易懂性－－如果你的用戶不了解UML用例圖中的符號的含義，那用例圖對用戶就沒有任何價值。這樣的話，要么使用另一種方法，要么教授用戶學習建模技術。風格問題同樣也會影響易懂性，例如避免交叉線。雜亂的圖表比清晰的圖表難懂。模型的細節程度（見下文），也會影響易懂性，因為相較一個不那么詳細的模型來說，一個過于詳細的模型要難于理解。簡單（見下文）同樣是影響易懂性的一個因素。
敏捷模型是足夠正確的。模型通常都不需要100%正確，只要足夠正確就行了。舉個例子，如果一張街道地圖漏畫了一條街道，或是它標示某條街道是通行的，但你發現它已經關閉維修了，那你會不會扔掉你的地圖開始在城里飆車犯罪呢？不太可能。你會考慮更新你的地圖，你可能會拿出筆來自己做修改或是去當地的商店買一張最新版的地圖（你原來的那張過期了）。也許你還是會接受那張雖不完美仍可使用的地圖，因為它對你來說已經足夠好了。你還是可以用這張地圖四處轉轉，因為它還是個正確的模型，標記出了大部分街道的位置。你在發現這張地圖不正確的時候，你沒有立刻扔掉它，原因是你根本不在乎它是否完美。類似的，當你在需求模型、數據模型中發現錯誤的時候，你也會選擇更新或是接受－－雖不完美但已經足夠好了。有些項目成員能夠容忍這種不正確而有些則不能：這取決于項目的特性，每個團隊成員的特性，組織的特性。充分正確性既和模型的聽眾有關，也和你要處理的問題有關。
我十幾歲的時候在一家餐館打工，開始是洗盤子，到后來升為出納。在我做出納時，我要學習如何關店。關店最重要的一件事就是清點錢柜。教我的那個店長認定一定要把錢柜的每一分錢都點清楚，如果和銷售的數字有出入的話，就要重復點。因為不但要點清紙幣，還要點清硬幣，所以平均每晚都要花20分鐘的時間。幾個月后，她調到了另一家店，換了一位新店長。一天晚上我們一起關店，他看見我在一個一個的數硬幣，他非常的吃驚。他馬上演示了一下他是怎么數硬幣的，他把同類的硬幣抓在手上，看了看，猜了一個數值，只要它們的總價值在幾美元之內，他就繼續這樣點。20分鐘的時間被壓縮到5分鐘，因為他認為數字只要接近就可以了，并不需要非常的精確。他每天可以提早15分鐘回家，按照一周6個晚上，一年50周計算，他一年能夠節省75個小時，而他的職業生涯已經30年了
敏捷模型是足夠一致的。一個敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一個用例在它的一個步驟中顯式的調用了另一個用例，那么相應的用例圖需要用UML的 <>版型來標記這兩個用例之間的關系。然而，你看了看圖表，發現它們并沒有這樣做，天哪！用例和圖之間不一致！危險！太危險了！紅色警報！快逃命呀！等一下，你的用例模型是有不一致的地方，但也沒到世界末日啊。是的，理想情況下，你的所有artifact最好是能夠完全一致，但這通常是不可能的。當我開發一個簡單的商用系統時，我通常都可以容忍部分的不一致。但有時我是不能容忍這種不一致的。最有力的佐證就是1999年 NASA發射火星太空探測器時采用了精密的測量系統。要樹立一個觀點，敏捷模型只要足夠一致就行了，你通常不需要使用那么完美的模型。
關于正確性和一致性，很明顯要考慮權衡問題。如果你要維護一個artifact（我們稱之為“保管”），隨著時間的流逝，你需要投入資源來更新它。否則它很會就會過期，對你就沒用了。例如，我可以容忍一張地圖標錯了一兩條街道，但是我絕對無法容忍一張地圖中四分之三的街道都標錯了。這就需要權衡了，進行足夠的努力，保證artifact足夠正確。過多不必要的努力反而會減緩項目的進度，而投入不足就沒有辦法保證artifact的有效性。
敏捷模型有足夠的細節。一張路線圖并不需要標記出每條街道上的每棟房子。那會有太多的細節，使得地圖難以使用。然而，在修路的時候，我想施工人員一定會有這條街道的詳細地圖，包括每幢建筑、下水道、電線盒等足夠的細節，這樣的地圖才是有用的。但是這張地圖并不用標記出每個院子和通向它們的路線。因為這樣又太繁瑣了。足夠的細節和聽眾有關，也和他們使用模型的目的有關－－司機需要的是顯示道路的地圖，施工人員需要的是顯示土木工程細節的地圖。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
