摘要： 我坚信这样一个观点：在描述一件事物的时候，不管它是一个系统还是像这里讨论的AM这样一个方法，都应该不仅描述它是什么，而且也描述它不是什么。下面几点刻画了AM范畴：AM是一个属性，而不是一个指令性过程。AM由下面几部分组成：一组敏捷建模人员坚持的价值观、敏捷建模人员相信的原则和敏捷建模人员使用的实践。AM描述了一种建模的风格，当它被正确地用在敏捷的环境中时，它能在避免过渡简化和不切实际的期望的同时，产生质量更高的软件和促进更快速的开发。AM不是一本开发的菜谱--如果寻求的是创建UML顺序图或者用户界面流程图的详细指导，那么需要在本书后面参考文献中列出的很多书中挑选一本。AM是对现有方法的一个补充 阅读全文

摘要： 为了理解AM，需要理解模型和敏捷模型之间的区别。模型是一个抽象，它描述问题的一个或多个方面，或者一个可能的解决问题的方法。模型在传统上被认为是几张图加上对应的文档，其实CRC卡、一个或多个业务规则的文字描述、业务过程的结构化英语描述等非图形制品也是模型。敏捷模型是一个刚刚够好的模型，但怎么能知道一个模型什么时候是足够好的呢？当一个敏捷模型展现下述特征的时候它就是足够好的：敏捷模型满足了创建者的目的。有时候建模是为了交流，例如，可能需要把项目的范围汇报给高级管理层；有时建模是为了理解，例如，可能需要确定实现一组Java类的设计策略。一个合格的敏捷模型必须满足创建它的目的。敏捷模型是易于理解的。敏 阅读全文