敏捷建模

AM（敏捷建模）是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML 顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍，我特别推荐我的书The Object Primer 2/e(尽管这有失公允)。

AM是对已有方法的补充，而不是一个完整的方法论。 AM的主要焦点是在建模上，其次是文档。也就是说，AM技术在你的团队采用敏捷方法（例如eXtreme Programming，Dynamic Systems Development Method （DSDM），Crystal Clear）的基础上能够提高建模的效果。AM同样也可以用于那些传统过程（例如Unified Process），尽管这种过程较低的敏捷性会使得AM不会那么成功。

AM是一种有效的共同工作的方法，能够满足Project Stakeholder的需要。敏捷开发者们和Project Stakeholder进行团队协作，他们轮流在系统开发中扮演着直接、主动的角色。在“敏捷”的字典中没有“我”这个单词。

AM是有效的，而且也已开始有效。当你学习到更多的AM知识时，有件事对你来说可能不好接受，AM近乎无情的注重有效性。AM告诉你：要使你的 Project Stakeholder的投资最大化；当有清晰的目的以及需要解了受众的需要时要建立模型或文档；运用合适的工件来记录手头的情形；不论何时都尽可能创建简单的模型。

AM是来自于实践中，而不是象牙塔般的理论。AM的目标就是以一种有效的态度描述系统建模的技术，它有效率，足够胜任你手头的工作。我和我在Ronin International (http://www.ronin-intl.com) 的同事将大量的AM技术应用于实践已经很多年了，我们琢磨的这些技术应用于非常广泛的客户，他们遍布各个不同的工业领域。而且，从2001年2月开始，就有数百位的建模专家通过“敏捷建模邮件列表”(http://www.agilemodeling.com/feedback.htm) 对这些技术进行过充分的检查和讨论。

AM不是灵丹妙药。敏捷建模是改进众多专家软件开发成果的有效技术，充其量也就是这样了。它并不是什么了不得的灵丹妙药，能够解决你开发中的所有问题。如果你努力的工作；如果你专注其上；如果打心眼儿里接受它的价值观、它的原则、它的实践；你就可以改进你做为一个开发人员的效果。

AM是面向一般的开发人员的，但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂，其中的很多内容，可能你都已经采用或期待多年了。应用AM技术并不是要你去练水上飘，但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术，这是个长期的、持续性的活动。学习建模在一开始可能很难，但你可以试着一次学习一样技术来完成你的学习。

AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单，尽可能的小，目的只集中在和目前开发的系统有直接关系的事情上，充分了解受众的需要。

AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果，提升价值的工具。而且，他们还尽力使用那些能够胜任工作的最简单的工具。

AM并不适合每一个人。

一、敏捷建模的价值观

AM的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

沟通. 建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。

简单. 画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

反馈. Kent Beck在Extreme Programming Explained中有句话讲得非常好：“乐观是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

勇气. 勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构（refactor）你的工作，修正你的方向。

谦逊. 最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

二、敏捷建模的原则

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。

核心原则：

主张简单. 当从事开发工作时，你应当主张最简单的解决方案就是最好的解决方案。不要过分构建（overbuild）你的软件。用AM的说法就是，如果你现在并不需要这项额外功能，那就不要在模型中增加它。要有这样的勇气：你现在不必要对这个系统进行过分的建模（over-model），只要基于现有的需求进行建模，日后需求有变更时，再来重构这个系统。尽可能的保持模型的简单。

拥抱变化. 需求时刻在变，人们对于需求的理解也时刻在变。项目进行中，Project stakeholder可能变化，会有新人加入，也会有旧人离开。Project stakeholder的观点也可能变化，你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行，项目环境也在不停的变化，因此你的开发方法必须要能够反映这种现实。

你的第二个目标是可持续性. 即便你的团队已经把一个能够运转的系统交付给用户，你的项目也还可能是失败的－－实现Project stakeholder的需求，其中就包括你的系统应该要有足够的鲁棒性（robust ），能够适应日后的扩展。就像Alistair Cockburn常说的，当你在进行软件开发的竞赛时，你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版，或是你正在构建的系统的运转和支持。要做到这一点，你不仅仅要构建高质量的软件，还要创建足够的文档和支持材料，保证下一场比赛能有效的进行。你要考虑很多的因素，包括你现有的团队是不是还能够参加下一场的比赛，下一场比赛的环境，下一场比赛对你的组织的重要程度。简单的说，你在开发的时候，你要能想象到未来。

递增的变化. 和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上，你就算想这么做也不太可能。而且，你不用在模型中包容所有的细节，你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型，你只要开发一个小的模型，或是概要模型，打下一个基础，然后慢慢的改进模型，或是在不在需要的时候丢弃这个模型。这就是递增的思想。

令Stakeholder投资最大化. 你的project stakeholder为了开发出满足自己需要的软件，需要投入时间、金钱、设备等各种资源。stakeholder应该可以选取最好的方式投资，也可以要求你的团队不浪费资源。并且，他们还有最后的发言权，决定要投入多少的资源。如果是这些资源是你自己的，你希望你的资源被误用吗。

有目的的建模.对于自己的artifact，例如模型、源代码、文档，很多开发人员不是担心它们是否够详细，就是担心它们是否太过详细，或担心它们是否足够正确。你不应该毫无意义的建模，应该先问问，为什么要建立这个artifact，为谁建立它。和建模有关，也许你应该更多的了解软件的某个方面，也许为了保证项目的顺利进行，你需要和高级经理交流你的方法，也许你需要创建描述系统的文档，使其他人能够操作、维护、改进系统。如果你连为什么建模，为谁建模都不清楚，你又何必继续烦恼下去呢？首先，你要确定建模的目的以及模型的受众，在此基础上，再保证模型足够正确和足够详细。一旦一个模型实现了目标，你就可以结束目前的工作，把精力转移到其它的工作上去，例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型：如果你要做一些改变，也许是一个熟知的模式，你应该有做出变化的正确理由（可能是为了支持一项新的需求，或是为了重构以保证简洁）。关于该项原则的一个重要暗示是你应该要了解你的受众，即便受众是你自己也一样。例如，如果你是为维护人员建立模型，他们到底需要些什么？是厚达500页的详细文档才够呢，还是10页的工作总览就够了？你不清楚？去和他们谈谈，找出你想要的。

多种模型.开发软件需要使用多种模型，因为每种模型只能描述软件的单个方面，“要开发现今的商业应用，我们该需要什么样的模型？”考虑到现今的软件的复杂性，你的建模工具箱应该要包容大量有用的技术（关于artifact的清单，可以参阅AM的建模artifact）。有一点很重要，你没有必要为一个系统开发所有的模型，而应该针对系统的具体情况，挑选一部分的模型。不同的系统使用不同部分的模型。比如，和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具，而是一次使用某一件工具。又比如，你可能会比较喜欢某些工具，同样，你可会偏爱某一种模型。有多少的建模artifact可供使用呢，如果你想要了解这方面的更多细节，我在Be Realistic About the UML中列出了UML的相关部分，如果你希望做进一步的了解，可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。

高质量的工作.没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望。

快速反馈.从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。

软件是你的主要目标. 软件开发的主要目标是以有效的方式，制造出满足project stakeholder需要的软件，而不是制造无关的文档，无关的用于管理的artifact，甚至无关的模型。任何一项活动（activity ），如果不符合这项原则，不能有助于目标实现的，都应该受到审核，甚至取消。

轻装前进.你建立一个artifact，然后决定要保留它，随着时间的流逝，这些artifact都需要维护。如果你决定保留7个模型，不论何时，一旦有变化发生（新需求的提出，原需求的更新，团队接受了一种新方法，采纳了一项新技术...），你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型，很明显，你实现同样的改变要花费的功夫就少多了，你的灵活性就增强了，因为你是在轻装前进。类似的，你的模型越复杂，越详细，发生的改变极可能就越难实现（每个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的好处（所以才需要加强团队之间，团队和project stakeholder之间的沟通）。千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子，质地优良的鞋子，水壶。如果他带了几百加仑的水，能够想象的到的所有求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？同样的道理，一个开发团队决定要开发并维护一份详细的需求文档，一组详细的分析模型，再加上一组详细的架构模型，以及一组详细的设计模型，那他们很快就会发现，他们大部分的时间不是花在写源代码上，而是花在了更新文档上。

补充原则：

内容比表示更重要.一个模型有很多种的表示方法。例如，可以通过在一张纸上放置即时贴的方法来建立一个用户界面规格（基本/低精度原型）。它的表现方式可以是纸上或白板上的草图，可以是使用原型工具或编程工具建立和传统的原型，也可以是包括可视界面和文本描述的正式文档。有一点很有意思，一个模型并不一定就是文档。它们通常作为其它artifact的输入，例如源代码，但不必把它们处理为正式的文档，即使是使用CASE工具建立的复杂的图表，也是一样。要认识到一点，要利用建模的优点，而不要把精力花费在创建和维护文档上。

三人行必有我师.你不可能完全精通某项技术，你总是有机会学习新的知识，拓展知识领域。把握住这个机会，和他人一同工作，向他人学习，试试做事的新方式，思考什么该做，什么不该做。技术的变化非常的快，现有的技术（例如Java）以难以置信的速度在改进，新的技术（例如C#和.NET）也在有规律的产生。现存开发技术的改进相对会慢一些，但也在持续的改进中－－计算机产业属于工业，我们已经掌握了其中的试验基本原理，但我们还在不断的研究，不断的实践，不断的改进我们对它的了解。我们工作在一个变化是家常便饭的产业中，我们必须通过训练、教育、思考、阅读、以及和他人合作，抓住每一个机会学习新的处事之道。

了解你的模型.因为你要使用多种模型，你需要了解它们的优缺点，这样才能够有效的使用它们。

了解你的工具.软件（例如作图工具、建模工具）有各种各样的特点。如果你打算使用一种建模工具，你就应当了解什么时候适合用它，什么时候不适合用它。

局部调整. 你的软件开发方法要能够反映你的环境，这个环境包括组织特征，project stakeholder的特征，项目自身的特征。有可能受其影响的问题包括：你使用的建模技术（也许你的用户坚持要看到一个细节的用户界面，而不是初始草图或基本原型）；你使用的工具（可能你没有数字照相机的预算，或是你已经拥有某个CASE工具的license）；你遵循的软件过程（你的组织采用XP的开发过程，或是RUP，或是自己的过程）。因此你会调整你的方法，这种调整可能是针对项目的，也可能是针对个人的。例如，有些开发人员倾向于使用某一类工具，有些则不用。有些人在编码上花大力气，基本不做建模，有些则宁可在建模上多投入一些时间。

开放诚实的沟通.人们需要能够自由的提出建议，而且人们还应该能够感受到他们是自由的。建议可能是和模型有关的想法：也许是某些人提出某部分新的设计方法，或是某个需求的新的理解；建议还可能是一些坏消息，例如进度延误；或仅仅是简单的工作状况报告。开放诚实的沟通是人们能够更好的决策，因为作为决策基础的信息会更加准确。

利用好人的直觉.有时你会感觉到有什么地方出问题了，或是感觉什么地方有不一致的情况，或是某些东西感觉不是很对。其实，这种感觉很有可能就是事实。随着你的软件开发的经验的增加，你的直觉也会变得更敏锐，你的直觉下意识之间告诉你的，很可能就是你工作的关键之处。如果你的直觉告诉你一项需求是没有意义的，那你就不用投入大量的精力和用户讨论这方面的问题了。如果你的直觉告诉你有部分的架构不能满足你的需要，那就需要建立一个快速技术原型来验证你的理论。如果你的直觉告诉设计方法A要比设计方法B好，而且并没有强有力的理由支持你选择某一个方法，那就尽管选择方法A。勇气的价值就已经告诉你，如果未来证实你的直觉是错的，你也有能力来挽救这种情况。你应该有这种自信，这很重要。

三、敏捷建模的实践

敏捷建模（AM）在AM原则的基础上定义了一组核心实践（practice）和补充实践，其中的某些实践已经是极限编程（XP）中采用了的，并在Extreme Programming Explained一书中有详细的论述，和AM的原则一样，我们在描述这组实践时，将会注重于建模的过程，这样你可以从另外一个角度来观察这些已或XP采用的素材。

核心实践：

Stakeholder的积极参与.我们对XP的现场客户（On-Site Customer）的概念做了一个扩充：开发人员需要和用户保持现场的接触；现场的用户要有足够的权限和能力，提供目前建构中的系统相关的信息；及时、中肯的做出和需求相关的决策；并决定它们的优先级。AM把XP的“现场客户”实践扩展为“使project stakeholder积极参与项目”，这个project stakeholder的概念包括了直接用户、他们的经理、高级经理、操作人员、支持人员。这种参与包括：高级经理及时的资源安排决策，高级经理的对项目的公开和私下的支持，需求开发阶段操作人员和支持人员的积极参与，以及他们在各自领域的相关模型。

正确使用artifact.每个artifact都有它们各自的适用之处。例如，一个UML的活动图（activity diagram）适合用于描述一个业务流程，反之，你数据库的静态结构，最好能够使用物理数据（physical data）或数据模型（persistence model）来表示。在很多时候，一张图表比源代码更能发挥作用，一图胜千言，同样，一个模型也比1K的源代码有用的多，前提是使用得当（这里借用了 Karl Wieger的Software Requirements中的词汇）。因为你在研究设计方案时，你可和同伴们和在白板上画一些图表来讨论，也可以自己坐下来开发一些代码样例，而前一种方法要有效的多。。这意味着什么？你需要了解每一种artifact的长处和短处，当你有众多的模型可供选择的时候，要做到这一点可没有那么容易。

集体所有制.只要有需要，所有人都可以使用、修改项目中的任何模型、任何artifact。

测试性思维.当你在建立模型的时候，你就要不断的问自己，“我该如何测试它？”如果你没办法测试正在开发的软件，你根本就不应该开发它。在现代的各种软件过程中，测试和质保（quality assurance）活动都贯穿于整个项目生命周期，一些过程更是提出了“在编写软件之前先编写测试”的概念（这是XP的一项实践：“测试优先”）。

并行创建模型.由于每种模型都有其长处和短处，没有一个模型能够完全满足建模的需要。例如你在收集需求时，你需要开发一些基本用例或用户素材，一个基本用户界面原型，和一些业务规则。再结合实践切换到另外的Artifact，，敏捷建模者会发现在任何时候，同时进行多个模型的开发工作，要比单纯集中于一个模型要有效率的多。

创建简单的内容.你应该尽可能的使你的模型（需求、分析、架构、设计）保持简单，但前提是能够满足你的project stakeholder的需要。这就意味着，除非有充分的理由，你不应该随便在模型上画蛇添足－－如果你手头上没有系统认证的功能，你就不应该给你的模型增加这么一个功能。要有这样的勇气，一旦被要求添加这项功能，自己就能够马上做到。这和XP的实践“简单设计”的思想是一样的。

简单地建模.当你考虑所有你能够使用的图表（UML图、用户界面图、数据模型等）时，你很快会发现，大部分时候你只需要这些图表符号的一部分。一个简单的模型能够展示你想要了解的主要功能，例如，一个类图，只要能够显示类的主要责任和类之间的关系就已经足够了。不错，编码的标准告诉你需要在模型中加入框架代码，比如所有的get和set操作，这没有错，但是这能提供多少价值呢？恐怕很少。

公开展示模型.你应当公开的展示你的模型，模型的载体被称为“建模之墙”（modeling wall）或“奇迹之墙（wall of wonder）”。这种做法可以在你的团队之间、你和你的project stakeholder之间营造出开放诚实的沟通氛围，因为当前所有的模型对他们都是举手可得的，你没有向他们隐藏什么。你把你的模型贴到建模之墙上，所有的开发人员和project stakeholder都可以看建模之墙上的模型，建模之墙可能是客观存在的，也许是一块为你的架构图指定的白板，或是物理数据模型的一份打印输出，建模之墙也可能是虚拟的，例如一个存放扫描好的图片的internet网页。如果你想要多了解一些相关的资料，你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。

切换到另外的Artifact.当你在开发一个artifact（例如用例、CRC卡片、顺序图、甚至源码），你会发现你卡壳了，这时候你应当考虑暂时切换到另一个artifact。每一个artifact都有自己的长处和短处，每一个artifact都适合某一类型的工作。无论何时你发现你在某个artifact上卡壳了，没办法再继续了，这就表示你应该切换到另一个artifact上去。举个例子，如果你正在制作基本用例，但是在描述业务规则时遇到了困难，你就该试着把你的注意力转移到别的artifact上去，可能是基本用户界面原型、CRC模型，可能是业务规则、系统用例、或变化案例。切换到另一个artifact上去之后，你可能就立刻不再卡壳了，因为你能够在另一个artifact上继续工作。而且，通过改变你的视角，你往往会发现原先使你卡壳的原因。

小增量建模. 采用增量开发的方式，你可以把大的工作量分成能够发布的小块，每次的增量控制在几个星期或一两个月的时间内，促使你更快的把软件交付给你的用户，增加了你的敏捷性。

和他人一起建模.当你有目的建模时你会发现，你建模可能是为了了解某事，可能是为了同他人交流你的想法，或是为了在你的项目中建立起共同的愿景。这是一个团体活动，一个需要大家有效的共同工作才能完成的活动。你发现你的开发团队必须共同协作，才能建立一组核心模型，这对你的项目是至关重要的。例如，为了建立系统的映像和架构，你需要和同组成员一起建立所有人都赞同的解决方案，同时还要尽可能的保持它的简单性。大多数时候，最好的方法是和另一些人讨论这个问题。

用代码验证.模型是一种抽象，一种能够正确反映你正在构建的系统的某个方面的抽象。但它是否能运行呢？要知道结果，你就应该用代码来验证你的模型。你已经用一些HTML页面建立了接受付款地址信息的草图了吗？编码实现它，给你的用户展示最终的用户界面，并获取反馈。你已经做好了表示一个复杂业务规则逻辑的 UML顺序图了吗？写出测试代码，业务代码，运行测试以保证你做的是对的。永远也别忘了用迭代的方法开发软件（这是大多数项目的标准做法），也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试（在其它的活动之中进行）。

使用最简单的工具.大多数的模型都可以画在白板上，纸上，甚至纸巾的背面。如果你想要保存这些图标，你可以用数码相机把它们拍下来，或只是简单的把他们转录到纸上。这样做是因为大多数的图表都是可以扔掉的，它们只有在你画出模型并思考一个问题的时候才有价值，一旦这个问题被解决了它们就不再有意义了。这样，白板和标签往往成为你建模工具的最佳选择：使用画图工具来创建图表，给你重要的project stakeholder看。只有建模工具能够给我们的编程工作提供价值（例如代码自动生成）时才使用建模工具。你可以这样想：如果你正在创建简单的模型，这些模型都是可以抛弃的。你建模的目的就是为了理解，一旦你理解了问题，模型就没有存在的必要了，因此模型都是可以丢弃的，这样，你根本就不必要使用一个复杂的建模工具。

补充实践：

使用建模标准.这项实践是从XP的编码标准改名而来，基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的编码惯例能够产生价值：遵守你选择的编码指南能够写出干净的代码，易于理解，这要比不这么做产生出来的代码好得多。同样，遵守共同的建模标准也有类似的价值。目前可供选择的建模标准有很多，包括对象管理组织（OMG）制定的统一建模语言(UML)，它给通用的面向对象模型定义了符号和语义。UML开了一个好头，但并不充分－就像你在Be Realistic About The UML中看到的，UML并没有囊括所有可能的的建模artifact。而且，在关于建立清楚可看的图表方面，它没有提供任何建模风格指南。那么，风格指南和标准之间的差别在何处呢。对源代码来说，一项标准可能是规定属性名必须以attributeName的格式，而风格指南可能实说在一个单元中的一段控制结构（一个if语句，一段循环）的代码缩进。对模型来说，一项标准可能是使用一个长方形对类建模，一项风格指南可能是图中子类需要放在父类的下方。

逐渐应用模式.高效的建模者会学习通用的架构模式、设计模式和分析模式，并适当的把它们应用在模型之中。然而，就像Martin Fowler在Is Design Dead中指出的那样，开发人员应当轻松的使用模式，逐渐的应用模式。这反映了简单的价值观。换言之，如果你猜测一个模式可能适用，你应当以这样的方式建模：先实现目前你需要的最小的范围，但你要为日后的重构留下伏笔。这样，你就以一种可能的最简单的方式实现了一个羽翼丰满的模式了。就是说，不要超出你的模型。举一个例子，在你的设计中，你发现有个地方适合使用GoF的Strategy 模式，但这时候你只有两个算法要实现。最简单的方法莫过于把算法封装为单独的类，并建立操作，能够选择相应的算法，以及为算法传递相关的输入。这是 Strategy模式的部分实现，但你埋下了伏笔，日后如有更多的算法要实现，你就可以重构你的设计。并没有必要因为Strategy模式需要，就建立所有的框架。这种方法使你能够轻松的使用模式。

丢弃临时模型.你创建的大部分的模型都是临时使用的模型－－设计草图，低精度原型，索引卡片，可能架构/设计方案等等－－在它们完成了它们的目的之后就再不能提供更多的价值了。模型很快就变得无法和代码同步，这是正常的。你需要做出决定：如果“同步更新模型”的做法能够给你的项目增添价值的话，那就同步更新模型；或者，如果更新它们的投入将抵消它们能够提供的所有价值（即负收益），那就丢弃它们。

合同模型要正式.在你的系统需要的信息资源为外部组织所控制的时候，例如数据库，旧有系统和信息服务，你就需要合同模型。一个合同模型需要双方都能同意，根据时间，根据需要相互改变。合同模型的例子有API的细节文档，存储形式描述，XML DTD或是描述共享数据库的物理数据模型。作为法律合同，合同模型通常都需要你投入重要资源来开发和维护，以确保它的正确、详细。你的目标是尽量使你系统的合同模型最少，这和XP的原则traveling light是一致的。注意你几乎总是需要电子工具来建立合同模型，因为这个模型是随时需要维护的。

为交流建模. 建模的次要原因是为了和团队之外的人交流或建立合同模型。因为有些模型是给团队之外的客户的，你需要投入时间，使用诸如文字处理器，画图工具包，甚至是那些“被广告吹得天花乱坠”的CASE工具来美化模型。

为理解建模.建模的最重要的应用就是探索问题空间，以识别和分析系统的需求，或是比较和对照可能的设计选择方法，以识别可能满足需求的、最简单的解决方案。根据这项实践，你通产需要针对软件的某个方面建立小的、简单的图表，例如类的生命周期图，或屏幕顺序，这些图表通常在你完成目的（理解）之后就被丢弃。

重用现有的资源.这是敏捷建模者能够利用的信息财富。例如，也许一些分析和设计模式适合应用到系统上去，也许你能够从现有的模型中获利，例如企业需求模型，业务过程模型，物理数据模型，甚至是描述你用户团体中的系统如何部署的模型。但是，尽管你常常搜索一些比较正确的模型，可事实是，在大多数组织中，这些模型要么就不存在，要么就已经过期了。

非到万不得已不更新.你应当在你确实需要时才更新模型，就是说，当不更新模型造成的代价超出了更新模型所付出的代价的时候。使用这种方法，你会发现你更新模型的数量比以前少多了，因为事实就是，并不是那么完美的模型才能提供价值的。我家乡的街道图已经使用了5年了，5年来我自己街道并没有改变位置，因此这张地图对我来说还是有用的。不错，我可以买一张新地图，地图是每年出一次的，但为什么要这么麻烦呢？缺少一些街道并没有让我痛苦到不得不投资买一份新地图。简单的说，当地图还管用的时候，每年花钱买新地图是没有任何意义的。为了保持模型、文档和源代码之间的同步，已经浪费了太多太多的时间和金钱了，而同步是不太可能做到的。时间和金钱投资到新的软件上不是更好吗？
确实不错的主意：

以下的实践虽然没有包括在AM中，但是可以做为AM的一份补充：

重构.这是一项编码实践。重构，就是通过小的变化，使你的代码支持新的功能，或使你的设计尽可能的简单。从AM的观点来看，这项实践可以保证你在编码时，你的设计干净、清楚。重构是XP的一个重要部分。

测试优先设计.这是一项开发实践。在你开始编写你的业务代码之前，你要先考虑、编写你的测试案例。从AM的观点来看，这项实践强制要求你在写代码之前先通盘考虑你的设计，所以你不再需要细节设计建模了。测试优先设计是XP的一个重要部分。

四、敏捷建模是（不是）什么？

我坚信当在描述事物的范围时，你需要说明它是什么，它不是什么。不管你谈论的是系统还是案例中的AM都一样。以下就是我对AM的范围的观点：

AM是一种态度，而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。 AM描述了一种建模的风格。当它应用于敏捷的环境中时，能够提高开发的质量和速度，同时能够避免过度简化和不切实际的期望。 AM可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图，你可以看看在建模Artifacts中列出的许多建模书籍，我特别推荐我的书The Object Primer 2/e(尽管这有失公允)。

AM是面向一般的开发人员的，但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂，其中的很多内容，可能你都已经采用或期待多年了。应用AM 技术并不是要你去练水上飘，但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术，这是个长期的、持续性的活动。学习建模在一开始可能很难，但你可以试着一次学习一样技术来完成你的学习。

AM并不适合每一个人。这一点在下面的列出的文章中会进一步讨论。

五、模型何时是敏捷的？

要想了解AM，你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念，它描述了一个的问题的一个或多个方面，或是处理这个问题可能的解决方案。传统意义上，模型被认为是图表加上相应的文档。然而那不够直观的artifact，也可以被视为模型，例如CRC卡片集，单条或多条业务规则的文字描述，或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢？当敏捷模型显现出如下的特性时，它就是刚刚足够好的：

敏捷模型实现了它们的目的。有时你为沟通而建模，或许你需要把你工作的范围告诉高级经理；有时你为理解而建模，或许你需要确定一个设计策略，实现一组Java类。一个敏捷模型是否足够好，要看它是不是满足了创建它时的初衷。

敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型，反之，技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性－－如果你的用户不了解UML用例图中的符号的含义，那用例图对用户就没有任何价值。这样的话，要么使用另一种方法，要么教授用户学习建模技术。风格问题同样也会影响易懂性，例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度（见下文），也会影响易懂性，因为相较一个不那么详细的模型来说，一个过于详细的模型要难于理解。简单（见下文）同样是影响易懂性的一个因素。

敏捷模型是足够正确的。模型通常都不需要100%正确，只要足够正确就行了。举个例子，如果一张街道地图漏画了一条街道，或是它标示某条街道是通行的，但你发现它已经关闭维修了，那你会不会扔掉你的地图开始在城里飙车犯罪呢？不太可能。你会考虑更新你的地图，你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图（你原来的那张过期了）。也许你还是会接受那张虽不完美仍可使用的地图，因为它对你来说已经足够好了。你还是可以用这张地图四处转转，因为它还是个正确的模型，标记出了大部分街道的位置。你在发现这张地图不正确的时候，你没有立刻扔掉它，原因是你根本不在乎它是否完美。类似的，当你在需求模型、数据模型中发现错误的时候，你也会选择更新或是接受－－虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能：这取决于项目的特性，每个团队成员的特性，组织的特性。充分正确性既和模型的听众有关，也和你要处理的问题有关。

我十几岁的时候在一家餐馆打工，开始是洗盘子，到后来升为出纳。在我做出纳时，我要学习如何关店。关店最重要的一件事就是清点钱柜。教我的那个店长认定一定要把钱柜的每一分钱都点清楚，如果和销售的数字有出入的话，就要重复点。因为不但要点清纸币，还要点清硬币，所以平均每晚都要花20分钟的时间。几个月后，她调到了另一家店，换了一位新店长。一天晚上我们一起关店，他看见我在一个一个的数硬币，他非常的吃惊。他马上演示了一下他是怎么数硬币的，他把同类的硬币抓在手上，看了看，猜了一个数值，只要它们的总价值在几美元之内，他就继续这样点。20分钟的时间被压缩到5分钟，因为他认为数字只要接近就可以了，并不需要非常的精确。他每天可以提早15分钟回家，按照一周6个晚上，一年50周计算，他一年能够节省75个小时，而他的职业生涯已经30年了

敏捷模型是足够一致的。一个敏捷模型并不需要和自己（或其它有用的artifact）保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例，那么相应的用例图需要用UML的 <>版型来标记这两个用例之间的关系。然而，你看了看图表，发现它们并没有这样做，天哪！用例和图之间不一致！危险！太危险了！红色警报！快逃命呀！等一下，你的用例模型是有不一致的地方，但也没到世界末日啊。是的，理想情况下，你的所有artifact最好是能够完全一致，但这通常是不可能的。当我开发一个简单的商用系统时，我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的测量系统。要树立一个观点，敏捷模型只要足够一致就行了，你通常不需要使用那么完美的模型。

关于正确性和一致性，很明显要考虑权衡问题。如果你要维护一个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）”你的工作。

七、敏捷建模何时是有（没有）意义的?

      何时合适AM运作?
      但这不是我的情形...
      何时不合适AM运作?
      何时敏捷建模是适合你的?

敏捷建模不是万能的，它并不适合于每一个人、每一种情况。即使是你的条件非常适合于AM，也不能保证它就能良好的运行——你在组织内实施AM时还是有可能犯下错误。我的经验是，在以下条件满足时，AM极有可能发挥其效力：

软件开发采用了敏捷方法。AM不是一门完整的方法学，它只是某个软件开发流程中的一部分应用。要成功应用AM，你所采用的开发流程的观念必须要与AM的观念相匹配（译注：XP与AM匹配，而CMM与AM就不匹配）。否则，你只是在片面的运用AM中的几项技术，而不是真正的配置了AM。

采用迭代式、递增式的开发方式。做为AM的两项实践，有效的沟通（communication）和反馈（feedback）要求软件开发采用迭代和渐增的方法。

需求不确定或不稳定。Martin Fowler在他的新方法学中指出，如果你的项目就像是自然探险（大多数项目都如此），那最佳的选择就是采用敏捷方法来开发软件。当需求不明或易变时，你就应该采用一种能够适应这种情况的开发方式。AM拥抱变化，它采用递增的开发方式，寻求快速的反馈，并且一贯坚持Project Stakeholder的积极参与，这就是AM对付需求变化的法子。使用AM，你就能够迅速而有效地发觉客户的需求。

开发软件是你的主要目标。这是AM的核心原则之一，但对很多项目来说，这并不是他们的目标。例如，有时候一个项目团队的主要目标是从客户那里圈钱（在外部采购中时有发生），或是简单的制定系统规范，因为系统要交付给另一个团队去实现。更糟的是，一些项目仅仅是出于政治上的考虑，它的目的就是让别人感到他们正在做这件事，至于要做出来什么东西却根本没有考虑。软件开发的目标应该是生产出满足客户需求的有效的软件系统－如果你的目标不是这样，AM就不适合你。

你需要有stakeholder的积极支持和参与。Fowler同样认为，敏捷软件开发工作要想成功，需要有project stakeholder的积极支持和参与。Project Stakeholder是那些受软件项目的开发和/或部署潜在的影响的人。包括直接用户，非直接用户，经理，高级经理，操作人员，支持人员，测试者，和这个系统有关（整合或交互）的其它系统的开发人员，以及维护人员。AM要想成功，你需要了解你的Project Stakeholder是谁，你还要能够和Stakeholder保持日常的接触，Stakeholder能够及时的为你提供信息、做出决策。此外，还应该要有管理层的大力支持。

开发团队能够自我决策。敏捷软件开发，特别是敏捷建模，对大多数的组织来讲都是新生事物。接受敏捷方法对大多数的组织来讲都是一件很难的事，因为它对大多数人来说都是一种新的工作方式。想要成功，我的经验是，不管成功还是失败，要根据项目团队的优点，给他们机会。鼓励他们尝试新技术，给他们资源（包括时间），让他们开始学习。应该尽量杜绝玩弄权术的现象，这就意味着组织中的管理层和一些部门要改掉原来的做法。

要有真正的AM斗士。不论何时，接受新的事物总会面临着挑战。人们不愿意改变，他们喜欢、他们也习惯了以前那种繁琐的慢节奏的工作方式。他们和你看事情的角度不同，你希望引入敏捷方法来解决问题，而他们不认为那是问题。也许他们会改进自己喜爱的开发方法，但这些方法和AM格格不入。也许，AM威胁到他们在组织内的权力分配。即使不考虑这些情况，也还是会有人抗拒变化。要想成功的改变，必须要有真正的AM斗士。他们支持AM，为AM奋斗，他们愿意去收集 Project Stakeholder的支持，他们愿意进行AM思想的宣传和培育，让AM能够在组织内生根发芽。改变需要时间，这些斗士就是在争取时间。

你需要负责、主动的开发人员。Fowler指出敏捷软件开发强调开发人员的纪律性，要求开发人员能够协同工作，开发高质量的软件。这意味着你需要一个健康的团队环境，人们能够相互信任，相互帮助，共同迈向成功。和那些敏捷开发方法的诋毁者告诉你的完全相反，你需要的人并不是一个个都要求能上天入地。根据我的经验，你的要求很简单：愿意完成工作，有合作精神，能够有效工作。

你需要有足够的资源。你现在知道了敏捷建模需要人们的紧密合作。就是说你需要“协同开发的空间”，例如能够使人专注于工作的建模室，一堵能够演示模型的公用墙，最好还能给每对开发人员配置一台共享工作站。除此之外，你还需要有足够的建模工具，例如白板、索引卡片、标记、和其它必须的CASE工具。我就曾经看过由于基本资源（像样的椅子，桌子，食物，饮料，和高端工作站）的缺乏，使软件开发工作的进展受到阻碍。如果你的项目团队因为这些锱铢之事导致失败，那我倒是想问问你这项目对你的组织是不是真的那么重要。如果不是，那就cancel它，把你的精力投入到其它更有价值的项目中去吧。

但这不是我的情况....

那么，当其上的一个或某些条件和你目前的情况有出入的时候，你该怎么办？试着去改变你目前的情况。缺乏AM的拥护者吗？那你自己就可以成为一个拥护者。不允许以迭代式和递增的方式工作，和你的老板们谈谈，让他们相信这是一种更好的工作方式，要求他们给你一个机会去证明。没有足够的资源？和你的头儿说明它们的重要性。如果你已经尽力改变了所有的情况，但是仍然还有一些条件是你无能为力的，你可以试试以下的选择：

部分的接受AM。你可以尽可能多的接受AM中的原则和实践，虽然你不会真正的实现AM，但你极有可能成为高效率的开发人员。一旦你的组织发现这确不失为一个软件开发的好方法，那就有可能会主动的去改变一些必需的要素，从而完全的接受AM。一言以蔽之，循序渐进的实现AM。

放弃让你的组织接受AM。从我个人的角度，我并不喜欢这种选择，但我不得不承认它是个正确的办法。现实就是这样，AM并不是适合每一个人的，也许你的组织确实是不适合接受AM的。

跳槽。看看外面的世界，还是有很多的组织期望能够从软件开发的竞赛中获胜，他们希望能有积极主动的软件开发人员加盟。

何时敏捷建模是不适合你的?

我猜想敏捷建模在遭遇如下的情形的时候你会陷入麻烦：

不满足以上列出的一个或多个条件。

你的组织文化适合采用传统的开发流程。许多组织对采用敏捷的软件开发方法毫无兴趣，他们对目前的状况感觉很好。这主要是那些政府部门、大型的公司（银行、保险公司、电信公司）以及专门为这些组织服务的咨询公司。这并不是说在这类组织中实施AM完全不可能，但要获得成功则要付出超乎寻常的努力才行。

你的团队很大，分布在各地。只有那些在同一个工作区域中相互协作的团队才能很好的进行敏捷建模的工作，特别是当开发人员在一个公共的工作室内合作的时候（通常我们称之为“tiger team”房间）。你可以尝试着在一个大型或分散的团队中应用敏捷方法，我在架构建模中讨论了这种情形，但你很快会发现你需要挑战这种方式带来的沟通问题。

我不同意将敏捷方法应用于性命攸关的系统上，例如航空管制系统或医疗监测系统，因为我并没有相关的项目经验，无法去研究AM应该怎样应用于这些系统。同样，我也没有嵌入式系统的相关经验，因此我也没有机会将AM技术应用于这种类型的项目。我很怀疑AM是否能够试用于嵌入式软件开发，这是我研究的一部分。我很期待你在敏捷建模的邮件列表中告诉我相关的经验。（详情请访问http://www.agilemodeling.com/feedback.htm）

八、AM的实践是如何组合的

AM的实践之间是相互促进的，因为他们彼此支持，彼此激发。为了使AM更有效率的工作，你需要了解它的实践是如何组合的。图1显示了AM的实践之间的关系，它们被分为七类。AM的核心实践集中在头四种类别中－验证，迭代和递增，团队协作，和简单，你需要完全接受它们才能真正理解敏捷建模。然后，才轮到属于辅助实践的文档，动机，生产率这三个类别。我们先针对核心实践的四个类别，讨论各类中的实践之间的关系，然后我们再针对辅助实践的三个类别，研究各类中实践之间的关系，最后我们来讨论类别之间的关系。

核心实践

在团队协作类别中有四项实践－－stakeholder的积极参与，和他人一起建模，公开展示模型，和集体所有制。stakeholder的积极参与对你的成功至关重要，因为你正是为了这些project stakeholder开发系统，正是为了了解和实现他们的需求。换言之，你需要和你的甲方们密切合作，这就自然的想到了和他人一起建模－－这个“他人” 也包括你的stakeholder。当你的建模工作有多人参加时（至少一个project stakeholder和一个除你之外的开发人员），你就需要和众人共同协作，相互促进，取长补短。一个擅长于业务过程建模和业务规则定义的敏捷建模者看不到的方面，一个精通结构化建模技术（例如UML类图或数据模型）的人极有可能看得到。一样的道理，系统的直接用户给你的团队提供的信息极可能是高级经理提供不了的。所以，要有这样的观点：你要在项目甲方和开发团队中营造一种积极参与的氛围，只有这样，才能够收集各种不同的观点和经验。集体所有制能够提升协作性，因为一个人单独的进行建模的工作，他很快就会遇到瓶颈，而如果每个人都能够为建模工作献计献策，那么你们就能够成为一个团队，轻易的解决问题。公开展示模型能够使得人们对模型“瞻前顾后”变得容易了，能够立刻考虑模型传达的信息，从而提高团队的协作性。当然，我们是假设模型都在众人的视线之内，或者这些模型都是大家目前正在开发或相关的。这方面的主题我在Organizing an Agile Modeling Room中有详细的讨论。

迭代和递增类别中包括了使用合适的artifact，并行创建模型，切换到另外的artifact，小增量建模这几项实践。不论哪一个artifact，都有它的长处和短处，任何一个单独的模型都不足以充分的描述你的项目的各个主要方面（如需求、架构）。例如你会发现你为了识别系统的需求，常常需要组合使用用例、业务规则定义、和技术需求定义。单单靠用例就能令project stakeholder立马告诉你他们所有的使用需求吗？这恐怕不太可能。你可以试试换用诸如业务规则之类的artifact来捕获他们的所有业务政策，再换用诸如技术需求的artifact来捕获他们的非功能需求。否则，他们会想起点什么就告诉你什么，还会返回去讨论先前提过的细节，甚至是改变他们的原来的主意。你的需求识别工作通常是一个动态的过程，分析、架构、设计工作也是一样。我相信物力论中指出了人们以此种方式思考的原因，我们思考的方式明显是杂乱的。敏捷建模者要认识到人们是以一种动态的方式在思考，特别是人们处于群体行为时，这样才能制定对策。敏捷建模者并行创建模型，从而能够最广泛的收集信息。这项实践又是由实践切换到另外的artifact和小增量建模来支持的－－你可能正在使用用例来捕获使用需求的相关信息，而当stakeholder开始讨论他们对编辑屏幕的要求时，你最好是使用基本用户界面原型或是传统用户界面原型来记录这些需求。你需要在不同的artifact之间来来回回，每一个artifact最好都需要编码来验证，这种方式可以由小增量建模的实践来实现－－最典型的方式就是在这个artifact上做一会儿工作，再换一个artifact，依此类推。

简单这个类别包括了创建简单的内容，简单地建模，使用最简单的工具这几项核心实践。创建简单的内容和简单地建模这两个实践集中于模型的简单性，在建模过程中这两项实践通产是密不可分的。把精力集中在如何简单描述，建模者常常会发现一些使得你手头的模型简单化的方法。举个例子，我曾经参加了一项存储层软件的开发工作，软件的概念类似于EJB的persistence container，封装了领域对象的一些存储操作。结果我们架构和设计非常的复杂，我们试着找到一种办法：建立一张简单的图表，帮助开发人员理解如何使用存储层来工作。其间我们还发现重构能够使我们的设计易于理解。实践使用最简单的工具能够使得过程变得简单。工具越简单就越容易使用，这就降低了他人在你的模型上工作的门槛，也就增加了实际中别人去这么做的机会，这也包括了你的project stakeholder。通过使用最简单的工具，简单描述模型也变得更自然了。此外，当你使用一些简单/低精度的工具，例如索引卡片，即时贴，白板的时候，你就能亲身体验这些简单工具的效力，你在不知不觉中已经强化了一些概念：最简单的解决方法实际上也能非常有效，对你正在开发的系统采用简单的设计。

验证类别包含了两个核心实践：测试性思维和用代码验证。有一条哲学，我常从中受益：“如果你无法测试它，你就不应该建立它，而你建立的一切都应该加以测试。”这使得我在系统建模时就考虑测试，也使得我积极的去获取我的模型的反馈－－实际上，我把该条哲学归纳为“考虑你创建的所有artifact的可测试性，以及验证所有种类的artifact。”但这并不仅仅局限于AM的范围之内。通过这种可测试性的考虑，在我建模时，我能够建立起可测试的模型，而且积极的通过编码来验证模型，这样，我就能够尽快的证实我的模型是真正可以测试的。

辅助实践

文档类别包括了三项辅助实践：丢弃临时模型，合同模型要正式，非到万不得已不更新。在项目的进行中，需求、对需求的理解、以及对可能的解决方案的理解，都在不断变化（回忆一下原则拥抱变化）。为了反映这种变化，你需要同步改进你大部分的项目artifact，包括模型和文档。就像在敏捷文档讨论的那样，比较好的方法是，不到万不得已不要更新你的模型和文档，这种做法才算是敏捷方法。遵循这项实践，如果你发现一个模型如果不再需要更新，那就是说这个模型对你的团队已经没什么价值了，一个没有价值的模型就可以视为临时模型，可以丢弃。不过，要注意合同模型。它定义了你的系统和其他系统之间的接口，不太可能经常改变，因为它们的重要性是勿庸置疑的。一言以蔽之，如果你有个非合同模型不再更新，那就意味着它已经没有用了。

为沟通建模和为理解建模这两项实践属于动机类别。实际上，这两项实践并没有太多的联系，有时候你创建模型的目的是为了研究和理解问题，有时候你的目的是为了和其他人交流你的想法，有时候你的目的包括了上述两者。就像你在图1中看到的，这两项实践常常会一起引出另两类的实践，这是下文要讨论的主题。

最后，生产率类别中包括使用建模标准，逐渐应用模式，以及重用现有的资源这几项实践。重用现有资源这个实践要求你尽量利用他人的工作成果并从中受益，这有很多种思考方向：一种是应用模式，根据经验，我认为它是所有重用方法中最有效率的一种，因为你重用的都是其它开发人员久经验证的解决方案 (Ambler, 1999)；另一种是遵循建模标准和指南，实际上，不论是标准还是指南，都能够提高你工作的一致性。是的，你可以自己写指南，有时你必须要这么做，因为你的实际环境中会有一些特别的情况。但是你只需要在Internet上稍做搜索就可以找到很多的开发指南。例如，你可 javaCodingStandards找到Java的开发指南。

九、类别间的联系

让我们考虑团队协作类别。简单类别中的实践增强了实践stakeholder的积极参与的效果，因为简单性消除了参与的代沟。迭代和递增类别中的实践也使得参与成为可能，尤其是并行创建模型，因为它增大了stakeholder们参加的机会。动机类别中的实践可以提高集体所有制和和他人一起建模的效果，对问题的理解和沟通通常可以激发人们的协作精神，简单类别的实践也也坑达到激发协作效果，因为它降低了参与的门槛。公开展示模型的效果可以通过生产力类别中的实践得到提高。遵循标准，应用模式的做法可以增加一致性和可读性，而重用现有的资源（例如通用架构），则给别人开了一个好头，使别人能够在你模型的基础上继续。迭代和递增类的实践可以支持集体所有制的实行，特别是并行创建模型和切换到另外的artifact，它们使得人们在适当的模型上共同开发。

简单类别的实践由另外几类的实践来辅助。使用建模标准和逐渐应用模式这两项实践支持同一种建模语言（使用标准和容易理解的模式），从而支持了实践简单地建模。文档类别的实践也可以支持简单类别的实践－－只有到万不得已才更新模型，这样，你才不会给模型增加不必要的信息。才有可能创建简单的内容以及简单地建模。

现在再来看迭代和递增类别。很明显，团队协作类别的实践支持该类的实践，由于团队的参与，针对目前的情况选用正确artifact的机会就增大了，你就可以根据需要来切换使用不同的artifact。验证类实践能够赋予你使用递增方法的勇气，特别是在你用代码验证的时候。保证你想法的易测性，你就更有把握同时操作多个artifact，并在它们之间切换，因为测试问题要求你从多个方面来看待它。文档类实践同样可以促进递增方法，特别是非到万不得已不更新。但是合同模型要正式这个实践抑止了递增方法的应用，因为你总是希望能够尽早的建立和其他系统间的接口标准。切换到另外的artifact和丢弃临时模型之间也能产生正面的效果，因为一个模型完成目的之后就把工作切换到另一个模型上去。简单类实践对这个类别也很重要，通过使用最简单的工具，你在不同的 artifact间来回切换就变得更容易了，你节省了熟悉工具的时间，只把精力集中在简单的内容和描述上，你也可以较容易记住模型要传达的信息。最后，动机类实践可以令你同时进行多个建模工作，因为对于复杂的系统，你需要从多个方面去沟通，去理解，因此你需要在适当的artifact间来回切换，这样才能有效的做到这一点。

验证类实践可由简单类实践来支持－－创建简单的内容和简单地建模能使你更容易进行测试性思维。迭代和渐增类实践也能提高验证类实践。例如，在你切换到另外的Artifact时，就可能切换到源代码，这样你就可以看到模型确实可以运行。

简单类实践可以推进生产力类实践。当你使用简单模型工作时，逐渐应用模式就更容易一些；当你简单地建模时，使用建模标准也会容易一些，而模型的简单、易懂，也会使你比较容易的重用现有的资源，例如企业需求模型或通用的架构模型。

简单类实践以及迭代和渐增类实践可以支持文档类实践的进行。文档越简单就越容易使用－－如果你的文档容易理解，这样你就有把握万不得已才更新你的文档，因为你知道做到这一点很简单；文档如果很复杂，你的项目风险就很大，因为没有把握什么时候文档需要更新。很明显，非到万不得已不更新和丢弃临时模型的运作环境可以其它的实践来改善，例如切换到另外的artifact、小增量建模。

十、那，你想成为一个敏捷建模者吗?

个性通才还是专才?

敏捷建模者的个性

      Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义个各个角色执行的任务，尽管入席，这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能，但人们必须要慢慢的熟悉这些技术。我的经验告诉我，要成为一个成功的敏捷建模者，下面的列出的个性是必要的：
      团队竞赛第一点，也是最重要的一点，敏捷建模者总是积极的寻求协作，因为他们意识到他们不是万事通，他们需要不同的观点，这样才能做到最好。软件开发可不是游泳，单干是非常危险的。在敏捷的字典中没有“我”这个词。
      畅所欲言敏捷建模者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听，能够主动获取反馈，并且能够把需要的写出来。
      脚踏实地敏捷建模者应当脚踏实地。他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足，即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种，当然，前提是要能够完成工作。
      好奇敏捷建模者乐衷于研究问题，解决问题。
      凡是都问个为什么敏捷建模者看问题从不会至于表面，而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试。
      实事求是敏捷建模者都非常的谦逊，他们从不认为自己是个万事通，所以他们会在建立好模型之后，用代码来小心的证明模型的正确。
      勇气敏捷建模者应当愿意去计划一个想法，然后做出模型，再想办法用代码来验证。如果结果不理想，他们就会返工，检查他们的方法，或是放弃原先的想法。把你的想法告诉你的同伴，再来验证它的正确，这是需要很大的勇气的。
      根据实验敏捷建模者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术。一般而言，他们也会接受敏捷建模开发技术，必要时，为了验证想法，他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量。
有纪律要坚持不懈的遵循敏捷建模的实践。对你来说，你可能会在不经意间说，“加上这个功能吧，无伤大雅。”或是，“我比project stakeholder更了解。”在AM的道路上要想不偏离方向，是需要一定的纪律性的。
      如果你不具有上面列出的所有个性，那该怎么办呢，你是不是还想成为一个敏捷建模者呢？不用担心，你只需要少量的努力就能够胜任。相信我，我也没有办法做到 100%的脚踏实地和实事求是，我也经常遇到沟通问题。没有人能够拥有所有的个性，大部分人都只能拥有一些个性。每个人都有不同点，这些不同点正是敏捷团队力量的源泉。某些人可能生来就好奇，另一些人的工作积极性可能比较强。人无完人嘛。

通才还是专才?

当你要增加团队成员时，所要处理的一个至关重要的问题是你希望保持的通才和专才的比率。要回答这个问题，你需要考虑现代软件开发环境。图1是企业统一过程（Enterprise Unified Process EUP）的生命周期。（译注：原文中并没有提供这副图，根据我的猜测，应该就是RUP的概述部分的那张生命周期图，但是因为没有取得瑞理公司的授权，所以我暂时也不便引用这张图，大家可以参阅RUP的相关资料。）图左边的EUP的工作流程暗示着软件开发的复杂－－你需要进行业务建模，收集需求，分析和设计系统等等－－而这还只是冰山一角。就像图中列出的那样，从先启到产品化的各个阶段，预示着在项目的过程中，不同的时间需要你集中于不同的地方，这需要不同的技能。有一个观点是很明确的，软件开发非常的复杂，任何一项工作都需要高超的技能和丰富的经验。首要的，要认识到这种复杂性是软件开发与身俱来的，而不是EUP使然的，即便你的团队采用的是XP方法，抑或是DSDM（Stapleton, 1997）方法，或是SCRUM （Beedle & Schwaber, 2001）方法，这种复杂性也还是存在的。尽管这些方法的生命周期看上去并不像EUP那样的复杂，但它们仍然需要配置管理活动，需要管理活动等等，只是它们处理问题的态度不同而已。

很多的组织对此的第一反应就是建立一个专才的团队。专才的最基本的含义是指那些特别精通某一项任务的人，因此他们的效率也特别的高。这样一支团队，要想高效率的运作，你需要组合这些专才，让每人负责一块任务，解决之后就把手头的工作传给另一个人。这个概念就类似于“流水线”的想法，如果你是在大量的生产汽车，这种方式会非常的有效，但是以我的经验，在手工的软件中采用这种方式并不是太合适。而且，这种方式需要一个大团队的支持－－如果软件开发中有N中不同的任务，你至少就需要N位专才才能满足这种方法的要求。但N是多大？20？50？100？这取决于你对专业定义的细节程度，是吧？如果你倾向于每位开发人员只处理一种artifact，那单单处理建模工作，就需要20多位的专才，在modeling artifacts essay列出了各种的artifact。如果你倾向于每位开发人员只负责一种角色，那再一个EUP的项目中也需要11中角色才能完成所有的工作流程。专才通常都很难同人合作，他们缺少谦逊的品质，意识不到其它人的专项技能能够为他的工作增添价值，他们也意识不到他们的所作所为可能为给后续的工作造成麻烦，也许他们需要返工，也许他们现在的努力会白费。关于专才的另一个问题是，即使是在他们擅长的领域，他们的技能也可能根本就没有那么精熟。IT产业的技术高变动率，导致了开发人员使用了几个月的新技术，开始熟悉它，就声称自己已经是这方面的专家了，因为和他具有同样层次经验的人毕竟不多。要建立一个专才组成的团队，这也是一个很明显的问题。

那么，建立一支仅有通才的团队会怎样呢？每个人都对软件开发有不错的了解，但是都缺乏足够详细的必需知识，完成不了工作。项目需要那些对现阶段使用的技术和技巧都非常熟悉的人。如果你是在使用Enterprise JavaBeans (EJB)，那你既需要对Java编程精通的人，也需要对EJB开发精通的人。一个使用Oracle的团队，幕后肯定有一位Oracle数据库管理专家。一个开发经纪人业务软件的团队，就需要一位能够了解股票和债券之间的细微差别的人。

我的经验是，两种极端的方式都不可取，你应该取它们的中间点。一种方法是团队中一部分人是通才，一部分人是专才。通才能够起到团队的连接剂的作用，通才注重远景，专才注重项目的具体的难点。这样做的好处是通才的长处能够弥补专才的短处，反之也是一样，由于这种平衡性，通才和专才组对能够发挥出极大的优势。一个更好的方法是团队中主要是通才，仅有一两个专才。例如，我认为我应该算是一个通才，我擅长于处理项目中各项技能之间的配合，而且还精通业务应用软件建模，以及对象存储和Java编程。我的另一位同事也是位通才，特别擅长建模，EJB开发，以及测试。还有一位堪称通才的同事则精于网络通信和Java编程。这样一支由通才组成，但又有一项或多项特技的团队，优势是很明显的，他们能够迅速的找到共同点，因为他们毕竟都是通才，而且他们之间有能够做到优势互补。它的劣势在于这种人才一般都比较稀缺，动辄都需花费10年甚至20年的时间才能够培养出这种通才，因此是很难得到的。如果你的团队中有一些这种人，那你的运气真是太好了。要认识到新手通常一开始都是专才，这很重要。软件开发的新手面对着需要消化的大量知识，往往不知所措，这很正常。大多数人一开始一开始会把精力集中在开发的一两个方面，也许是Java编程，也许是获取用户需求，然后以这方面的经验为基础，再逐渐的拓展知识的覆盖面。随着时间的增长，经验在不断的累积，他们会慢慢的完善自己的技能树，他们会软件开发中各个技能如何配合会更加了解，同时，他们还擅长于一两门特技。

还有一点也很重要，要明白很多的开发人员的专精反而害了这些人。由于软件开发的与身俱来的复杂性，开发人员经常会落入一个名为单一artifact开发者的陷阱中去，他们把自己定位为仅仅从事一种artifact的开发工作，例如代码，用例模型，或数据模型；开发人员还可能遇到的一个陷阱名为单一角色开发者，他们的定位是专门从事一种工作的人，例如建模，测试，或编码。换言之，这些人专精于某一个角色，这种倾向在一些的采用传统过程的大型组织中特别显著，问题就出现了，这些陷阱的落入者的视野往往过于狭窄，难以在一个采用敏捷方法的软件开发项目中作到高生产率。当然，如果他们原意扩展自己的视野，这个问题就容易得到解决。

译注：想必国内的程序员看到这篇文章会很开心吧。毕竟，中国的程序员向来都是以通才自封的。但是，要注意的一点是，这篇文章是针对国外的程序员的，因为国外的程序员通产都只关注于自己的领域，例如数据库的专家对数据库非常的熟悉，但他可能对测试一窍不通。但是他们对自己领域的了解是非常不得了的。可是中国的程序员一般是万金油，哪儿需要，哪儿就有我的丰姿。只要是软件领域的，都无所不能，无所不精。但是人的精力都是有限的，不可能什么都精通。样样都精，也就是样样都庸。这个道理大家务必要了解。国内的很多程序员都算不上是通才，而只能算是庸才。这句话可能不好听，但是事实如此。如果能够意识到这一点，好，我想你已经不是庸才了，而是在往通才迈进的途中了。本来是不打算译这篇文章的，因为担心有些人看完它后会断章取义，反而成了一项罪过。但是这篇文章的很多思想值得借鉴，再加上为了保证译作的完整性，最后还是把它译了出来，并加上了一段废话，提醒大家注意。最后，我真诚的希望中国的程序员都能够成为作者在文中提到的那种既是通才，又是专才的人。

十一、建模的误区

走出一般性的设计误区，迈向成功之途

英文原文版权由Scott W. Ambler拥有
Original text is copyrighted by Scott W. Ambler
译者：高继荣| 原文出处：www.AgileModeling.com

无论你遵从的是重量级的方法,比如Enterprise Unified Process(EUP)，还是轻量级的开发过程，如Extreme Programming(XP)，建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面，有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠半的市场宣传以及象Object Management Group (OMG)和IEEE这类组织的标准。这个月，我要揭示建模中的误区，指出其相应的事实真相。

误区一：建模就等于是写文档

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中，制造着一些脆弱而劣质的系统。另外，甚至于许多尽责的开发人员现在也认为建模是一件讨厌的事，而不愿去学习相应的建模技术。

事实分析：“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型，而不论是被画在餐巾纸的背面，或写在一块白板上，或在Class Responsibility Collaboration(CRC)卡片中，还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档，但他们却都是有价值的模型。

建模很象是作计划：作计划的价值在于计划编制的过程中，而非计划本身；价值体现在建模的活动中，而非模型本身。实际上，模型不是你系统中的一部分正式的文档，而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型，而且它一定是非常完美。

误区二：从开始阶段你可以考虑到所有的一切

这种说法流行于二十世纪七十年代到八十年代早期，现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确，试图在编码开始前就“冻结”所有的需求（见误区四），以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点，项目组开发了大量的文档，而不是他们真正想要得到的—开发满足需要的软件。

事实分析：怎么才能走出这个误区呢？首先，你必须认识到你不能考虑到所有的细枝末节。第二，认识到编码员可能会对建模者的工作不以为然（这是可能的，事实上建模者所作的工作在实际价值中只占很少的部分），他们或许会说模型没有反应出真实的情况。第三，认识到不管你的最初所作的规格说明书有多好，但注定代码会很快地与之失去同步，即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四，认识到迭代法（小规模地建模，编一些代码，做一些测试，可能还会做一个小的工作版本）是软件开发的准则。它是现代重量级的软件开发过程（如EUP），以及轻量级（如XP)的基本原理。

误区三：建模意味着需要一个重量级的软件开发过程

走入这个误区（经常与误区一有联系）的项目组常常是连建模都彻底地放弃了，应为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

事实分析：你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM)。而且，你可以丢弃你的模型当使命完之后，同样也可以很基本的方式进行建模（比如，从办公桌起来，来到白板前就开始构略草图）。只要你愿意，你就可以轻松地建模。

误区四：必须“冻结”需求

这个要求常常来自高级经理，他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求，就可以确切地知道所要的是一个什么样的东西；缺点就是他们可能没有得到实际上所需要的（不全或错误的需求，译者）。

事实分析：变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解，都会引起需求的变化。与冻结需求相反，估计项目成功的风险，尽量去接受变化而且相应地采取行动，就象XP所建议的一样。

误区五：设计是不可更改的

如同误区四，要求每一个开发人员必须严格遵从“设计“，导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计，否定了所有设计可能带来的好处。冻结了设计，你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件，使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

事实分析：事实上，设计会经常根据开发人员和数据库管理员的反馈进行修改，因为他们是最接近实际应用的人，通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实：人无完人，他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗？另外，如果需求并没有被冻结，其实就意味着你不能冻结你的设计，因为任何需求的修改势必影响设计。对之，正确的态度是：只要你的代码还在改动，涉及就没完。

误区六：必须使用CASE工具

建模常常被认为是一项复杂的工作，因此需要大量地使用CASE工具辅助进行。

事实分析：是的，建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息，而不是将一些无关紧要的细节包括进来。

比如，我经常使用UML建立模型来表示类、它们的属性及一些关键的业务操作，但并不画出属性的存取操作(get和set)，以及维护与其它类关系的框架代码，或者其他一些琐碎的实现细节。我通过建模寻找解决问题的方法，让我和我的同事能继续前进去实现这个模型。以这样灵活的方式，大多数情况下我并不需要一个CASE工具来支持建模工作，一块白板，或者一台数字相机足以。这样，我就不用花时间去评估CASE工具，不用去和工具供应商讨论许可证的问题，也免去了人员培训开销。CASE工具只有当它能体现最佳性价比时（相对你自己的情况而言），才值得购买。大多数情况下，我都能不用它而达到目的（完成建模）。我经常使用的工具有Together/J(http://www.togethersoft.com/) – 因为它能产生数目可观的Java框架代码；还有ERWin（http://www.cai.com/） -- 因为它能规划数据库。这两个工具真正地帮助我实现了软件开发的目的 – 制造满足用户要求的软件。但我绝大多数得建模工作仍然使用的是简单的工具，而不是CASE工具。

误区七：建模是在浪费时间

许多新手都这样认为，这主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码，就如初级程序员。他们放弃了提高效率和学习技能的机会，这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

事实分析：在大多数情况下，在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外，建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题，从而对所要的是一个什么样的东西可以得到更好的理解，涉及到该项目中的每个成员也可得到对该项目有一个从分的了解。

误区八：数据模型(Data Model)就是一切

许多组织基于数据模型就蹒跚启动新的开发工作，也许正如你所在的组织：IT部门对于数据有非常严格的规定，控制着你的开发项目；或者你以前的数据库是一团糟，别无选择。

事实分析：数据模型是一个重要的但不是最重要的建模，它最好是建立在另外的模型之上。（参见“Extreme Modeling”，Thinking Objectively，Nov.2000）。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的（在数据模型中没有表示出来），这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例（use cases），业务规则（business rules），activity diagrams，类图（class diagrams），component diagrams，用户界面流程图（user interface flow diagrams）和CRC，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

误区九：所有的开发人员都知道如何建模

我们现在面临照这样一个严重的问题：许多不是开发人员的人，包括高级经理和用户，不知道软件是如何建成的。其结果，他们不能够区分开熟练的开发者和一般的程序员（当然也分不清高级程序员和一般程序员），他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

事实分析：这肯定是不正确的。建模的技能，是只有当一个开发者通过学习它，并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能，毕竟他们终究只是程序员。正因为这样的狂妄自大，他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂，单单一个人是很难具备所有的技能去成功地进行开发，甚至也不可能去配置有一定复杂程度的系统。开发这应该有自知之明，明白他们自己的弱点，学无止境。通过互相取长补短，建模者可从程序员身上学到一项技术的具体细节，程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人，包括我自己，都是新手。

Agile Modeling

通过理解和避开建模的误区，你能够是得你自己、你的项目组和你的组织更加有效地进行软件开发。在揭示这些普遍存在误区的过程中，我已经表述了Agile Modeling(AM)的许多原则。Agile Modeling 以前叫做Extreme Modeling(XM)。我希望我所给于你的是精神上的食粮。

在此我要感谢Blueprint Technologies（http://www.blueprinttech.com/）的Doug Smith，Evanetics（http://www.evanetics.com/）的Gary Evans，以及在Agile Modeling邮件列表（可访问http://www.agilemodeling.com/加入）中对本文做出贡献的人们。我同样要感谢Martin Fowler，Ron Jeffries和其他一些XP社区中成员，因为我想我已经融入了一些他们的观点。

十二、建模十条原则

仅有数据模型对于现代软件是不够的。

接收变化，并且允许你的模型能够随着时间进行改进。你不能冻结它们，然后就期待着成功。

模型并不一定就是文档，文档也不一定就是模型。

大多数的模型可能也应该被丢弃。

只有代码才能与代码保持真正的同步。

一些简单的工具，比如白板，就完全足以应付大多数得建模工作。

思考，然后再编码。

你总能从别人身上学到东西。

建模可以用一种轻盈的方式。

设计直到代码发布以后才算完成。

本文来自敏捷中国站点
译者：林星
原文出处：www.AgileModeling.com
英文原文版权由Scott W. Ambler拥有
Original text is copyrighted by Scott W. Ambler

欢迎注册黑客派社区，开启你的博客之旅。让学习和分享成为一种习惯！