什么是敏捷流程

敏捷建模（Agile Modeling，AM）的价值观包含了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外。还扩展了第五个价值观：谦逊。

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。除了原则和实践，模式也是非常重要的，多研究模式及其应用能够使你更深层次的理解敏捷开发。

沟通

建模不但可以促进你团队内部的开发者之间沟通、还可以促进你的团队和你的project stakeholder之间的沟通。

简单

画一两张图表来取代几十甚至几百行的代码。通过这样的方法，建模成为简化软件和软件（开发）过程的关键。

这一点对开发者而言非常重要－它简单，easy发现出新的想法。随着你（对软件）的理解的加深，也可以非常easy的改进。

反馈

Kent Beck在Extreme Programming Explained中有句话讲得很好：“过度自信是编程的职业病，反馈则是其处方。”通过图表来交流你的想法。你可以高速获得反馈，并可以依照建议行事。

谦逊

最棒的开发者都拥有谦逊的美德。他们总能认识到自己并非无所不知的。

其实。不管是开发者还是客户。甚至全部的 project stakeholder，都有他们自己的专业领域。都可以为项目做出贡献。一个有效的做法是如果參与项目的每个人都有同样的价值。都应该被尊重。

2原则编辑

敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。

当中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的具体描写叙述。

而XP中的一些原则又是源于众所周知的软件project学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要側重于它们是怎样影响着建模工作；这样。对于这些借鉴于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。

◆高质量的工作

没有人喜欢烂糟糟的工作。

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

◆高速反馈

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

◆软件是你的主要目标

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

◆轻装前进

你建立一个artifact，然后决定要保留它。随着时间的流逝，这些artifact都须要维护。假设你决定保留7个模型。不论何时，一旦有变化发生（新需求的提出。原需求的更新。团队接受了一种新方法，採纳了一项新技术...），你就须要考虑变化对这7个模型产生的影响并採取对应的措施。

而假设你想要保留的仅是3个模型，非常明显。你实现相同的改变要花费的功夫就少多了。你的灵活性就增强了。由于你是在轻装前进。类似的，你的模型越复杂。越具体，发生的改变极可能就越难实现（每一个模型都更“沉重”了些，因此维护的负担也就大了）。每次你要决定保留一个模型时，你就要权衡模型载有的信息对团队有多大的优点（所以才须要加强团队之间，团队和project stakeholder之间的沟通）。

千万不要小看权衡的严重性。一个人要想过沙漠，他一定会携带地图，帽子。质地优良的鞋子，水壶。假设他带了几百加仑的水，可以想象的到的全部求生工具，一大堆有关沙漠的书籍，他还能过得去沙漠吗？相同的道理。一个开发团队决定要开发并维护一份具体的需求文档，一组具体的分析模型。再加上一组具体的架构模型，以及一组具体的设计模型。那他们非常快就会发现。他们大部分的时间不是花在写源码上。而是花在了更新文档上。

宣言原则

最重要的是通过尽早和不断交付有价值的软件满足客户须要。

我们欢迎需求的变化，即使在开发后期。

敏捷过程可以驾驭变化，保持客户的竞争优势。

常常交付能够工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发人员应该在整个项目过程中始终朝夕在一起工作。

环绕斗志高昂的人进行软件开发，给开发人员提供适宜的环境，满足他们的须要，并相信他们可以完毕任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

能够工作的软件是进度的主要度量标准。

敏捷过程提倡可持续开发。出资人、开发者和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单——尽可能降低工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结怎样更有效率，然后对应地调整自己的行为。^[1]

补充原则

◆内容比表示更重要

一个模型有非常多种的表示方法。

比如。能够通过在一张纸上放置即时贴的方法来建立一个用户界面规格（基本/低精度原型）。它的表现方式能够是纸上或白板上的草图。能够是使用原型工具或编程工具建立和传统的原型，也能够是包含可视界面和文本描写叙述的正式文档。

有一点非常有意思，一个模型并不一定就是文档。它们通常作为其他artifact的输入，比如源码，但不必把它们处理为正式的文档。即使是使用CASE工具建立的复杂的图表，也是一样。

要认识到一点。要利用建模的长处。而不要把精力花费在创建和维护文档上。

◆三人行必有我师

你不可能全然精通某项技术。你总是有机会学习新的知识。拓展知识领域。把握住这个机会，和他人一同工作，向他人学习，试试做事的新方式。思考什么该做。什么不该做。技术的变化很的快，现有的技术（比如Java）以难以置信的速度在改进，新的技术（比如C#和.NET）也在有规律的产生。

现存开发技术的改进相对会慢一些，但也在持续的改进中－－计算机产业属于工业，我们已经掌握了当中的试验基本原理，但我们还在不断的研究，不断的实践，不断的改进我们对它的了解。我们工作在一个变化是家常便饭的产业中，我们必须通过训练、教育、思考、阅读、以及和他人合作，抓住每个机会学习新的处事之道。

◆了解你的模型

由于你要使用多种模型。你须要了解它们的优缺点，这样才可以有效的使用它们。

◆了解你的工具

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

◆局部调整

你的软件开发方法要可以反映你的环境，这个环境包含组织特征，project stakeholder的特征，项目自身的特征。

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

◆开放诚实的沟通

人们须要可以自由的提出建议，并且人们还应该可以感受到他们是自由的。建议可能是和模型有关的想法：或许是某些人提出某部分新的设计方法，或是某个需求的新的理解；建议还可能是一些坏消息，比如进度延误；或不过简单的工作状况报告。

开放诚实的沟通是人们可以更好的决策，由于作为决策基础的信息会更加准确。

◆相信直觉

有时你会感觉到有什么地方出问题了。或是感觉什么地方有不一致的情况。或是某些东西感觉不是非常对。事实上。这样的感觉非常有可能就是事实。随着你的软件开发的经验的添加。你的直觉也会变得更敏锐，你的直觉下意识之间告诉你的，非常可能就是你工作的关键之处。

假设你的直觉告诉你一项需求是没有意义的，那你就不用投入大量的精力和用户讨论这方面的问题了。

假设你的直觉告诉你有部分的架构不能满足你的须要，那就须要建立一个高速技术原型来验证你的理论。假设你的直觉告诉设计方法A要比设计方法B好。并且并没有强有力的理由支持你选择某一个方法。那就虽然选择方法A。勇气的价值就已经告诉你，假设未来证实你的直觉是错的，你也有能力来拯救这样的情况。你应该有这样的自信，这非常重要。

3实践编辑

敏捷建模（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的好处和短处，当你有众多的模型可供选择的时候。要做到这一点可没有那么easy。

◆集体全部制 仅仅要有须要，全部人都能够使用、改动项目中的不论什么模型、不论什么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的一个重要部分。