敏捷建模的补充原则定义了用来提升敏捷建模人员效率的一些概念。虽然这些原则支持第3章中描述的核心原则，但采纳它们并不是真正进行敏捷建模的先决条件。这些原则都是很好的想法，如果它们能够适合你所在的公司文化，你就应该采纳它们，敏捷建模的补充原则包括：
- 内容比形式更重要
- 每个人都可以向别人学习
- 了解你的模型
- 适应本地情况
- 开发和诚实的交流
- 相信直觉
1.内容比形式更重要
任何一个给定的模型都有多种表示方法。比如，要创建一个AUI的规格说明书，可以在一大张纸上贴一些即时贴（基本/低精度的原型），可以在纸上或白板上画个草图，可以是使用原型工具或编程语言建立起来的“传统”原型，也可以是包括可视界面和文字描述的正式文档。这取决于建立该模型的目的，这些不同的表现形式可能是等价的。如果目的是研究HTML页面的布局，那么这些表示方法都是足够的。事实上，采用画图工具把规格说明书弄得更漂亮，以及用文档详尽地描述它，对于这个目的都毫无帮助。在这里，内容比形式更重要。
本原则的一个重要含义是，不必一开始就使用复杂的CASE工具，的确，CASE工具在帮你生成代码或从现有代码有逆向工程导出可以理解的模型方面是很有用的，但是刚开始最好还是用些简单灵活的工具。将在第10章中予以详细阐述。
让我们考虑以下这个例子。一个UML类图可以画成如图4-1所示中的草图的样子，或是如图4-2所示那样用Microsoft Visio等画图工具画出，或是用别的复杂CASE工具完成。但它仍旧是同一个类图，只不过在描绘上不同而已。就它的目的而言草图或许是足够的了，因为它帮助了绘制它的人理解他们如何开始软件设计的第一步。不能把图4-1放在正式文档中吗？为什么不行呢？它虽说没有工具画出来的图4-2那样好看，但绘制它只需要后者三分之一的时间。请记住，敏捷建模人员总是最大化项目关系人的投资，因此仅仅为了让东西变得好看而花费时间是值得认证对待的问题。我认为即使在正式文档中使用了手工绘制的草图，世界末日也不会到。我常常在正式文档或演讲中使用扫描过的草图或草图的数字照片，这些草图记录了我要交流的想法，我不愿意仅仅为了让它变得漂亮些而浪费时间把它眷写到复杂的工具里。让别人看看不那么完美的工作也没关系，为自己只做必须做的最少的工作然后继续前进的决定辩护也是正确的。很显然这个模型并不完整，老实说，我写的字糟透了，但是请记住，敏捷的建模人员是带着目的建模的，而且只要目的达到就停手。
提示 满足读者的期望
在文档中包括手工绘制的图是否可行取决于读者：如果他们是“循规蹈矩”的人，那么可能要花些时间用电子工具来眷写模型。这没什么不对的，毕竟你是在花他们的钱，但应当承认你的确有更敏捷的选择，同时应该让他们意识到这一点。
类似地，图4-1和图4-2中同样的类结构也可以用其他类型的制品来描述，如CRC卡，或是采用其他表示方法，例如OMT方法（Rumbaugh et. al. 1991）。话说到这里，我不会选择OMT方法而放弃UML方法，原因很简单，UML是业界标准而OMT不是。是的，或许在技术上OMT要胜过UML，但很可能由于它没有采用通用标准而造成交流上更大的损失。
一个有趣的隐含的意义是模型未必一定要是文档。我可以画出如图4-1所示那样的草图，只是为了理解我正在从事的类的结构，接下来编码和测试这些类，然后一旦完成工作就丢弃这个模型。即使是用CASE工具创建的复杂的图也未必会成为文档的一部分，它们可能被用作其他制品的输入，极有可能是源代码，但它们永远不会正式化成官方文档。问题的要点是利用建模的好处又不会为创建和维护文档花费资源。本原则的激发因素是敏捷建模简单和交流的价值观以及敏捷联盟（2001a）关于能运行的软件优于详尽的文档的优先顺序。
2.每个人都可以向别人学习
敏捷建模人员承认他们永远不可能真正成为某些领域的大师，学习更多东西和扩展知识面的机会永远是存在的。他们利用和他人合作的机会向对方学习，尝试解决问题新的途径，反思那些失败或成功的案例。科技与时俱进，现有的技术如Java正义炫目的步伐演进，而同时新技术如C#和.NET也在不断引入。现有的开发技术也在演化，尽管速度慢一些但仍然在发展。作为一个产业，我们理解测试的基本要素已经有一段时间了，尽管我们仍然在通过研究和实践来不断地提高自己的理解。重要的是，我们生存在一个这样的环境中，这里变化是日常的惯例，这样必须抓住每一个机会，通过培训、教育、辅导、阅读和与他人合作来学习新的做事方式。
本原则的另一层含义就是人人都应该期望通过与他人的合作来从对方身上学习新的技能。事实上，我认为你有责任帮助他人来增强他们的知识工具箱。本原则的激发因素是交流和谦虚的价值观。
3.了解你的模型
作为一名敏捷建模人员，在实际中有多个模型可以运用，因此需要了解这些模型各自的优缺点，以便达到更有效运用它们的目标。另外，建模技术也在不断地演进以反映技术的变化。如果面向方面编程（Aspect-Oriented Programming,AOP）（XEROX 2001）变得更加主流，我认为我们将不得不学习一个或多个面向方面的模型和/或现有模型的面向方面扩展。因为这样既可以让模型尽量保持简单，又能提高在应用这些建模技术的项目中的交流质量。
4.适用本地情况
AM是否能“拿出来就用”是值得怀疑的。相反，你需要修改它来反映环境，这里的环境包括所处组织的特点、同事、项目关系人和所从事的项目本身。在修改AM来满足这些特殊需求的时候，你必须审视这些即将打算采用的建模技术。举个例子，客户可能坚持用具体的用户界面，而不是初步的草图或基本的用户界面原型。你所采用的工具将影响工作的方式。或许没有买一个数码相机的预算，但是有现有CASE工具的许可证。可以修改AM来反映它所应用的软件过程。第三部分将讨论如何把AM应用到XP项目中，第四部分将介绍怎样在统一过程项目中使用AM。
不仅在项目级别上，而且在个人级别上也要调整你的工作方式。例如，有些开发人员喜欢某一套开发工具胜过其他工具。比如，在我用Java编程时，我便爱复杂的代码编辑器和JDK，而我的同事可能喜欢Java IDE（集成开发环境）。有的人将注意力放在编码上而只做很少的建模，但其他更喜欢图形化东西的人则倾向于在编码之前花更多的时间画图。不同的人，运用AM的方式自然不同。请注意，这里价值观、原则和实践仍然是相同的，不同的只是应用场合而已。
同时，正如第1章中说过的，AM并不是万能的，它不可能在所有的地方都适合。试图完全采用AM有可能是不现实的，至少眼下是不现实的，因此你可能会发现可以剪裁AM中的一部分原则和实践，并把它们运用到已有的软件过程中去。只要能提高你作为开发人员的工作效率，这样做就没有任何问题。
5.开放和诚实的交流
人们需要在自由并且知道自己是自由的情况下才能提出建议来，这些建议包括与一个或多个模型有关的想法。或许有人对解决设计的某一部分问题有了新的方案，或许他对需求有了新的认识，或许只是一种新的介绍当前工作状态的方法。开放和诚实的交流使人们能够做出更好的决策，因为这些决策来源于更精确的信息。
开放和诚实的交流需要每个人的投入以及一个共识，即有效的交流是软件开发项目是否成功的一个关键因素。那些敢于直抒胸臆的人必须能够倾听逆耳之言。每个人都需要谦虚，在听到自己最得意的想法可能没有最初想象的那么好的时候能够做到放弃它。
6.相信直觉
有人感觉某个东西将不能运转，或者几个事物之间出现了不一致，或者就是觉得某个东西不对劲，这倒真的很有可能是事实。随着软件开发经验的增长，你的直觉越来越敏锐，而直觉下意识地告诉你的东西往往成为建模工作的一个重要输入。如果直觉告诉你某个需求毫无意义或者并不完备，那么你应该和客户再研究一番。如果直觉告诉你架构的某个部分不能满足要求，那么你应该去构建一个快速的端到端原型来测试这一理论。如果直觉告诉你设计方案A要比方案B好，而同时又没有理由非选其中哪一个不可的话，那么选A吧。很重要的一点是AM勇气的价值观指出，即使将来某个时刻你发现自己的直觉错了，仍然可以补救整个情况。
7.从这些原则中获益
除非把它们融为自己的一部分，否则本章和第3章所讲到的这些原则和那些善意的劝告也没有太大的区别。敏捷建模人员接纳这些原则并按照它们来行动，这其实是说起来容易做起来难的事。我不知道如何能保证你们的确和这些原则融为一体，我能做的就是要求你们认证考虑并在可能的情况下尽量遵循它们。我把AM的要旨--包括价值观、原则和实践总结起来放在一个小册子里，可以从AM的网站（www.agilemodeling.com）上下载，把它打印出来，三张表在同一页上，然后张贴在你的工作区域的墙上。这或许对你有帮助，至少值得一试。
作者：银月莲
出处：http://www.cnblogs.com/moonsilvering
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，包括文章，代码，图片等本站内所有资源，否则保留追究法律责任的权利。
