部分的接受AM。你可以尽可能多的接受AM中的原则和实践，虽然你不会真正的实现AM，但你极有可能成为高效率的开发人员。一旦你的组织发现这确不失为一个软件开发的好方法，那就有可能会主动的去改变一些必需的要素，从而完全的接受AM。一言以蔽之，循序渐进的实现AM。
放弃让你的组织接受AM。从我个人的角度，我并不喜欢这种选择，但我不得不承认它是个正确的办法。现实就是这样，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中有详细的讨论。
文章来源于领测软件测试网 https://www.ltesting.net/
