在软件开发中，敏捷建模方法防止了目标的偏离并且使实践者思路清晰，随时准备好进入到下一步工作步骤。在日常工作中引进敏捷建模的精益方法、表示形式和相关技术并不需要额外的开支。
 
    这个技巧为做好建模提供了秘诀，其中包括五个最佳实践，这是我这在David Allen的GTD（尽管去做）一书中首次阐述外部的一些概念时学到的。我还查阅了一些历史依据，看看是谁在什么时候总结出了敏捷建模的实践；像数据一致编程、数据建模和统一建模语言（UML）。

    敏捷建模的平衡混合图表和文本或代码有利于同事或者项目干系者之间的沟通。另一方面，在建模过程中不使用或者肤浅地使用精益方法，符号扩散会在后面的项目中出现，这些项目起初是以精益建模开始，之后就变得臃肿了。也许这就是为什么软件行业通常还是没有多少“图形编程”的原因。

    在敏捷开发中少既是多，那多少才足够好呢？今天IT业几乎和其他行业一样成熟，并且GTD作为应用在这里也很合适。模型大小和细节必须在同事之间允许反复走查、更新和交流。当然，基于PC的工具突破了这种限制，就像主流的GTD，但是它们又无法消除这些限制。进一步自动化——从UML图或业务流程执行/模拟的生成代码——一方面通常需要更多的模型细节；但另一方面，也要有一个结构，一个表现形式模型来抑制符号扩散。

　　如果这个项目只用几个基本的图表类型，自动化就更容易。在很多应用中，完整的类图和状态图——包括发送和接受消息/事件——足以生成代码。其他的图表用于改善架构、文档、协定、需求沟通等等，而不只是生成代码。

　　一个经常被忽视的GTD诀窍是对组件、Web服务、扩展平台、高级的LINQ函数、开源程序等等的普通封装。即使模式和特定领域建模（DSM）很接近这一点，但是常常需要额外的内容填充。一旦这个功能是可用而且可靠的，它可以用在任何需要的地方，而无需重新建模。如果不是因为所有一致性的结构化程序里面都充满了通常应该是在编译器、代码生成器、数据库引擎（图2）或者操作系统中处理的，该功能的存在将是不言而喻的。另外，还要留意充斥着对象交互的UML图，这些UML图通常也应该是已经在SQL存储过程、LINQ查询、Java Hibernate/C#的N-Hibernate或者其他什么地方处理的。

　　建模的五个架构经验法则

1. 保持敏捷和牢记GTD。相对于只能供专家阅读的极其细致的模型，最新精简的模型能被广泛阅读和理解，具有更多的价值。
2. 对象设计的核心是要保持懒惰。你可以打电话让邻居去处理。正如GTD所建议的：重用以前的设计，让设计的结果做到“一劳永逸”。复杂程度可以比我们认识到的有更频繁的封装、测试和隐藏。
3. 考虑一下这些模式和特有领域模型时不要被它们困扰。即使它们不完全适合，仍然可以用它们的方法完成点工作。
4. 怀疑，挣扎和成本往往来自过去在高级/业务级表达式和组件的测试工具中遇到的问题。如果你的情况确实如此，就要早点考虑它们的优先级。在故障检测，测试，权威的声明表达或高层功能的动画等方面找到一些良好参考的工具。能直观地看到在运行期间组件或表达执行是如何提高可用性和可接受性。这在业务流程模型中同等重要。
5. 预先建立一个系统边界。明确规定每个项目团队要设计什么，什么不需要立即着手去做。注意UML用例图在审视交互式应用中能良好工作，但其他技术也是如此。