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

敏捷开发原则

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

核心原则

◆主张简单

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

◆拥抱变化

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

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

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

◆递增的变化

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

◆令投资最大化

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

◆有目的的建模

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

◆多种模型

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

◆高质量的工作

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

◆快速反馈

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

◆软件是你的主要目标

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

◆轻装前进

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

宣言原则

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

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

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

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

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

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

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

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

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

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

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

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

敏捷成功之道

随机应变

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

自主权

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

分享经验

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

敏捷开发相关工具

Visual Studio Team Foundation Server

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

Atlassian Jira

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

Axosoft

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

LeanKit

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

Planbox

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

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

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

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