AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”，如
果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍，我特别推荐我的书The Object Primer 2/e(尽管这有失公允)。
AM是对已有方法的补充，而不是一个完整的方法论。 AM的主要焦点是在建模上，其次是文档。也就是说，AM技术在你的团队采用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基础上能够提高建模的效果。AM同样也可以用于那些传统过程（例如Unified Process），尽管这种过程较低的敏捷性会使得AM不会那么成功。
AM是一种有效的共同工作的方法，能够满足Project Stakeholder的需要。敏捷开发者们和Project Stakeholder进行团队协作，他们轮流在系统开发中扮演着直接、主动的角色。在“敏捷”的字典中没有“我”这个单词。
AM是有效的，而且也已开始有效。当你学习到更多的AM知识时，有件事对你来说可能不好接受，AM近乎无情的注重有效性。AM告诉你：要使你的 Project Stakeholder的投资最大化；当有清晰的目的以及需要解了受众的需要时要建立模型或文档；运用合适的工件来记录手头的情形；不论何时都尽可能创建简单的模型。
AM不是灵丹妙药。敏捷建模是改进众多专家软件开发成果的有效技术，充其量也就是这样了。它并不是什么了不得的灵丹妙药，能够解决你开发中的所有问题。如果你努力的工作；如果你专注其上；如果打心眼儿里接受它的价值观、它的原则、它的实践；你就可以改进你做为一个开发人员的效果。
AM是面向一般的开发人员的，但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂，其中的很多内容，可能你都已经采用或期待多年了。应用AM技术并不是要你去练水上飘，但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术，这是个长期的、持续性的活动。学习建模在一开始可能很难，但你可以试着一次学习一样技术来完成你的学习。
AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单，尽可能的小，目的只集中在和目前开发的系统有直接关系的事情上，充分了解受众的需要。
AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果，提升价值的工具。而且，他们还尽力使用那些能够胜任工作的最简单的工具。
何时是敏捷的？
要想了解AM，你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念，它描述了一个的问题的一个或多个方面，或是处理这个问题可能的解决方案。传统意义上，模型被认为是图表加上相应的文档。然而那不够直观的artifact，也可以被视为模型，例如CRC卡片集，单条或多条业务规则的文字描述，或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢？当敏捷模型显现出如下的特性时，它就是刚刚足够好的：
敏捷模型实现了它们的目的。有时你为沟通而建模，或许你需要把你工作的范围告诉高级经理；有时你为理解而建模，或许你需要确定一个设计策略，实现一组Java类。一个敏捷模型是否足够好，要看它是不是满足了创建它时的初衷。
敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型，反之，技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性－－如果你的用户不了解UML用例图中的符号的含义，那用例图对用户就没有任何价值。这样的话，要么使用另一种方法，要么教授用户学习建模技术。风格问题同样也会影响易懂性，例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度（见下文），也会影响易懂性，因为相较一个不那么详细的模型来说，一个过于详细的模型要难于理解。简单（见下文）同样是影响易懂性的一个因素。
敏捷开发
敏捷模型是足够正确的。模型通常都不需要100%正确，只要足够正确就行了。举个例子，如果一张街道地图漏画了一条街道，或是它标示某条街道是通行的，但你发现它已经关闭维修了，那你会不会扔掉你的地图开始在城里飙车犯罪呢？不太可能。你会考虑更新你的地图，你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图（你原来的那张过期了）。也许你还是会接受那张虽不完美仍可使用的地图，因为它对你来说已经足够好了。你还是可以用这张地图四处转转，因为它还是个正确的模型，标记出了大部分街道的位置。你在发现这张地图不正确的时候，你没有立刻扔掉它，原因是你根本不在乎它是否完美。类似的，当你在需求模型、数据模型中发现错误的时候，你也会选择更新或是接受－－虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能：这取决于项目的特性，每个团队成员的特性，组织的特性。充分正确性既和模型的听众有关，也和你要处理的问题有关。
敏捷模型是足够一致的。一个敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例，那么相应的用例图需要用UML的 <> 版型来标记这两个用例之间的关系。然而，你看了看图表，发现它们并没有这样做，天哪！用例和图之间不一致！危险！太危险了！红色警报！快逃命呀！等一下，你的用例模型是有不一致的地方，但也没到世界末日啊。是的，理想情况下，你的所有artifact最好是能够完全一致，但这通常是不可能的。当我开发一个简单的商用系统时，我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的
测量系统。要树立一个观点，敏捷模型只要足够一致就行了，你通常不需要使用那么完美的模型。
关于正确性和一致性，很明显要考虑权衡问题。如果你要维护一个artifact（我们称之为“保管”），随着时间的流逝，你需要投入资源来更新它。否则它很会就会过期，对你就没用了。例如，我可以容忍一张地图标错了一两条街道，但是我绝对无法容忍一张地图中四分之三的街道都标错了。这就需要权衡了，进行足够的努力，保证artifact足够正确。过多不必要的努力反而会减缓项目的进度，而投入不足就没有办法保证artifact的有效性。
敏捷模型有足够的细节。一张路线图并不需要标记出每条街道上的每栋房子。那会有太多的细节，使得地图难以使用。然而，在修路的时候，我想施工人员一定会有这条街道的详细地图，包括每幢建筑、
下水道、电线盒等足够的细节，这样的地图才是有用的。但是这张地图并不用标记出每个院子和通向它们的路线。因为这样又太繁琐了。足够的细节和听众有关，也和他们使用模型的目的有关－－司机需要的是显示道路的地图，施工人员需要的是显示土木工程细节的地图。
考虑一个架构模型，可能一组画在白板上的图表就足够了－－项目的进行中再对它们更新，也许你需要用CASE 工具来生成一些图表，也许这些图表还需要有详细的文档，这依赖于环境。不同的项目有不同的需要。在每一个例子中，实际上你都是在开发、维护一个有足够的细节的架构模型，只是这个“足够的细节”的概念和环境有关。
敏捷模型能提供正面价值。对项目中的任一artifact，一个基本的要求是它们能够提供正面价值。一个架构模型给你的项目带来的价值是不是能够超过开发它、维护它（可选）的总成本？一个架构模型能够坚定你们团队为之努力的愿景，所以它当然是有价值的。但是，如果它的成本超过了这个价值，那就是说，它无法提供正面价值。投入100,000美元去开发一个详细的、重量级的文档化架构模型，而它的效用，只需一些画在白板上的图表就能够达到，这些图只需要花你 5,000美元，看看，这是多么轻率的做法。
敏捷模型要尽可能的简单。只要能够达到目的，你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性，而所使用的符号范围也会影响简单性。例如，UML的类图就包括了无数的符号，包括对象约束语言 (Object Constraint Language OCL) ，但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号，你可以限制自己使用符号的一个子集，当然，这个子集是足够让你完成工作的。
因此呢，一个敏捷模型的定义就是一个实现它的目的，没有画蛇添足的模型；为你的预期听众所理解的模型；简单的模型；足够正确、足够一致、足够详细的模型；创建和维护它的投资能够给项目提供正面价值的模型。
一个普遍的哲学问题是源代码是不是一个模型，更重要的，它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题，我会回答说，是，源代码是一个模型，虽然是一个高度细节化的模型，因为它是软件的一个抽象。同时我还认为，优秀的代码是一个敏捷模型。但在这里，我还需要把两者区分开来，源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码。
