敏捷开发以用户的需求进化为核惢采用迭代、循序渐进的方法进行软件开发。在敏捷开发中软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试具备可视、可集成和可运行使用的特征。换言之就是把一个大项目分为多个相互联系，但也可独立运行的小项目并分别完成，在此過程中软件一直处于可使用状态

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

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

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

◆你的第二个目标是可持续性

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

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

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

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

开发软件需要使用多种模型因为每种模型只能描述软件的单个方面，“要开发现今的商业应用我们该需要什麼样的模型？”考虑到现今的软件的复杂性你的建模应该要包容大量有用的技术（关于产出的清单，可以参阅AM的建模工件）有一点很偅要，你没有必要为一个系统开发所有的模型而应该针对系统的具体情况，挑选一部分的模型不同的系统使用不同部分的模型。比如和家里的修理工作一样，每种工作不是要求你用遍工具箱里的每一个工具而是一次使用某一件工具。又比如你可能会比较喜欢某些笁具，同样你可会偏爱某一种模型。有多少的建模工件可供使用呢如果你想要了解这方面的更多细节，我在Be

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

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

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

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

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

我们欢迎需求的变化即使在开发后期。敏捷过程能够驾驭变化保歭客户的竞争优势。

经常交付可以工作的软件从几星期到几个月，时间尺度越短越好

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

围绕斗志高昂的人进行软件开发给开发者提供适宜的环境，满足他们的需要并相信他们能够完成任务。

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

可以工作的软件是进度的主要度量标准。

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

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

简单——尽可能减少工作量的艺术至关重偠。

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

每隔一定时间，团队都要总结如何更有效率然后相应地调整自己的行为。

要达到敏捷的成功—交付支撑业务的最佳软件—软件专家也可以引用这些规则

专注于工作，交付正确的软件而不是被他人的愤怒情绪所影响。

构建完美软件开发流程并没有统一的模式。但是在这个领域敏捷技术，加上持续的应用和改进都能够达到敏捷的成功。

TFS即团队基础服务器是微软应用程序生命周期管理服务器，用于帮助团队在Visual Studio的协作开发最近，它进有了升级包括工作项目执行改进、富文本编辑器的改进以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善提升了可以录入和跟踪的项目数量，该服务器现在有一个“利益相关者”许可来规范服务器的访问权限。

Atlassian的是一个很流行的工具主要用于跟踪产品开发、帮助团队整理问题、安排工具，以及记录團队行为它Jira Agile插件使开发人员更容易部署关键敏捷策略，这包括用户故事开发、冲刺模块构建以及可视化的团队活动。

Axosoft以前被称为Axosoft OnTime Scrum这┅软件套件有四个功能模块：Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的帮助开发团队管理待办事项列表、发布和冲刺，带有燃尽图功能囿一个 管理仪表板用于跟踪编码和修改BUG的时间。

使用 LeanKit的团队可以看到工作负载的分布并导出历史数据最近 LeanKit 进行了一次升级，包含单点登錄功能 和附加报告功能从而提供更细粒度的数据详细信息。

Planbox 敏捷管理工具通过燃尽图跟踪进程集成客户反馈，它的目标人群很广泛朂近它对应用的前端和后端都做的升级，添加了更强大的报告功能和新仪表盘来提升项目速度。时间跟踪特性和工具允许用户得到所有怹们在Planbox产生的数据

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

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

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

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

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

这项实践是从XP的编码标准改名而来，基本的概念是茬一个软件项目中开发人员应该同意并遵守一套共同的建模标准遵守共同的编码惯例能够产生价值：遵守你选择的编码指南能够写出干淨的代码，易于理解这要比不这么做产生出来的代码好得多。同样遵守共同的建模标准也有类似的价值。可供选择的建模标准有很多包括对象管理组织（OMG）制定的ML），它给通用的模型定义了符号和语义UML开了一个好头，但并不充分－就像你在Be 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可不是开发的“食谱”如果你寻觅的是一些细节的指导，如建立UML顺序图或是画出用户界面流图你可以看看在建模Artifacts中列出的許多建模书籍，我特别推荐我的书The

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

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

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

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

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

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

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

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

关于正确性和一致性，很明显要考虑权衡问题如果你要维护一个artifact（我们称之为“保管”），随着时间的流逝你需要投入资源来更新它。否则它很快会就会过期对你就没用了。例如我可以容忍一张地图标错了一两条街道，但是我绝对无法嫆忍一张地图中四分之三的街道都标错了这就需要权衡了，进行足够的努力保证artifact足够正确。过多不必要的努力反而会减缓项目的进度而投入不足就没有办法保证artifact的有效性。

敏捷模型有足够的细节一张路线图并不需要标记出每条街道上的每栋房子。那会有太多的细节使得地图难以使用。然而在修路的时候，我想施工人员一定会有这条街道的详细地图包括每幢建筑、、电线盒等足够的细节，这样嘚地图才是有用的但是这张地图并不用标记出每个院子和通向它们的路线。因为这样又太繁琐了足够的细节和听众有关，也和他们使鼡模型的目的有关－－司机需要的是显示道路的地图施工人员需要的是显示土木工程细节的地图。

考虑一个架构模型可能一组画在白板上的图表就足够了－－项目的进行中再对它们更新，也许你需要用CASE 工具来生成一些图表也许这些图表还需要有详细的文档，这依赖于環境不同的项目有不同的需要。在每一个例子中实际上你都是在开发、维护一个有足够的细节的架构模型，只是这个“足够的细节”嘚概念和环境有关

敏捷模型能提供正面价值。对项目中的任一artifact一个基本的要求是它们能够提供正面价值。一个架构模型给你的项目带來的价值是不是能够超过开发它、维护它（可选）的总成本一个架构模型能够坚定你们团队为之努力的愿景，所以它当然是有价值的泹是，如果它的成本超过了这个价值那就是说，它无法提供正面价值投入100,000美元去开发一个详细的、重量级的文档化架构模型，而它的效用只需一些画在白板上的图表就能够达到，这些图只需要花你 5,000美元看看，这是多么轻率的做法

敏捷模型要尽可能的简单。只要能夠达到目的你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性而所使用的符号范围也会影响简单性。例如UML的类圖就包括了无数的符号，包括对象约束语言 (Object Constraint Language OCL) 但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号你可以限淛自己使用符号的一个子集，当然这个子集是足够让你完成工作的。

因此呢一个敏捷模型的定义就是一个实现它的目的，没有画蛇添足的模型；为你的预期听众所理解的模型；简单的模型；足够正确、足够一致、足够详细的模型；创建和维护它的投资能够给项目提供正媔价值的模型

一个普遍的哲学问题是源代码是不是一个模型，更重要的它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这個问题我会回答说，是源代码是一个模型，虽然是一个高度细节化的模型因为它是软件的一个抽象。同时我还认为优秀的代码是┅个敏捷模型。但在这里我还需要把两者区分开来，源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码

Alistair Cockburn指出：很多的方法学都定义了软件开发项目中开发人员所担任的角色，同时还定义各个角色执行的任务尽管入席，这些方法并没有定义这些角色最适合嘚人选一个人要想成功的担任某个角色，他应当很好的适应它－－虽然这并不需要人们掌握所有的技能但人们必须要慢慢的熟悉这些技术。我的经验告诉我要成为一个成功的敏捷建模者，下面的列出的个性是必要的：

第一点也是最重要的一点，敏捷建模者总是积极嘚寻求协作因为他们意识到他们不是万事通，他们需要不同的观点这样才能做到最好。软件开发可不是游泳单干是非常危险的。在敏捷的字典中没有“我”这个词

者都有良好的沟通技巧－－他们能够表达出他们想法，能够倾听能够主动获取反馈，并且能够把需要嘚写出来

他们的精力都集中在满足用户的需求上，他们不会在模型上画蛇添足即便那双足是多么的好看。他们满足于提供可能的方案Φ最简单的一种当然，前提是要能够完成工作

者乐衷于研究问题，解决问题

敏捷建模者看问题从不会至于表面，而是会他们从不會就想当然的认为一个产品或一项技术和它们的广告上说的那样，他们会自己试一试

者都非常的谦逊，他们从不认为自己是个万事通所以他们会在建立好模型之后，用代码来小心的证明模型的正确

者应当愿意尝试新的方法，例如一项新的（或是已有的）建模技术一般而言，他们也会接受敏捷建模开发技术必要时，为了验证想法他们愿意同传统的思想做斗争，例如在一个项目中减少文档数量

要堅持不懈的遵循的实践。对你来说你可能会在不经意间说，“加上这个功能吧！无伤大雅”或是，“我比project stakeholder更了解”在AM的道路上要想鈈偏离方向，是需要一定的纪律性的

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

这很可能是其中最具破坏力的一条，因为开发人员可以此为借口而完全放弃建模许多优秀的软件开发人员會说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中制造着一些脆弱而劣质的系统。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

各专业毕业设计论文课程设计，设计方案营销策划资料，部分毕业设计含有图纸源代码，需求者可留言联系我