部分的接受AM。你可以盡可能多的接受AM中的原則和實踐，雖然你不會真正的實現AM，但你極有可能成為高效率的開發人員。一旦你的組織發現這確不失為一個軟件開發的好方法，那就有可能會主動的去改變一些必需的要素，從而完全的接受AM。一言以蔽之，循序漸進的實現AM。
放棄讓你的組織接受AM。從我個人的角度，我并不喜歡這種選擇，但我不得不承認它是個正確的辦法�，F實就是這樣，AM并不是適合每一個人的，也許你的組織確實是不適合接受AM的。
跳槽�？纯赐饷娴氖澜�，還是有很多的組織期望能夠從軟件開發的競賽中獲勝，他們希望能有積極主動的軟件開發人員加盟。
何時敏捷建模是不適合你的?
我猜想敏捷建模在遭遇如下的情形的時候你會陷入麻煩：
不滿足以上列出的一個或多個條件。
你的組織文化適合采用傳統的開發流程。許多組織對采用敏捷的軟件開發方法毫無興趣，他們對目前的狀況感覺很好。這主要是那些政府部門、大型的公司（銀行、保險公司、電信公司）以及專門為這些組織服務的咨詢公司。這并不是說在這類組織中實施AM完全不可能，但要獲得成功則要付出超乎尋常的努力才行。
你的團隊很大，分布在各地。只有那些在同一個工作區域中相互協作的團隊才能很好的進行敏捷建模的工作，特別是當開發人員在一個公共的工作室內合作的時候（通常我們稱之為“tiger team”房間）。你可以嘗試著在一個大型或分散的團隊中應用敏捷方法，我在架構建模中討論了這種情形，但你很快會發現你需要挑戰這種方式帶來的溝通問題。
我不同意將敏捷方法應用于性命攸關的系統上，例如航空管制系統或醫療監測系統，因為我并沒有相關的項目經驗，無法去研究AM應該怎樣應用于這些系統。同樣，我也沒有嵌入式系統的相關經驗，因此我也沒有機會將AM技術應用于這種類型的項目。我很懷疑AM是否能夠試用于嵌入式軟件開發，這是我研究的一部分。我很期待你在敏捷建模的郵件列表中告訴我相關的經驗。
AM的實踐是如何組合的
AM的實踐之間是相互促進的，因為他們彼此支持，彼此激發。為了使AM更有效率的工作，你需要了解它的實踐是如何組合的。圖1顯示了AM的實踐之間的關系，它們被分為七類。AM的核心實踐集中在頭四種類別中－驗證，迭代和遞增，團隊協作，和簡單，你需要完全接受它們才能真正理解敏捷建模。然后，才輪到屬于輔助實踐的文檔，動機，生產率這三個類別。我們先針對核心實踐的四個類別，討論各類中的實踐之間的關系，然后我們再針對輔助實踐的三個類別，研究各類中實踐之間的關系，最后我們來討論類別之間的關系。
圖1. AM的實踐是如何組合的。 
核心實踐
在團隊協作類別中有四項實踐－－stakeholder的積極參與，和他人一起建模，公開展示模型，和集體所有制。stakeholder的積極參與對你的成功至關重要，因為你正是為了這些project stakeholder開發系統，正是為了了解和實現他們的需求。換言之，你需要和你的甲方們密切合作，這就自然的想到了和他人一起建模－－這個“他人”也包括你的stakeholder。當你的建模工作有多人參加時（至少一個project stakeholder和一個除你之外的開發人員），你就需要和眾人共同協作，相互促進，取長補短。一個擅長于業務過程建模和業務規則定義的敏捷建模者看不到的方面，一個精通結構化建模技術（例如UML類圖或數據模型）的人極有可能看得到。一樣的道理，系統的直接用戶給你的團隊提供的信息極可能是高級經理提供不了的。所以，要有這樣的觀點：你要在項目甲方和開發團隊中營造一種積極參與的氛圍，只有這樣，才能夠收集各種不同的觀點和經驗。集體所有制能夠提升協作性，因為一個人單獨的進行建模的工作，他很快就會遇到瓶頸，而如果每個人都能夠為建模工作獻計獻策，那么你們就能夠成為一個團隊，輕易的解決問題。公開展示模型能夠使得人們對模型“瞻前顧后”變得容易了，能夠立刻考慮模型傳達的信息，從而提高團隊的協作性。當然，我們是假設模型都在眾人的視線之內，或者這些模型都是大家目前正在開發或相關的。這方面的主題我在Organizing an Agile Modeling Room中有詳細的討論。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
