我坚信这样一个观点：在描述一件事物的时候，不管它是一个系统还是像这里讨论的AM这样一个方法，都应该不仅描述它是什么，而且也描述它不是什么。下面几点刻画了AM范畴：

AM是一个属性，而不是一个指令性过程。AM由下面几部分组成：一组敏捷建模人员坚持的价值观、敏捷建模人员相信的原则和敏捷建模人员使用的实践。AM描述了一种建模的风格，当它被正确地用在敏捷的环境中时，它能在避免过渡简化和不切实际的期望的同时，产生质量更高的软件和促进更快速的开发。AM不是一本开发的菜谱--如果寻求的是创建UML顺序图或者用户界面流程图的详细指导，那么需要在本书后面参考文献中列出的很多书中挑选一本。

AM是对现有方法的一个补充，它不是一个完整的方法。AM的主要焦点是建模，第二个焦点是文档，仅此而已。AM技术应该被用来提高遵循XP、SCRUM和Crystal Clear（Cockburn 2001b）等敏捷方法的项目团队的建模工作。AM也可以被用到统一过程等指令性过程中，虽然在这样的情况下，它的成功将取决于这个过程的敏捷性。

AM是对其他建模过程的补充。ICONIX（Rosenberg and Acott 1999）和Catelysis（D’Souza and Wills 1999）等建模方法重点放在如何创建某种制品的细节上，详细解释怎样着手应用用例、健壮图、构件图等制品，为了有效建模的高层实践不是它们的重点，而这正是AM所针对的。我的经验是，AM和其他的建模方法能很好地一起工作，我丝毫不怀疑有一天会在市场上看到名为“敏捷建模与ICONIX”和“敏捷建模与Catalysis”的书。

AM是一种通过有效地一起工作来满足项目关系人需求的方法。敏捷开发人员和他们的项目关系人像一个团队一样地工作，项目关系人在系统开发中扮演着一个直接和积极的角色。套用一句大家都知道的话；在“敏捷”里没有“我”。

AM是有效的，并且是关于如何有效地工作的。在更多地了解了AM以后，应该有一个强烈的感受，AM总是不留情面地集中精力在有效的工作上。AM告诉你：最大化项目关系人的投资、在有明确的目的并且理解模型或理解文档听众的需要时才去创建模型或文档、使用正确的制品去解决面对的问题以及尽可能地创建简单的模型。不做超出绝对最小需要的事情。

AM是面向实践的，它不是一个学术理论。AM的目标是描述以有效的方式建模系统的技术，这些技术对所面对的任务是高效而且够用的、很多AM技术我和Roni International公司（www.ronin-intl.com）的同事们已经使用了好几年的时间，这些技术都是我们在不同产业、各种类型的客户那里反复实践精炼过的，而且，从2011年2月开始，已经有几百个在敏捷建模电子邮件列表（www.agilemodeling.com/feedback.htm）上的实践者们研究和讨论过这些技术，他们认为这些技术是有效的。

AM不是银弹。敏捷建模是一种能够有效地提高很多软件开发专业人员工作的技术，仅此而已。它决不是能解决所有的开发问题的灵丹妙药。如果你努力工作、集中精力、从心里接受AM的价值观、原则和实践，那么作为一个开发人员你将极有可能提高工作效率。

AM是针对一般开发人员的，但它不是能人的替代品。AM的价值观、原则和实践都很容易理解，其中的很多可能你已经遵循了好多年，或者很久以前就希望能够遵循。不是非要有三头六臂才能应用AM技术，但确实需要有基本的软件开发技能。关于AM最难的一点就是它会督促你学习大量的建模技术，这时一个长时间持续的活动。学习建模刚开始可能看起来很难，实际上也确实是这样，但如果决定在一段时间只学习一种技术，你一定能成功。

AM不是对文档的一个抨击。敏捷建模人员创建的文档是最大化用于创建和维护上的投资。敏捷文档是尽可能地简单、尽可能地最少、有明确的与正在开发的系统直接相关的目的、有明确的听众并且听众的需要被很好地理解。

AM不是对CASE工具的一个抨击。敏捷建模人员使用提供积极价值的工具，这些工具使他们作为开发人员的工作更加有效，而且，他们总是使用能完成工作的最简的工具。

作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。