项目管理之敏捷开发之道

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

敏捷开发原则

敏捷建模（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顺序图了吗？写出测试代码，业务代码，运行测试以保证你做的是对的。永远也别忘了用迭代的方法开发软件（这是大多数项目的标准做法），也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试（在其它的活动之中进行）。

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

补充实践

◆使用建模标准 这项实践是从XP的编码标准改名而来，基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的编码惯例能够产生价值：遵守你选择的编码指南能够写出干净的代码，易于理解，这要比不这么做产生出来的代码好得多。同样，遵守共同的建模标准也有类似的价值。可供选择的建模标准有很多，包括对象管理组织（OMG）制定的统一建模语言ML），它给通用的面向对象模型定义了符号和语义。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可不是开发的“食谱”，如果你寻觅的是一些细节的指导，如建立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是面向一般的开发人员的，但并不是要排斥有能力的人。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工具

建模常常被认为是一项复杂的工作，因此需要大量地使用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，等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处，应该正确地使用。

误区九

所有的开发人员都知道如何建模

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

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

敏捷开发宣言

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

敏捷开发遵循原则

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

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

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

n 不断地关注优秀的技能和好的设计会增强敏捷能力。

简单是最根本的。

n 最好的构架、需求和设计出自己组织的团队。

n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

当软件开发随需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

n 僵化性：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。

n 脆弱性：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

n 牢固性：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

n 粘滞性：做正确的事情比做错误的事情要困难。

不必要的复杂性：设计中包含有不具任何直接好处的基础结构。

n 不必要的重复性：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。

晦涩性：很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

单一职责原则（SRP)

就一个类而言，应该仅有一个引起它变化的原因。

开放-封闭原则（OCP)

软件实体应该是可以扩展的，但是不可修改。

n Liskov替换原则（LSP)

子类型必须能够替换掉它们的基类型。

n 依赖倒置原则（DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

n 接口隔离原则（ISP)

不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

n 重用发布等价原则（REP)

重用的粒度就是发布的粒度。

共同封闭原则（CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。

共同重用原则(CRP)

一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。

环依赖原则（ADP)

在包的依赖关系图中不允许存在环。

稳定依赖原则（SDP)

朝着稳定的方向进行依赖。

稳定抽象原则（SAP)

包的抽象程度应该和其稳定程度一致。

上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

敏捷开发团队原则

最大的分歧

最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工作，而且有能力承担他们面前的任务。

发现中立点

团队决定作为一个团队需要做什么，如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色（如，软件测试员或开发员）来定义自己。所以找到一个中立点，她列出了小型离线会议，和每周工作之外的小时集体活动所需的事项。这样，该团队去当地的农场采摘蓝莓。他们一起上瑜珈课。他们集体在厨房里烤燕麦棒，做果沙。

正确执行应用程序

团队找到了让自此感到舒服的新水平。整个项目的工作流程顺利进行，只做一个待办的事情，而不是四个。

分布式敏捷开发

分布式敏捷开发团队并不是工作在所有组织中；拥有一个已经建立的分布式敏捷开发工作文化对分布式团队很重要。有些公司一直坚持“面对面”，这给分布式敏捷站立会议的开发增加的难度。

但是如果文化一直就已经存在，那么开展敏捷站立会议和其它会议就会很容易。其中的一个选择就是使分散的团队成员按照同一计划表工作，即时区不一致。如果团队成员同意，且时差不超过几个小时的话，这才有效。

敏捷开发的原则

1. 快速迭代

相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

2. 让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

3. 编写可测试的需求文档

开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

4. 多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。

团队要确保日常的交流，面对面沟通比邮件强得多。

5. 做好产品原型

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

6. 及早考虑测试

及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。 

敏捷开发概述

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

　　

敏捷开发的路线^[1]

　　图：敏捷开发的路线图

　　Test-Driven Development，测试驱动开发。

　　它是敏捷开发的最重要的部分。在ThoughtWorks，我们实现任何一个功能都是从测试开始，首先对业务需求进行分析，分解为一个一个的Story，记录在Story Card上。然后两个人同时坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论，直到达成共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘，编写该测试代码的实现。如果没有测试代码，就不能编写功能的实现代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

　　Continuous Integration，持续集成。

　　在以往的软件开发过程中，集成是一件很痛苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题，比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事情呢？它至少包括：获得所有源代码、编译源代码、运行所有测试，包括单元测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一些其它的任务，比如说代码分析、测试覆盖率分析等等。在我们公司里，开发人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码是可用而可靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品CruiseControl。

　　Refactoring，重构。

　　相信大家对它都很熟悉了，有很多很多的书用来介绍重构，最著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不容易实现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者check in代码之前，都要对所写代码进行重构，让代码达到clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复，也要对它进行重构。

　　Pair-Programming，结对编程。

　　在敏捷开发中，做任何事情都是Pair的，包括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT，关于这个话题，钱钱同学有一篇很有名的文章对它进行介绍，名为Pair Programming (结对编程)。

　　Stand up，站立会议。

　　每天早上，项目组的所有成员都会站立进行一次会议，由于是站立的，所以时间不会很长，一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等，而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么？ 3. 你遇到了哪些困难？站立会议让团队进行交流，彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题，那么在站立会议后，他就会和你进行讨论。

　　Frequent Releases，小版本发布。

　　在敏捷开发中，不会出现这种情况，拿到需求以后就闭门造车，直到最后才将产品交付给客户，而是尽量多的产品发布，一般以周、月为单位。这样，客户每隔一段时间就会拿到发布的产品进行试用，而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁，每一个版本新增的功能简单，不需要复杂的设计，这样文档和设计就在很大程度上简化了。又因为简单设计，没有复杂的架构，所以客户有新的需求或者需求进行变动，也能很快的适应。

　　Minimal Documentation，较少的文档。

　　其实敏捷开发中并不是没有文档，而是有大量的文档，即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法，如果有新人加入团队，最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效。如果用书面文档或者注释，某天代码变化了，需要对这些文档进行更新。一旦忘记更新文档，就会出现代码和文档不匹配的情况，这更加会让人迷惑。而在敏捷中并不会出现，因为只有测试变化了，代码才会变化，测试是真实反应代码的。这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗？其实简单可读的代码才是好的代码，既然简单可读了，别人一看就能够看懂，这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单，需要对它进行重构。

　　Collaborative Focus，以合作为中心，表现为代码共享。

　　在敏捷开发中，代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它，如果有人看到某些代码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意，很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码，即使团队的人员变动，也没有风险。

　　Customer Engagement ，现场客户。

　　敏捷开发中，客户是与开发团队一起工作的，团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后，能够以最快速度得到客户的反馈。

　　Automated Testing ，自动化测试。

　　为了减小人力或者重复劳动，所有的测试包括单元测试、功能测试或集成测试等都是自动化的，这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具，能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作，包括Selenium开源项目。

　　Adaptive Planning，可调整计划。

　　敏捷开发中计划是可调整的，并不是像以往的开发过程中，需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行，一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代，小版本的发布，根据客户反馈随时作出相应的调整和变化。

　　敏捷开发过程与传统的开发过程有很大不同，在这过程中，团队是有激情有活力的，能够适应更大的变化，做出更高质量的软件。

　　敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

敏捷开发的特点

　　（1）敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

　　这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。 　　 　　（2）敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的，过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

　　在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

　　然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。

　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

　　实际上敏捷开发运动在数年前就开始了，但它正式开始的标志是2001年2月的“ 敏捷宣言 ”（Agile Manifesto），这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的，他们的 价值观 是：个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对 合同 的 谈判 ；对变化的响应重于始终遵循固定的计划。

敏捷开发的价值观

　　个人与交互重于开发过程与工具的原因：一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代的齿轮，但结果却并不成功。敏捷过程是承认每个人都有特定的能力（以及缺点）对之加以利用，而不是把所有的人当成一样来看待。更重要的是，在这样的理念下，几个项目做下来，每个人的能力都从中得以提高。这种人的能力的提高，对公司是无价之宝。而不至于把人当成齿轮，随着时间的推移，人的能力慢慢被消耗掉，最后变成留之无用、弃之可惜的尴尬人物。

　　可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始，并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长，以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待。

　　寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力，合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢，要么大家一起输。换句话说，就是希望开发小组和客户在面对项目的时候，以一种合作的态度共同向目标前进。当然，合同是必需的，但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力。

　　对变化的响应重于始终遵循固定的计划的原因：敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外，用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法，也许今天看起来是必需的功能，明天就会觉得不那么重要了。随着小组获得更多的知识和经验，他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说，一个计划是从某个角度对未来的看法，而具有多个不同的角度看问题是有可能的。

[编辑]

项目的敏捷开发方法

　　敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程（RUP）等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先级； 检查与调整。下图是典型的敏捷过程总图，下面介绍其有关的特点。

　　

　　1、敏捷小组作为一个整体工作

　　项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员，一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然，尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同，但愿则基本上是一样的。第一个角色是产品所有者，他的主要职责包括：确认小组成员都在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。

　　2、敏捷小组按短迭代周期工作

在敏捷项目中，总体上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工作（分析、设计、编码、测试。等等）。迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4周，在 Scrum中采用的是 30个日历天，也就是 4 周。迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。

　　3、敏捷小组每次迭代交付一些成果

　　比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了MTBF测试，其它都达到了发布状态。

　　4、敏捷小组关注业务优先级

　　敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。

　　5、敏捷小组检查与调整

　　任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对于项目投资最大化是有益处的。从这个观点来看，迭代周期的长度选择就比较重要了，因为两次迭代之间是提供变更的机会，周期太长，变更机会就可能失去；周期太短，会发生频繁变更，而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑，对于一个复杂项目，迭代周期选择4周还是有道理的。

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。其它的因素是：

　　1、至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。

　　2、开发团队具备运作多个产品的工作经验。

　　3、很早就致力于构建和提供内聚的架构。

　　从这个报告中所透露出的信息告诉我们，认真研究敏捷过程对软件项目的成功是非常有意义的，它的意义在于：

　　1）给开发小组的自组织提供了机会

　　经典项目管理就好比一个具备中央调度服务的航空管理系统，这个系统是自治的，而且是封闭的，但现实中更庞大的系统，似乎并不属于中央调度控制系统，但也同样也是有效的。假如我们开车到某个地方，我们可以任意选择所需要的路线，我们甚至不需要准确计算停车，只要我们遵守交通法规，驾驶员可以临时根据路况改变某个转弯点，在驾驶游戏规则的框架内，依照自身最大利益做出决策。成千上万的驾驶者，并不需要中央控制和调度服务，人们仅仅在简单的交通法规的框架内，就可以完成综合起来看是更庞大的目标，很多事情从管理的角度只要抓住关键点，并不需要多么复杂的规则，往往会更有效。随着系统复杂度的提高，中央控制和调度系统面临崩溃。仔细研究交通系统的特点，我们会发现这样的系统中独立的个体在一组适当的规则下运行，并不需要设计每个个体临时变更的方案，而每个个体只需要知道目标和大致的状况，他们完全可以利用自己的聪明才智来决定自己的行为。

　　2）缩短了反馈通道

　　敏捷过程有效运作的另一个原因是，它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候，便需要有一种方法在比较短的时间内发展完善。事实上，所有的过程改进都不同程度的使用着戴明循环，以研究问题、测试解决方案、评估结果，进而根据已知的事实来进行改进，这就称之为基于事实的决策模式，我们都知道，这比前端预测的决策方式更加有效。

　　3）易于集思广益

　　敏捷过程能有效应用的另一个原因在于，它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候，总有某些人员知道问题所在，但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸，事后分析出了各种原因，但这种调查也提供给我们一个惊人的事实，就是部分工程师早就意识到这些潜在问题，却无法说服他人重视这个担忧。对这些事实的深入思考，促使我们研究我们应该采取何种管理系统，使前线工作人员的经验、观点及担忧得到充分的重视呢？

[

对敏捷开发的误解

　　误解一：敏捷对人的要求很高

　　很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么？ 软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。

　　从另一个角度来看：过程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显着的效果，甚至有些时候还有反效果；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显着。

　　敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。

　　误解二：敏捷没有文档，也不做设计

　　这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是“必要且意义重大”？这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写；再如，架构设计文档要不要写？复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人（比如lead）来决定。

　　至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善（重构），使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。

　　误解三：敏捷好，其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。

　　从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性。

　　因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。

　　误解四：敏捷就是XP（极限编程），就是Scrum

　　XP 和Scrum只是众多敏捷方法中的两种，还有很多其他的敏捷方法。龙生九子各个不同，敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法，就是因为他们背后的理念和原则都是相同的，这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践，还要理解实践后的原则，不仅要理解怎么做，还要理解为什么这么做，以及什么时候不要这么做。

　　即使将XP或Scrum完全的应用的你的项目中，也未见得就能成功，适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点，但绝对不是终点，最适合你的方式还要由你自己在实际工作中探索和寻找。

　　误解五：敏捷很好，因此我要制定标准，所有项目都要遵循着个标准

　　没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

　　同时，对于同一个团队，随着项目的进行，对需求理解的深入，对技术理解的深入，一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整，保证项目的质量和效率。敏捷是动态的，而非静止不变的，因为这个世界本身就是变化的，在变化的世界使用不变的方法，是不现实的。银弹从来就没有过，在有限的将来也不会存在。

敏捷开发知识体系整体框架

敏捷开发工程实践

项目管理

• 迭代开发
• 风险价值生命周期
• 多级项目规划
• 完整团队
• 每日站立会议
• 任务板
• 燃尽图

需求管理

• 需求订单
• 业务流程草图
• 用例驱动开发
• 用户故事

架构

• 演进的架构
• 演进的设计
• 基于组件的架构设计

开发

• 结对编程
• 测试驱动开发
• 重构
• 代码规范

测试

• 单元测试
• 并行测试
• 测试管理

变更管理

• 持续集成
• 自动构建
• 团队变更管理

敏捷开发管理实践描述

• 定义和特征说明
• 主要角色
• 主要活动和最佳实践
• 主要输入输出
• 工作流程

敏捷开发工程实践描述

• 定义和特征说明
• 应用说明
• 案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说, 尽管右项有其价值, 我们更重视左项的价值.
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3
    
    
    
    
4
    
    
    
    
5
   
   
   
   
   
   
   
   

    
    
    
    
1
    
    
    
    
2
    
    
    
    
3
    
    
    
    
4
    
    
    
    
5
   
   
   
   

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

• 以人为本
• 目标导向
• 客户为先
• 拥抱变化

敏捷开发的原则

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
• 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
• 可工作的软件是进度的首要度量标准。
• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
• 以简洁为本，它是极力减少不必要工作量的艺术。
• 最好的架构、需求和设计出自自组织团队。
• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

• 产品负责人（Product Owner） 
  
  • 通常由市场部门的人担任
• 敏捷教练 (Scrum Master) 
  
  • 通常由开发组组长担任
• 开发团队 (Scrum Team) 
  
  • 包括开发,需求,测试

“鸡”角色

• 用户 
  
  • 软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”
• 利益所有者 (客户，提供商) 
  
  • 影响项目成功的人, 但只直接参与冲刺评审过程。
• 管理者 
  
  • 为产品开发团体架起环境的那个人

主要活动和最佳实践

• 迭代式软件开发
• 两层项目规划 (Two-Level Project Planning)
• 整体团队协作 (Whole Team)
• 持续集成
• 冲刺规划会议 (Sprint Plan Meeting)
• 每日站立会议 (Sprint Daily Meeting)
• 冲刺复审会议 (Sprint Review Meeting)
• 冲刺回顾会议 (Retrospective Meeting)

主要输入输出

• 产品订单(Product Backlog)
• 冲刺订单(Spring Backlog)
• 燃尽图(Burndown Chart)
• 新的功能增量

工作流程

项目管理过程

• 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
• 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

• 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
• 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
• 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
• 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
• 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

• 项目/产品愿景
• 项目/产品路线图
• 版本发布计划
• 迭代计划
• 每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

• 当前的问题
• 机会描述和理由(描述项目的重要性)
• 项目的价值
• 项目如何和组织的战略目标达成一致
• 解决方案综述
• 项目包含的关键功能
• 项目必须服从的技术和约束条件
• 项目范围
• 项目的关键时间线
• 项目收益分析
• 项目和其他项目的依赖性
• 项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

• 根据当前状态确定是否需要对版本计划做出更新
• 为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人（Product Owner）

• 确定产品的功能。
• 决定发布的日期和发布内容。
• 为产品的收益(profitability of the product)负责。
• 根据市场价值确定功能优先级。
• 在30天内调整功能和调整功能优先级。
• 接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

• 负责监督整个Scrum项目进程, 调整开发计划
• 保证团队资源完全可被利用并且全部是高产出的。
• 保证各个角色及职责的良好协作。
• 解决团队开发中的障碍。
• 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
• 保证开发过程按计划进行，组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
• 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
• 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
• 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决
• Scrum Master需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数，进展中的工作需要得到最小化，以实现精益生产率的收益。
• Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决.

开发团队 (Scrum Team)

• 具有不同特长的团队成员，人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
• 弱化分工, 每个人都参与设计, 开发与测试
• 确定Sprint目标和具体说明的工作成果。
• 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
• 向Product Owner演示产品功能。

团队素质完整性

• 要具备很强的集体协作精神.
• 要具备良好的沟通能力
• 必须能积极主动的接受新的事物, 要具备创新能力
• 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

• Sprint启动会
• 每日站立会议
• Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责，通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前，首先团队需要定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员，强调如何实现系统以及如何检验。

• 挑选用户故事
• 为故事写测试
• 实现测试
• 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

• 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
• 主要角色: ST, PO, SM
• 主要输入: Product backlog, 团队的能力
• 主要输出: Sprint Backlog

冲刺会议分两个部分 
1. 解决本次冲刺要完成哪些需求 
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

• 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
• 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
• 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
• 最高分和最低分的组员像团队做出解释
• 全组成员自由讨论几分钟
• 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

• PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
• 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
• 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

• 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
• 需求订单式开放的, 团队每个成员都可以编写和维护
• 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

• 具备可视性
• 具备风险预估, 提醒团队目前完成情况
• 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

• 我们上次开会后你都干了什么
• 在我们下次开会之前你要做什么
• 每个你负责的、正在做的任务还剩下多少时间
• 你的工作被阻碍了吗

任务板(Task board)

• 为项目团队提供一个便利的工具用于管理他们的工作
• 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码

参考资料

百度百科-敏捷开发：http://baike.baidu.com/link?url=cwuvVabLCt05za2V4avXDr1XWFUdiBlPeJWxxswQdacHZT76b_TZRGPGHFYEEn7aSGzx1sPeUm2TxthXiqcHTfAPjs15jvdQUn4wAHTOWdrKJd6dh-rA1fC-0BNy01hJ

智库百科-敏捷开发：http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

敏捷开发知识体系笔记：http://blog.csdn.net/uxyheaven/article/details/49618097