信息系统项目管理师考前培训-第三讲

软件工程，顾名思义，就是以工程化的思想来开发软件，为什么要以工程化的思想来做软件开发？这是因为最初的时候，软件开发是一种很不规范的一些活动，最初的时候要求不一样，计算机发明出来之后，第一次去运行一些程序，是直接把一些这些指令，什么东西输入到计算机里面，后来慢慢的就有了存储的概念，把它存下来，先写好指令存在里面，然后要执行的时候，直接执行，再到后面，开始，有了一些小的软件，要实现一些功能，那做这些小的软件，也许就是一个人就可以搞定，那这种情况，也就是直接委托某个人去做就ok了，也不需要什么方法、体系之类的来指导，但是当开发规模越来越大的时候，人们发现问题出现了，以前一个人让他做，一个月，能够把这个事情做好，现在这个工作量增加了10倍，让他两个人做5个月，也还是能够完成。工作量进一步加大，要10个月，10个人来完成的项目，那很有可能就失败了，失败原因是什么？很多程序技术高手，独善其身，是可以的，自己做好自己的事情，但是让他们去管理别人，就很难了，这个配合了，也很难达到一个默契的程度，随着这个软件开发，这种问题越来越多，失败率越来越高了，就有人提出来了，我们是不是能够应用到某种方法，用这种方法的时候，这个做软件，跟生产产品一样，第一个产品生产出来是这么一个效果，第二个也是这么一个效果，质量是可控的，所以就诞生了软件工程。

所以，我们在讲后面的这些软件工程里面一些知识的时候，会经常涉及到建筑领域的一些例子，举建筑领域的例子，是，因为本身这个软件工程是属于工程领域的东西，而建筑也是属于工程领域的东西，而建筑有着数千年的历史，所以在这个软件工程里面，很多很难理解的概念，我们引入到建筑工程，就很容易去理解了，这是软件工程，那软件工程部分，需要了解的知识，包括这一些方面：软件开发模型、需求、工程、软件设计、软件测试、软件运行与维护，软件复用，以及软件开发环境，首先看到开发模型，开发模型，每一次考试，基本上都会考到，考什么内容，第一个，开发模型的特点，第二个，开发模型的应用，就是，这两个方面，没有其他的一些什么更多的考法了，在这一块，我们会详细讲到，每一种开发模型，有些什么特色，他如果说有存在阶段的划分的话，哪些，这个阶段，做什么事情，都会简单的讲到，首先看到瀑布模型，瀑布模型是所有这些模型里面，知名度算是最高的，同时也是最老的一个模型，这个模型把所有的这些开发工作，分成了多个阶段，第一个阶段是软件计划，第二个阶段是需求分析，第三个阶段是软件设计，第四个阶段是程序编码，第五个阶段是软件测试，最后一个阶段，运行维护，严格来讲，运行维护已经不属于我们要涉及到的范围的，因为它属于运维阶段，那么前面的软件设计和需求分析的部分工作，其实是属于另一阶段的，中间，这几部分是开发阶段，这样子的一个划分，每个阶段，每个阶段都联系紧密，首先做了计划，做了计划之后，就可以开始需求分析工作了，完成需求分析工作，一、依据分析的结果来做软件设计，依据软件设计的结果来写程序，做编码工作，编码完成之后，就做测试，所以这一个流程下来，给人感觉是计划，相当的严谨，与此同时，他如同瀑布，如同流水，一气呵成的，完成一个任务，看上去似乎也是很合理的一种模型。

但是，我要告诉大家一个数据，在这个瀑布模型最为盛行的时候，美国的研究机构做过这样子的统计，使用瀑布模型开发的软件系统，那么，开发软件系统，做的这个项目，10个项目，有9个会失败，也就是说，使用瀑布模型做开发，失败的概率会达到90，甚至是90以上，这个数据是一个真实的数据，在此之前，这个美国的官方、组织和军方，都还是指定的瀑布模型做开发的，那用的瀑布模型做开发，那么，为什么瀑布模型盛行的时候，使用它，开发，失败概率能够达到90？我们想想，如果说做一个项目，然后使用瀑布模型，有一两个失败的，我们可能会从管理的角度入手，会从流程的角度入手，去考虑，是不是人的问题，是不是流程的问题，是不是管理方面的问题，导致了项目的失败，但是，如果说使用这种方式，十有八九会失败，是不是？我们会开始考虑另外一个问题，就是，模型本身是不是有问题了。大家想想，这个问题在哪里？其实是集中于需求分析阶段，为什么这么讲？我们试想一个场景，比如说，一个项目，周期是2年，那么最初的时候，我会做计划，做了计划，做需求分析，做需求分析的时候，毋庸置疑，我会跟客户频繁的交互，为什么？因为需求分析阶段，不就是获取用户需求吗？好，这样子，我跟用户不断的交流，做访谈，做什么联合需求分析，会议，做问卷调查，等等，来获取需求，那么需求获取完毕之后，会得到一个称为需求规格说明书的东西，也就是srs，得到这个东西之后，往往项目团队就开始不跟客户做紧密的交流了，进而做的是什么？就是依据srs，也就是需求规格说明书，来做软件的设计，做设计，做完设计之后，做编码，有些朋友可能在想，我做完设计之后，是不是就把这个设计稿给用户去看一看，往往这样子是很难行通的，为什么很难行通？是因为客户懂的是他的业务，你懂的是技术，这里面会有脱节，你给他一个软件设计稿看，他不一定能够看得懂，所以你要继续进行编码工作，好，编码工作完成之后，做测试工作：好，做完测试了，这个时候，就可以给客户去看了，因为程序已经写完了嘛，系统已经开发完了，也做完测试了？好，这个时候，你作为项目经理，你觉得我们的项目可能是已经要完成了，这个时候，时间已经过去了，18个月，按理说，这个项目周期是20个月的，18个月完成，还是提早完工了？好，这个时候，你作为项目经理，跑到客户那里，去，拿到这个软件，给他们做演示，演示，ppt，这个系统已经开发出来了，是一个什么样子的，怎么去操作的？好？这个时候，问题可能就出现了，当你演示完之后，底下的客户就在讲，他说：哎，这个软件开发出来就是这个样子，怎么和我们之前想象的不太一样？好，他就开始提意见了，比如说，这个报表，这个原来的五项数据，有三项是没必要的，但是还有另外两项是没有加进来的，好，要怎么怎么怎么改，哪个报表里面应该体现出什么样的数据来，哪个按钮应该放在什么位置？好，提了这么通建议之后了，那么，你作为项目经理，作何感想？你是不是立马就拿着这个要求就回去改，当然，你不得不这么做，但是改要从哪里改？要从需求分析开始，改，为什么？因为你做的这一套东西，是依据srs指导而完成的，但是srs本身就没有符合用户的需求，好，你现在已经把软件做出来了，现在用户提出这么多要修改东西，而时间只有2个月了，能完成吗？很难完成，所以说，这样子，就会导致项目的失败。

正结：就在需求分析这样的一个环节里面，需求分析，为什么会出现这种问题，因为需求本身就是不明确的一个东西，与此同时，客户又不懂得计算机技术，而你不懂得客户的业务，两方交流起来了，很很成困难，这样子导致需求获取了不是很准确，同时，需求本身在最初的时候，又不是很明确，所以造成了重大的隐患，需求出问题，设计、编码、测试，会跟着出问题，跟着出错，所以导致一系列的连锁反应，所以，瀑布模型最大的软肋，就在这里，讲到了，它的这些特色，比如说，阶段明晰，每个阶段都有文档的要求，这都是瀑布模型做得好的地方，但它最大的缺陷在哪里？就在于开发那些需求不明确的系统，所以说，瀑布模型这一块，注意这么一些特点，它是不能够开发需求不明确的，也就是说，某个系统，只有需求明确的时候，才能够用瀑布模型来做，开发，这是瀑布模型，正因为瀑布模型有这样的一个缺陷，所以后面的很多模型都是考虑了这个方面，做了弥补工作的，比如说微模型，那么微模型。我们看到这一个图，包括：需求分析，概要设计、详细设计、编码、单元测试、集成测试、确认测试，这么一些内容，这一部分来看，其实和pro模型基本上是一样的，因为概要设计和详细设计，把合在一起，就称为软件设计，先是需求，再是设计，再是编码，最后测试，这是跟pro模型相同的一面，另外一块，和瀑布模型不一样，就是它的测试分成了，单元测试，集成测试，确认测试，与此同时，这些测试的测试计划提前到前面去做，比如说，需求分析完了之后，就开始做确认测试的测试计划，概要设计完成之后，就开始做集成测试的测试计划，而详细设计完成之后，就开始做单元测试的测试计划，微模型，通过这种方式，把测试工作往前面提，这样子能够发现很多的问题，与此同时，这种理念也称为测试，贯穿于始终，就是我在整个的开发过程中，都有测试工作在进行，而不是等到所有的事情全部做完之后，再来做测试，这是pro模型和v模型，它的理念上面本质的一个差异，再来看这个圆形法，圆形法，圆形法，我们之前讲这个信息系统的时候，提到了，也提到了这个圆形，那么圆形法，它主要是用来做需求分析的，它最大的特色就是适用于需求不明确的情况，怎样做，才能够适用于需求不明确的情况。最初的工作还是一样的，比如说，我们要先要跟客户进行交流，来了解，客户，希望做一个什么样的系统出来，然后通过跟客户一系列的交流之后，得到了需求，规格，说明书，srs，这个过程之中，我们不会把srs直接交给设计人员，去开始做设计工作，而是把这个美工交过来，美工叫过来之后，做什么，就依据跟客户交流的这些信息，来画出整个系统的界面，见面，但是不做程序实现，这是很容易完成的一件事情，这个工作耗时了，非常的短，那也许也就是一两天就完成了，好，完成这个界面之后，我就会拿到这个界面给客户去看，客户可能看到界面之后，会有一个直观的印象，感觉是怎么样的，好，通过观察这些界面，流程，用户了，肯定能够发现一些问题，比如，这里和我想象不一样，那里和我想象有区别之类的，好，有了这个东西，我们可以把它记录下来，记录下来，回来之后，就按客户的要求做修改，修改好之后，又拿给客户去看，经过多轮的一个修正过程，这个最终的这个系统的一个样子了，客户了，就有了一个很直观的概念，哎，我会知道，我开发出来的这一个系统，最终是一个什么样的效果，能够做一些什么事情，做的方式是怎么样的，得到的结果，展现，形式又是如何，所以这样子，得到了这个圆形之后，那需求明确了，这是圆形法，圆形法迭代模型，迭代模型，它的主要的思路，就是，通过多轮迭代，得到结果的一个过程，迭代，这个概念，最初了，我们是在中学的数学里面学习到的，比如说迭代方程，有了一个迭代方程，我可以了，先定义某一个x的值，然后把这个值带入到方程里面，算出y的值，算出y的值，y就是一个近似结果，再把y又带到这个式子里面，当成x，当成x的值，带到式子里面，再来计算，通过多轮计算，这个结果就越来越趋近你想要的真实结果，这就是迭代模型，在这个软件开发当中，迭代模型实际上是这么一种思路来的，第一次，我们做开发的时候，不会得到一个，最终产品，只是一个雏形，这个雏形，可能很多功能都还不具备，很多东东都不具备，然后接下来，嗯，就来开始做这个，做迭代，第一轮，完成了，一些功能，给客户用了，用了之后，用户提出来建议，然后做修改，第二轮，把它进行改进，改进，又功能，又强大一些了，又全面一些了，然后再进行改进，再进行改进，进行多轮迭代，之后，形成最终的产品，然后是螺旋模型，螺旋模型是多个模型的一个综合体，包括哪些模型，比如说瀑布模型，比如说迭代模型，好，螺旋模型，第一个是多个模型的综合体，这是第一个特点，第二个非常重要的特点，就是，在这一个模型当中，引入了风险分析的概念，有风险分析的概念了，之前的那些开发模型，其实都没有风险分析的概念的，在螺旋模型里面，才首次提出了风险分析的概念，这是要注意的，然后，这个模型，嗯，从最中心点开始，每经历一圈螺线，经历一圈螺线，那么它的这一个，就会要产生一个软件的版本，产生一一个软件的版本来，那么每一圈螺线，其实都会做很多的事情，就是瀑布模型，那一系列的事情都会做，比如说这个什么详细设计，编码，单元测试，组装、测试，等等，一系列的工作，他都会要做到，而且还要做风险分析，它是以这种循环式的一种模式来进行的，所以我们讲，它也是属于一种迭代模型，它是一个综合体，综合起来使用，就包括我们之前讲到的，pu模型，也可以和其他模型综合起来使用，比如说，我们先用圆形法，获取到用户的需求，获取到需求，之后，有了明确的需求，再用pro模型来做后期的开发，这也是可以的。构建的组装模型，构建组装模型是，就是相对来说，比较新的一种模型，这种模型要求把系统里面的这些功能，组成部件，都做成标准的构建，然后把它组装起来，就形成了一个完整的系统，这样做有什么好处了，好处是很明显的，比如说，用构建组装模型，它可以节省成本，可以缩短开发的工期，还可以提高系统的可靠性，哎，优点是很明显的，那么它是通过什么方式来达到这些效果的，那我来讲一讲，构建组装模型，它是依据什么样的一个流程，来做相应的一些开发工作，如果说我们要用构建组装模型，做一个系统开发，首先，我们会分析这个系统的需求，这和其他的一些开发方法是没有什么太多区别的，第二步就不同了，他会做软件的架构设计，架构设计了，这个架构是一个比较抽象的东西，我们可以简单的去理解，他，就像一个房子的框架，我们现在看到的建房子，不都是钢筋混凝土结构了吗？先把框架搭起来，然后再去往里面塞砖头，来，砌，一堵一堵的墙，把它分隔开来，那一堵一堵的墙，相当于构建，而整个的框框，就是架构，要把这个软件架构设计出来，设计出架构之后，开始看整个系统里面需要一些什么样的构建，需要一些什么样的构建。那么需要一些什么？构建，我们首先从构建库里面来查，找，查，这个构建，是不是存在于构建库里面，如果说这个构建在构建库里面已经有了，那我就直接拿出来用，不用开放，直接拿过来用，就ok了，如果说有相似的，但是不一，不，完全符合要求，怎么办？就把这个构建从构建库里面提取出来，再做一些小的修改，修改好之后，用到目前的这个系统里面来，然后硬是找不到相关的，相同的，这些构建，就重新开发，是这样的一个操作流程来进行的，这是构建组装模型，构建组装模型的一些做法，正是因为我们重复的利用到了以前那些构建，所以说了，开发速度会很快，也比较节省成本，以前的这些构建，已经用到了很多系统里面，这样一来了，相当于是不断在给这些构建做相应的测试工作，不断测试，不断测试，自然你得到的这一个系统也是更加合理一些的，然后这些构建也不会出现问题，那么你开发完这个系统之后，你可能新建了一些构建，新建出来的构建，你又可以把它存到构建库里面，以备以后的系统开发的时候来用，所以说，go，基于构建的开发，就有这么一些优势，那么构建有它相应的一些标准，比如说cable标准，cable标准，比如说come，de，com，come，加标准。比如说，e接b标准，这些标准就定义了，这些构建，应该要用什么方式来写，如果说你在a系统里面用的，e接b标准，写出来构建，那在b系统里面，你用同样的标准，就可以引入这些构建来使用，那么这些构建标准里面，koba标准是由这个omg组织提出来的，come，decom，come，加了，是微软公司提出来的，那么come是比较早期提出来的，那么他提出来之后，嗯，其实就相当于这个构建组装模型的诞生，因为他提出来，用com写出来的组件，可以按人们的思路组合起来，形成一个应用系统，然后以后的话，可以良好的去复用这些构建，这其实就是我们构建组装模型的核心思想，然后为了增加分布式的一些功能，满足分布式系统的需求，所以就在com的基础之上，增加了分布式的一些特点，一些应用，然后形成了decom，形成了decom，那么com加了，可以理解为：com，dcom的一种综合体，混合体，ejb，是由sun公司提出来的，some公司提出来的，就在加瓦体系中去应用的一个东西，这是构建组装模型，了解它的一些基本特色，优点，在哪里，就ok了，接下来看到的是统一过程，那统一过程分了：初始阶段，细化阶段，构建阶段，和交付阶段，统一过程，它是由IBM公司提出来的，这个是统一过程，是由racing的公司提出来的，然后后来是被ibm公司收购的，是这样的一一层关系，所以说，统一过程，最初的英文名也叫rup，rup，那么rup的英文缩写就是reach，公司首字母，加上统一的，这个单词的首字母u，以及过程的首字母p组成的，那么后来这一块是被ibm收购了，收购之后，他就把这个r代表这个瑞显的公司的这一部分，把它去掉了，所以我们在考题里面，看到了，统一过程，u、p，rup，都属于了，这个统一过程，都是同样的一个意思，只是它写法了，有点差异而已，统一过程是一种以架构为中心的，这种开发模型，其实也可以讲，它属于的是这种构建组装模型，为什么这么讲，待会大家看到它的一些特点，就能够明显的感觉到这一点，统一过程分的这四个阶段，每个阶段各司其职，在初始阶段，做的，主要就是确定项目的范围和边界，范围和边界是一个什么样的关系，比如说，我们把这个框框来代表一个系统，那么范围是这个框框里面的东西，框里面这一部分就是范围，边界是什么？就是边上的这一条线，这个框框称为边界，那么确定项目和范围，和边界，有什么价值和意义，很简单，比如说，有一个功能，我要开发，如果说这个功能，在这个框框里面，那必然是要开发的，如果他在框框的外面，是一定不能开发的，框，框外面的，代表，不是这一个项目的范围，我们做项目的时候，应该要明确一点，做的事情，必须是本项目里面应该做的事情，不要超出这个范围去做，然后要识别系统的关键，用力，我们有的时候讲，嗯，使用任何一个软件系统，其实人们80的时间，都只使用到了系统里面20的功能，那么这个20的功能称为关键uni，如果说，一个系统，在实现的过程中，关键用力，这20的功能都没有实现好，那么这个项目，这个系统必然是失败的，所以，在初始阶段，我们就要识别出系统的关键，用力，来展示系统的候选架构，候选架构，这一个词，就说明了一个问题，做任何一个系统，其实可供选择的架构是有多个的，你选a架构，可能性能会比较好，选b架构了，可能安全性会比较高，选c架构了，可能是a和b的一个折中，在初始阶段，我们就会要把可以用的一些候选架构了，都把它罗列出来，供我们来选择，接下来，需要估算项目的费用和时间，再来评估项目的风险，评估项目的风险，这是初始阶段应该做的事情，接下来是细化阶段，细化阶段需要做什么事情，首先要分析系统的问题，领域，然后要建立软件架构基础，建立软件架构基础，实际上就是确定架构，我们之前初始阶段不是展示出了备选架构吗？那么在细化阶段，就要具体选定是哪一个架构，并且要把这个架构把它建立起来，淘汰掉最高风险的元素，也是了，这个阶段需要去做的事情；在是构建，构建阶段，要做的是开发剩余的构建，因为之前我们讲这个基于构建的开发的时候，已经提出来了吗？在以这种方式来做开发的时候，首先我们不是想着要去开发新的构建，而是想着以前构建库里面哪些资源，可以把它利用的上来，哪些利用上来的，就能够直接拿过来用，有些修修改改，也能够拿过来用，然后，如果说实在是不行的话，好，在构建阶段，要开发剩余的构建，开发出剩余的构建，之后，就要做构建的组装与测试工作，测试与组装工作，最后是交付阶段，其实交付阶段会做一些测试和发布的工作，主要是这一块的工作，那么这个测试和那个之前讲的测试；是有区别的，比如说，要进行贝塔测试，大家知道，贝塔测试是什么测试吗？就是在用户的环境当中，由用户来做的测试工作，比如说，我们有的时候，嗯，下载这一个qq软件，下载的qq软件，就会有这样子的一个情况，在里面，下载的版本是测试版，旁边就写了一个beta，这其实就是贝塔测试版，那你把这个软件，把它下下来，之后，下下来之后，然后完了之后，就做这个，就使用这个软件，使用这个软件的时候，其实你就在帮这个腾讯公司做贝塔测试，这就是在用户的环境当中，由用户来完成的测试工作，制作发布版本，制作发布版本，就是我的工作，测试工作都完成了，然后做出一个正式版本来进行发布，然后再是用户，文档，定稿，等等，这么一些，还有培训的一些工作，这成为交付阶段要完成的工作，那么我们可以注意到，从初始到细化，再到交付，就完成了这些阶段，按理说，但为什么从交付到初始阶段，又有一个箭头了，那，从而形成了一个圈，这是因为了rup统一过程，它是一个迭代型的模型，就是完成一轮之后，你可以了，再来进行一轮，这第一轮完成之后，发现了，不，不是，很符合我们自己的要求，那你就再进行一轮迭代，q7，就做一系列的改进的工作。所以，从交付了，到初始了，又有一个箭头过来，可以进行多轮，直到满足需求为止，所以它是迭代与增量的，因为每一个迭代周期，就会增加一些东西进来，还有另外两个特色了，一个是用力驱动，一个是以架构为中心，用力驱动，是指的在这个用rup进行开发的过程中，最初的时候，会做出一个用力模型来，做出一个用力模型来，用力模型就展示出了参与者和系统内部之间的一种交互关系，在接下来，我们会去实现这些用力，把这些用力把它实现出来，把它做出来，做完之后，我们会依据这些用力，来设计，测试用力，所以我们会发现了，在整个的开发流程中，这个用力是贯穿于始终的，由用力来推动一系列的开发工作，这就成为用力驱动，以jr为中心，是指的，我们会在开发的比较前期的阶段，先把这个架构，把它构做好，做好架构之后，然后再来做后期的一些工作，而且把架构放在一个很核心的位置，这成为了以架构为中心，这是rop的一系列的这个特点，那么在这一块，我们需要了解它的这几个核心的特色，这肯定需要了解，然后每一个阶段有什么工作。也是需要了解的，哎，因为之前的很多考察过程中，就会考，哎，以下的哪项工作，不属于细化阶段的工作，或者说，在rup当中，哪个阶段就已经完成了，这个架构的设计，那那你要能够从这个这样的一些特征里面提取信息，来判断，来答题，另外，值得注意的一点是，统一过程，属于一个重量级的模型，往往在企业的大型开发里面，会要用到它！最后，我们来看到敏捷方法，敏捷方法是我们开发模型里面要讲到的最后一种方法，或者说了一类方法，为什么？因为敏捷方法并不是一个具体的方法，它是一系列方法的组合，自适应开发方法，水晶方法，特征驱动开发方法，以及极限编程，都属于敏捷方法，都属于敏捷方法，敏捷方法是在一个怎样的大环境里面产生的了？就是大家都注重流程，注重文档，然后发现这个文档越写越多，但是很多文档写出来之后，以后，再也没有用过，基于这种大环境之下，产生了敏捷方法，敏捷方法是由全世界范围之内，顶尖级的it这一块的专业人士提出来的，他们提出来了，我们做了这么多年的软件，那么流程文档这一块，是越做越标准，越丰富，但这些文档的话，很多时候又用不上，而反而占用了开发人员很多的时间，这就显得得不偿失了，写这么多文档，还不如花更多的精力在具体的编码上面，所以就提出敏捷方法，那敏捷方法，虽然有多种，由不同的人提出来，但都具备一些共同的特色，比如说，敏捷方法，适合于小的团队，小规模的项目，小步快跑的模式，它是一种小步快跑模式，为什么讲小步快跑？因为敏捷方法，它是去掉了很多的文档，只留下几个觉得重要，必备的一些文档，砍掉文档，所节省下来的时间，用于开发，用于集成，比如说，我们要开发一个系统，那按原来的一些做法的话，可能先做需求分析，做他几个月的时间，再做设计，再做编码之类的，按这种流程来搞，那么，敏捷方法不是这样子的，可能先做个一两个星期的需求，就开始做设计，做编码了，他一块一块来，做了一部分，之后，一个月之后，就产生了一个最初始的一个版本，产生，这个版本，给用户去用，好，用了之后，用户提出一些要求，提出要求了，就有变更，就有修改，那么，在这种情况下，敏捷方法是欢迎用户提出变更的，这跟我们传统的思路就不一样了，传统的思路，我们是希望用户尽可能少的变更，为什么？一旦变更，就意味着你的成本有可能超支，你的时间，有可能会超过预期的时间，所以大家都不愿意看到变更，但是敏捷方法思路不一样，他认为，如果说这个东西，用户有可能提出不同的意见来，那么这种意见持题，不如早提，我先给他看看了，之后，他用的过程中有问题，及时就把它调整过来了，通过不断的变更、修改，那么到后期，其实也不会有太多的东西需要去变化了，因为前期该变的都已经变了，所以，他的这种思路，和常规的思路已经有着很明显的一个区别，差异是比较大的，那么，敏捷方法里面，多种方法，里面，最为著名的，属于极限编程，也称为了xp方法，注意，这个xp和我们使用的windowsxp操作系统是不一样的，它是极限编程的一个缩写，xp方法，那么极限编程是最为出名的。但事实上，它并不是这几类敏捷方法里面最好的一种，他的出名，是因为提出他的这一个专家，是专家组里面最牛的，但与此同时，这个极限编程，也是很讽刺的一个方法，当他提出来之后，备受关注，所以当时ibm有一个研究组，就决定，采用极限编程，来完成一个项目，作为极限编程，这一块，甚至是敏捷方法里面的一个标杆性的项目，当时这个项目的规模是比较大的，几百上千人在做的，结果，很遗憾的一点，就是，这个项目做了大概一年多的时间，做不下去了，发现做下去肯定是失败的，结果，就终止了项目，所以说，极限编程的样板工程，都还是失败的，项目，都是失败的，项目，失败的原因是什么？就是因为项目团队过大，项目规模过大，所以导致了他失败，所以由此也总结出来，敏捷方法是适合于小团队，小规模，小步、快跑模式，那下面我们看到了这个极限编程的价值观和原则，他有4大价值观和5大原则，这个四大价值观，包括：沟通、简单、反馈和勇气，沟通，毋庸置疑，对内、对外都是很重要的，对内的沟通，包括程序员之间的沟通，项目经理和这个开发人员和程序员之间的一些沟通，对外有项目组和客户之间的沟通，这两方面都是很重要的，所以属于他；四大价值观的主要位置；简单，他的意思就是，做事情尽量的简单化，现在需要完成什么样的功能，就给他完成什么样的功能，不去过多的考虑以后的一些，这个扩展性，一些问题，尽量简单的，快速的实现它；反馈，就是有任何问题，及时反馈给用户；这个；勇气，勇气，就是我们刚才讲到的，敏捷，方法，是欢迎别人提出变更请求的，这是需要勇气的，你要去面对这个问题；五大原则，其实和这个价值观是很匹配的，一些方向，那敏捷方法，其实具体到一些实践的原则，还有一些很有意思的东西，比方说，结对编程，结对编程，我在国内目前还没看到。有哪一个开发机构真正去用它？原因就是这种模式，老板会很不爽，为什么这么讲？结对编程，顾名思义，就是程序员结着对子来做开发，比如说，a和b是一对的，那么a做开发，做程序的时候，b搬一条凳子，坐在a旁边，看着他写程序，而b写程序的时候，a看着他写，这样倒好，电脑都省了一半了，但对于老板来讲，他也许在想，哎，我请了100个人，结果有50个人在休息，这样子，感觉效率是降低了一半，但事实上，其实不会这样子的，为什么？写过程序的人都清楚，在做开发的过程中，最耗时的并不是写程序，而是调试，程序，遇到错误，调试，需要耗费大量的时间，如果说两个人合在一起，有任何问题，都可以讨论，两个人的水平不一样，然后关注点不一样，调试过程中出现问题，很快就能够找到答案，一个人可能就在这个方面会耗费过多的时间，这是一方面，就是两个人配合了，经过一段时间的磨合之后，然后大家都没偷懒的情况下，可以达到，甚至是超越2个人单独工作的效率，这是绝对编程的第一个好处！第二个好处是什么？就是做人力资源的，这个备份，降低人力资源这一块的风险，我们知道，对于这个信息系统的开发项目而言，如果说某个核心的程序员走了，那这对于项目组的打击来讲，可以讲是致命的打击，为什么？因为核心程序员走了之后，你很难在短时间内，找到另外一个程序员来替代他的岗位，即使他们能力水平相当，也需要一段时间来适应，来了解一些基本情况，所以这个人力资源方面的风险是比较大的，如果说用结对编程，那么走了一个没有关系，另外一个可以延续他的工作，因为他本身就是原来就是结成一对，在做开发吗？之前那个程序员写在吗？他都很清楚，所以也能够避免一些风险，所以，敏捷方法，他提出来的很多条款，都是很有道理的，大家感兴趣了，可以找一些课外的资料，再做一些拓展，但是因为我们考试当中，最多也就考到这些方法的一些特点，所以我们不在这里继续深入的讨论，那么，除了适合团小，团队，小规模的项目，小步快跑模式，这这些特点以外，还要注意敏捷方法，它属于一个轻量级的开放模型，所谓轻量级，就是指的轻文档，轻文档，重量级，也是指的重文档，除了敏捷方法，其他所有的方法都可以归到这个重量级的开发模型里面去，这是开发模型