敏捷模型要尽可能的简单。只要能够达到目的，你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性，而所使用的符号范围也会影响简单性。例如，UML的类图就包括了无数的符号，包括对象约束语言 (Object Constraint Language OCL) ，但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号，你可以限制自己使用符号的一个子集，当然，这个子集是足够让你完成工作的。
因此呢，一个敏捷模型的定义就是一个实现它的目的，没有画蛇添足的模型；为你的预期听众所理解的模型；简单的模型；足够正确、足够一致、足够详细的模型；创建和维护它的投资能够给项目提供正面价值的模型。
一个普遍的哲学问题是源代码是不是一个模型，更重要的，它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的－－敏捷模型帮助你得到源代码。
模型何时是敏捷的？
要想了解AM，你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念，它描述了一个的问题的一个或多个方面，或是处理这个问题可能的解决方案。传统意义上，模型被认为是图表加上相应的文档。然而那不够直观的artifact，也可以被视为模型，例如CRC卡片集，单条或多条业务规则的文字描述，或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢？当敏捷模型显现出如下的特性时，它就是刚刚足够好的：
敏捷模型实现了它们的目的。有时你为沟通而建模，或许你需要把你工作的范围告诉高级经理；有时你为理解而建模，或许你需要确定一个设计策略，实现一组Java类。一个敏捷模型是否足够好，要看它是不是满足了创建它时的初衷。
敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型，反之，技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性－－如果你的用户不了解UML用例图中的符号的含义，那用例图对用户就没有任何价值。这样的话，要么使用另一种方法，要么教授用户学习建模技术。风格问题同样也会影响易懂性，例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度（见下文），也会影响易懂性，因为相较一个不那么详细的模型来说，一个过于详细的模型要难于理解。简单（见下文）同样是影响易懂性的一个因素。
敏捷模型是足够正确的。模型通常都不需要100%正确，只要足够正确就行了。举个例子，如果一张街道地图漏画了一条街道，或是它标示某条街道是通行的，但你发现它已经关闭维修了，那你会不会扔掉你的地图开始在城里飙车犯罪呢？不太可能。你会考虑更新你的地图，你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图（你原来的那张过期了）。也许你还是会接受那张虽不完美仍可使用的地图，因为它对你来说已经足够好了。你还是可以用这张地图四处转转，因为它还是个正确的模型，标记出了大部分街道的位置。你在发现这张地图不正确的时候，你没有立刻扔掉它，原因是你根本不在乎它是否完美。类似的，当你在需求模型、数据模型中发现错误的时候，你也会选择更新或是接受－－虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能：这取决于项目的特性，每个团队成员的特性，组织的特性。充分正确性既和模型的听众有关，也和你要处理的问题有关。
我十几岁的时候在一家餐馆打工，开始是洗盘子，到后来升为出纳。在我做出纳时，我要学习如何关店。关店最重要的一件事就是清点钱柜。教我的那个店长认定一定要把钱柜的每一分钱都点清楚，如果和销售的数字有出入的话，就要重复点。因为不但要点清纸币，还要点清硬币，所以平均每晚都要花20分钟的时间。几个月后，她调到了另一家店，换了一位新店长。一天晚上我们一起关店，他看见我在一个一个的数硬币，他非常的吃惊。他马上演示了一下他是怎么数硬币的，他把同类的硬币抓在手上，看了看，猜了一个数值，只要它们的总价值在几美元之内，他就继续这样点。20分钟的时间被压缩到5分钟，因为他认为数字只要接近就可以了，并不需要非常的精确。他每天可以提早15分钟回家，按照一周6个晚上，一年50周计算，他一年能够节省75个小时，而他的职业生涯已经30年了
敏捷模型是足够一致的。一个敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例，那么相应的用例图需要用UML的 <<Include>>版型来标记这两个用例之间的关系。然而，你看了看图表，发现它们并没有这样做，天哪！用例和图之间不一致！危险！太危险了！红色警报！快逃命呀！等一下，你的用例模型是有不一致的地方，但也没到世界末日啊。是的，理想情况下，你的所有artifact最好是能够完全一致，但这通常是不可能的。当我开发一个简单的商用系统时，我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的测量系统。要树立一个观点，敏捷模型只要足够一致就行了，你通常不需要使用那么完美的模型。
关于正确性和一致性，很明显要考虑权衡问题。如果你要维护一个artifact（我们称之为“保管”），随着时间的流逝，你需要投入资源来更新它。否则它很会就会过期，对你就没用了。例如，我可以容忍一张地图标错了一两条街道，但是我绝对无法容忍一张地图中四分之三的街道都标错了。这就需要权衡了，进行足够的努力，保证artifact足够正确。过多不必要的努力反而会减缓项目的进度，而投入不足就没有办法保证artifact的有效性。
敏捷模型有足够的细节。一张路线图并不需要标记出每条街道上的每栋房子。那会有太多的细节，使得地图难以使用。然而，在修路的时候，我想施工人员一定会有这条街道的详细地图，包括每幢建筑、下水道、电线盒等足够的细节，这样的地图才是有用的。但是这张地图并不用标记出每个院子和通向它们的路线。因为这样又太繁琐了。足够的细节和听众有关，也和他们使用模型的目的有关－－司机需要的是显示道路的地图，施工人员需要的是显示土木工程细节的地图。
考虑一个架构模型，可能一组画在白板上的图表就足够了－－项目的进行中再对它们更新，也许你需要用CASE 工具来生成一些图表，也许这些图表还需要有详细的文档，这依赖于环境。不同的项目有不同的需要。在每一个例子中，实际上你都是在开发、维护一个有足够的细节的架构模型，只是这个“足够的细节”的概念和环境有关。
敏捷模型能提供正面价值。对项目中的任一artifact，一个基本的要求是它们能够提供正面价值。一个架构模型给你的项目带来的价值是不是能够超过开发它、维护它（可选）的总成本？一个架构模型能够坚定你们团队为之努力的愿景，所以它当然是有价值的。但是，如果它的成本超过了这个价值，那就是说，它无法提供正面价值。投入100,000美元去开发一个详细的、重量级的文档化架构模型，而它的效用，只需一些画在白板上的图表就能够达到，这些图只需要花你5,000美元，看看，这是多么轻率的做法。
敏捷模型要尽可能的简单。只要能够达到目的，你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性，而所使用的符号范围也会影响简单性。例如，UML的类图就包括了无数的符号，包括对象约束语言 (Object Constraint Language OCL) ，但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号，你可以限制自己使用符号的一个子集，当然，这个子集是足够让你完成工作的。
因此呢，一个敏捷模型的定义就是一个实现它的目的，没有画蛇添足的模型；为你的预期听众所理解的模型；简单的模型；足够正确、足够一致、足够详细的模型；创建和维护它的投资能够给项目提供正面价值的模型。
一个普遍的哲学问题是源代码是不是一个模型，更重要的，它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的－－敏捷模型帮助你得到源代码。
你是在敏捷建模吗?
敏捷开发方法所面临的最大的挑战就是开发人员声称自己遵循了这种方法，而实际上他们并没有这么做。当他们运作出了问题的时候，他们就会去责备方法不好，但其实他们根本就没有真正遵循过这些方法。在极限编程(eXtreme Programming XP)就有这样的例子，一些编程狂宣称他们完全遵循XP所有的原则，但实际上仅仅是他们听到的关于XP的一小部分内容，如你不需要这么多文档。他们的产品要么质量低劣，要么根本就不能满足实际用户需求，但他们将这一切的失败都归罪于XP，真是不公平！
我很想避免此类问题在AM上出现，但这只是一个理想。现实中，我力所能及的只是能指出你在什么情况下是在以敏捷的方式建模，什么情况下不是。
什么情况下，你是在敏捷建模?
你的客户/用户都能够积极的参与需求建模，分析建模工作。
接受需求的变化，并遵照变化了的需求行事——不存在“需求冻结”。
根据Project Stakeholder定下的优先级顺序，首先解决优先级最高的需求；在随后的工作进展中，集中解决风险最大的问题。
你采用迭代、递增的方法建模。
你的精力主要集中于软件的开发，而不是文档或模型本身。
注重团队协作精神，欢迎任何人提出意见或建议。
尽可能地做到简单——使用你可以获得的最简单的工具；使用能够胜任的最简单的模型。
随着开发的进展，你的大部分（不是所有的）模型都会被丢弃（而不作为正式的文档保存下来）。
客户/业务组织拥有业务决定权，开发人员拥有技术决定权。
大家都一致认为模型的内容比内容的格式/表现手法要重要的多。
在你建模的时候，需要不断考虑的一个关键问题是你该如何测试该模型所描述的内容。
什么情况下，你不是在敏捷建模?
你的目的是产生文档，例如需求文档，并且，这些文档需要一个或几个Project Stakeholder签字认可。
你使用CASE工具进行软件的架构搭建和设计，但却没有进一步在此基础上自动地产生部分或全部的代码。
你的客户/用户和你一起工作的时间很有限。比如，他们加入项目需求的初始开发阶段，但时间非常有限，只是回答一些问题；然后就会撤出；然后在迟些时候再参加一个或几个对你工作的接受审查。
你一次只专注于一种模型。最常见的例子就是“用例建模会议”，“类建模会议”或是“数据建模会议”。这种问题产生的最根本的原因就是“单一的artifact开发者”。例如专门进行数据建模的人，专门进行用户界面建模的人。而在AM中，每个人都是多面手，都能够胜任这项工作。
你工作的方式是做好一个模型以后再做下一个模型－也就是说，你是采取一种“serial”的方法工作。
你所在小组仅负责模型的设计或文档的编写，当完成这些模型或文档后再将其交付给另外的小组进行下一步的开发工作。也就是说，你是以一种“serial”的方式来“传出（handing off）”你的工作。
敏捷建模何时是有（没有）意义的?
何时合适AM运作?
但这不是我的情形...
何时不合适AM运作?
何时敏捷建模是适合你的?
敏捷建模不是万能的，它并不适合于每一个人、每一种情况。即使是你的条件非常适合于AM，也不能保证它就能良好的运行——你在组织内实施AM时还是有可能犯下错误。我的经验是，在以下条件满足时，AM极有可能发挥其效力：
软件开发采用了敏捷方法。AM不是一门完整的方法学，它只是某个软件开发流程中的一部分应用。要成功应用AM，你所采用的开发流程的观念必须要与AM的观念相匹配（译注：XP与AM匹配，而CMM与AM就不匹配）。否则，你只是在片面的运用AM中的几项技术，而不是真正的配置了AM。
采用迭代式、递增式的开发方式。做为AM的两项实践，有效的沟通（communication）和反馈（feedback）要求软件开发采用迭代和渐增的方法。
需求不确定或不稳定。Martin Fowler在他的新方法学中指出，如果你的项目就像是自然探险（大多数项目都如此），那最佳的选择就是采用敏捷方法来开发软件。当需求不明或易变时，你就应该采用一种能够适应这种情况的开发方式。AM拥抱变化，它采用递增的开发方式，寻求快速的反馈，并且一贯坚持Project Stakeholder的积极参与，这就是AM对付需求变化的法子。使用AM，你就能够迅速而有效地发觉客户的需求。
开发软件是你的主要目标。这是AM的核心原则之一，但对很多项目来说，这并不是他们的目标。例如，有时候一个项目团队的主要目标是从客户那里圈钱（在外部采购中时有发生），或是简单的制定系统规范，因为系统要交付给另一个团队去实现。更糟的是，一些项目仅仅是出于政治上的考虑，它的目的就是让别人感到他们正在做这件事，至于要做出来什么东西却根本没有考虑。软件开发的目标应该是生产出满足客户需求的有效的软件系统－如果你的目标不是这样，AM就不适合你。
你需要有stakeholder的积极支持和参与。Fowler同样认为，敏捷软件开发工作要想成功，需要有project stakeholder的积极支持和参与。Project Stakeholder是那些受软件项目的开发和/或部署潜在的影响的人。包括直接用户，非直接用户，经理，高级经理，操作人员，支持人员，测试者，和这个系统有关（整合或交互）的其它系统的开发人员，以及维护人员。AM要想成功，你需要了解你的Project Stakeholder是谁，你还要能够和Stakeholder保持日常的接触，Stakeholder能够及时的为你提供信息、做出决策。此外，还应该要有管理层的大力支持。
开发团队能够自我决策。敏捷软件开发，特别是敏捷建模，对大多数的组织来讲都是新生事物。接受敏捷方法对大多数的组织来讲都是一件很难的事，因为它对大多数人来说都是一种新的工作方式。想要成功，我的经验是，不管成功还是失败，要根据项目团队的优点，给他们机会。鼓励他们尝试新技术，给他们资源（包括时间），让他们开始学习。应该尽量杜绝玩弄权术的现象，这就意味着组织中的管理层和一些部门要改掉原来的做法。
要有真正的AM斗士。不论何时，接受新的事物总会面临着挑战。人们不愿意改变，他们喜欢、他们也习惯了以前那种繁琐的慢节奏的工作方式。他们和你看事情的角度不同，你希望引入敏捷方法来解决问题，而他们不认为那是问题。也许他们会改进自己喜爱的开发方法，但这些方法和AM格格不入。也许，AM威胁到他们在组织内的权力分配。即使不考虑这些情况，也还是会有人抗拒变化。要想成功的改变，必须要有真正的AM斗士。他们支持AM，为AM奋斗，他们愿意去收集Project Stakeholder的支持，他们愿意进行AM思想的宣传和培育，让AM能够在组织内生根发芽。改变需要时间，这些斗士就是在争取时间。
你需要负责、主动的开发人员。Fowler指出敏捷软件开发强调开发人员的纪律性，要求开发人员能够协同工作，开发高质量的软件。这意味着你需要一个健康的团队环境，人们能够相互信任，相互帮助，共同迈向成功。和那些敏捷开发方法的诋毁者告诉你的完全相反，你需要的人并不是一个个都要求能上天入地。根据我的经验，你的要求很简单：愿意完成工作，有合作精神，能够有效工作。
你需要有足够的资源。你现在知道了敏捷建模需要人们的紧密合作。就是说你需要“协同开发的空间”，例如能够使人专注于工作的建模室，一堵能够演示模型的公用墙，最好还能给每对开发人员配置一台共享工作站。除此之外，你还需要有足够的建模工具，例如白板、索引卡片、标记、和其它必须的CASE工具。我就曾经看过由于基本资源（像样的椅子，桌子，食物，饮料，和高端工作站）的缺乏，使软件开发工作的进展受到阻碍。如果你的项目团队因为这些锱铢之事导致失败，那我倒是想问问你这项目对你的组织是不是真的那么重要。如果不是，那就cancel它，把你的精力投入到其它更有价值的项目中去吧。
但这不是我的情况....
那么，当其上的一个或某些条件和你目前的情况有出入的时候，你该怎么办？试着去改变你目前的情况。缺乏AM的拥护者吗？那你自己就可以成为一个拥护者。不允许以迭代式和递增的方式工作，和你的老板们谈谈，让他们相信这是一种更好的工作方式，要求他们给你一个机会去证明。没有足够的资源？和你的头儿说明它们的重要性。如果你已经尽力改变了所有的情况，但是仍然还有一些条件是你无能为力的，你可以试试以下的选择：
部分的接受AM。你可以尽可能多的接受AM中的原则和实践，虽然你不会真正的实现AM，但你极有可能成为高效率的开发人员。一旦你的组织发现这确不失为一个软件开发的好方法，那就有可能会主动的去改变一些必需的要素，从而完全的接受AM。一言以蔽之，循序渐进的实现AM。
放弃让你的组织接受AM。从我个人的角度，我并不喜欢这种选择，但我不得不承认它是个正确的办法。现实就是这样，AM并不是适合每一个人的，也许你的组织确实是不适合接受AM的。
跳槽。看看外面的世界，还是有很多的组织期望能够从软件开发的竞赛中获胜，他们希望能有积极主动的软件开发人员加盟。
何时敏捷建模是不适合你的?
我猜想敏捷建模在遭遇如下的情形的时候你会陷入麻烦：
不满足以上列出的一个或多个条件。
你的组织文化适合采用传统的开发流程。许多组织对采用敏捷的软件开发方法毫无兴趣，他们对目前的状况感觉很好。这主要是那些政府部门、大型的公司（银行、保险公司、电信公司）以及专门为这些组织服务的咨询公司。这并不是说在这类组织中实施AM完全不可能，但要获得成功则要付出超乎寻常的努力才行。
你的团队很大，分布在各地。只有那些在同一个工作区域中相互协作的团队才能很好的进行敏捷建模的工作，特别是当开发人员在一个公共的工作室内合作的时候（通常我们称之为“tiger team”房间）。你可以尝试着在一个大型或分散的团队中应用敏捷方法，我在架构建模中讨论了这种情形，但你很快会发现你需要挑战这种方式带来的沟通问题。
我不同意将敏捷方法应用于性命攸关的系统上，例如航空管制系统或医疗监测系统，因为我并没有相关的项目经验，无法去研究AM应该怎样应用于这些系统。同样，我也没有嵌入式系统的相关经验，因此我也没有机会将AM技术应用于这种类型的项目。我很怀疑AM是否能够试用于嵌入式软件开发，这是我研究的一部分。我很期待你在敏捷建模的邮件列表中告诉我相关的经验。（详情请访问http://www.agilemodeling.com/feedback.htm）
AM的实践是如何组合的
AM的实践之间是相互促进的，因为他们彼此支持，彼此激发。为了使AM更有效率的工作，你需要了解它的实践是如何组合的。图1显示了AM的实践之间的关系，它们被分为七类。AM的核心实践集中在头四种类别中－验证，迭代和递增，团队协作，和简单，你需要完全接受它们才能真正理解敏捷建模。然后，才轮到属于辅助实践的文档，动机，生产率这三个类别。我们先针对核心实践的四个类别，讨论各类中的实践之间的关系，然后我们再针对辅助实践的三个类别，研究各类中实践之间的关系，最后我们来讨论类别之间的关系。
图1. AM的实践是如何组合的。
核心实践
文章来源于领测软件测试网 https://www.ltesting.net/
