敏捷模型是足够一致的。一个敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例，那么相应的用例图需要用UML的 <
关于正确性和一致性，很明显要考虑权衡问题。如果你要维护一个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）”你的工作。
文章来源于领测软件测试网 https://www.ltesting.net/
