XP开发方法简介（一）转

Error

XP开发方法简介        1
一 、XP诞生背景        2
二、什么是XP?        2
三、XP开发过程简述        6
四．XP的规则        7
4．1 计划阶段        8
4.1.1建立用户需求        8
4.1.2 发布计划        9
4.1.3 小型版本发布        10
4.1.4 项目开发进度        10
4.1.5 迭代开发        11
4.1.6 建立迭代开发计划        11
4.1.7 人员流动        11
4.1.8现场办公        12
4.1.9 修改不合适的规则        12
4．2 设计阶段        12
4.2.1简单性        12
4.2.2定义系统框架（system metaphor）        12
4.2.3 CRC卡        12
4.2.4确定关键问题的解决方法（SPIKE）        13
4.2.5 勿太早增加新功能        13
4.2.6 坚决重组        13
4、3编码阶段        13
4.3.1  自始至终强调用户的作用        13
4.3.2  编码        14
4.3.3  编码前建立测试单元        14
4.3.4    成对编码        14
4.3.5 串行集成        14
4.3.6频繁集成        15
4.3.7集体代码所有权（collective code ownership）        15
4.3.8 最后的优化        16
4.3.9不要加班        16
４．４ 测试阶段　（testing）        16
4.4.1　单元测试        16
4.4.2      单元测试框架        17
4.4.3       发现Bug        17
4.4.4 验收测试        17
五、小结：XP的特点        18

一 、XP诞生背景
６０年代晚期，７０年代早期，电脑程序员往往应用能够应用的任何方法来开发软件，许多程序员能开发出一些复杂的软件产品，但没有人可以理解，同时，每个程序运行时都会不可避免的出现一些Bug,这就是软件危机。１９６８年，Edsger Dijbstra 给CACM 写了一封信名为Goto Statement Considered Harmful.信中包含了软件工程的核心思想。人们意识到必须有一个更有纪律性的方法来帮助我们开发软件，使得软件的质量及预计花费相一致。
８０年代是电脑程序员的黄金时代，其时已建立了一些软件开发的标准和原则，开发出的软件质量比几年前大大提高，看来只要对所有遇到的问题都创建更多的标准、规则，人们就可以及时交付完美的软件产品。因此人们针对所有潜在的问题制定了越来越多的规则。
然而，人们发现很难真正遵循所有这些规则，整个过程太过复杂，难以理解，一些用抽象的概念写成的文档数量太多，难以管理。试图遵循一个好的大型开发方法犹如加州的淘金热，每个人都迎头前进，结果却失望而归。于是人们又开发了一些软件来帮助软件开发，出现了CASE工具，用于帮助我们遵循这些规则。但它们本身太难应用，实际上很少有人能真正遵循一个大型的开发方法，很多程序员又倾向于应用一些轻量级的软件开发方法，它们包含的标准和规则比较少，易于遵循。
这并不意味着重新回到无规则的年代，学到的教训并未被忘记，人们选择了一些能提高软件开发质量的规则，去掉那些阻碍开发过程的原则，提出一些轻量级、简明有效，易于遵循的软件开发方法。
XP是新型的软件开发方法之一。１９９０年，Kent希望找到一种更好的发展软件工程的方法。他与Ward一起工作，总结了自己简单高效的开发软件的经验，于１９９６年提出的一种新的开发/生产方法――XP。

二、什么是XP?
XP 是Extreme Programming 的缩写，从字面上可以译为极端编程。但是，XP 并不仅仅是一种编程方法，也不是中文中常理解的那种不可理喻的“极端”化做法。实际上，XP 是一种审慎的（deliberate）、有纪律（disciplined）的软件生产方法。
我们说软件生产，而不说“顺口”的软件开发，是因为软件开发常常被误解为代码编写。软件生产从手工作坊式进化到工程化，是软件业不小的进步；但人们在软件工程的实践过程中也逐渐传统的软件生产方法太过“笨重”，难于实施，导致的直接结果是生产成本的上升，于是，人们开始寻找有别于“重量级”（heavyweight）生产模式的“轻量级”（lightweight）生产模式。所谓“轻量级”（lightweight）就是只有很少的一些规则（rule）和做法（practice）。XP 就是在这样的历史背景下在90 年代初出现的。
XP 的鼻祖是Kent Beck 。最初Kent 的希望是找到更好的软件生产方法。在思考和探索的过程中，Kent 逐渐意识到改进软件项目的四个因素。
第一是强调沟通（communication）。
第二是推崇简单（simplicity）。
第三是注重反馈（feedback）。
第四是富有勇气（courage）。
这四个因素后来成为XP 的四大价值观。
有人以为XP 只在非正规的软件项目开发中才存在，而实际上，XP 特别强调客户满意和团队合作，很多商业化的软件公司都采用XP 来开发软件项目。XP强调满足用户的需求，这种开发方法可在任何需要的时候提供给客户可用的软件产品。XP强调遵循用户的需求变化，即使在开发的生命周期晚期，这种需求变化也可以得到满足。在XP 中，开发队伍不仅仅是编程人员，还包括管理人员和客户。但是XP 适合2-10 人的开发队伍。所以大规模的软件项目XP 不大能够胜任。
经过多年的应用和实践检验，XP 总结出了软件生产的十余条做（practice），涉及软件设计、测试、编码、发布等各个环节。


下列几点是必须要做的：you must
1.        test before code编码之前写出测试
2.        program in pairs成对编码
3.        integrate frequently频繁集成
4.        be rested不要加班
5.        communicate with the customer daily每天与用户进行交流
6.        follow the customer’s priorities遵循用户的优先级
7.        leave the software clean and simple by the end of the day每天清理代码
8.        adapt the process and practices to your environment适应开发方式和环境

XP主要在四方面提高了软件开发：
１．强调交流（communication）
       XP teams:
Use a common system metaphor.
Work in an open workspace.
Continuously integrate the code.
Have a customer teammate.
Program in pairs.
Collectively own the code.
Frequently plan with
and report status
to the customer.

２．推崇简单（simplicity）
    XP teams:
Do the simplest thing that could
possibly work.
Continuously simplify and improve the
design through refactoring.
３．注重反馈（feedback）
     Write test cases before production code.
Develop in small releases,
And even smaller iterations.
And even smaller tasks.
And even smaller tests.

４．要有勇气（courage）
     XP team members are not afraid to:
Stop when they are tired.
Let every business decision be made by the customer.
Ask customers to reduce the scope of a release.
Ask their peers, or customers, for help.
Design and implement only what is needed for today, trusting that we can add, tomorrow,  what will be
needed tomorrow.
Make changes that improve the function or structure
of code.
Fix the design and retrofit existing code when the design is shown to be inadequate.
Throw code away.
Change the process when it’s not working.

XP 强调四种价值：交流，简易，回馈，勇气。XP开发过程中，程序员与用户及其他程序员之间经常保持交流，要求开发设计尽可能简洁。同时XP要求从第一天就进行测试，以获得反馈信息，尽早提供给用户可用系统，然后听取用户的反馈，进行修改，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。
XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，也就是说，看上去没有意义的每个部分，组合起来却实现了一个有效的开发过程。XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它尤其适合中小规模的团队进行一些需求不甚明确或需求变化很大的开发。XP改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
第二问题：XP 带给我们的变化
通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。
这是真的吗？XP 认为事实并非如此。
一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说；“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。
另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。
你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。
一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。
XP 开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。
第三个问题：我们什么时候用XP
XP 方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。
XP 方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。
XP 方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。
***另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。
在XP 方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。         假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。
三、XP开发过程简述
XP流程图如下：





                                    测试情况
user stories
        请求        新的user stories        bug
        计划速度
体系结构
测试信号        系统？        发布计划        版本方案        最新版本  验收  客户审核   小
        测试           版本
        不确定的
        估计        确信的        下一个重复
        估计
       
测试信号


用户提出User Story后，可根据这些需求制订发布计划，根据发布计划确定每一次的迭代计划，一次迭代中实现一部分User Story。当有新User Story加入或项目开发速度变化时，需要修改发布计划。一次迭代完成后，对最新版本进行验收测试。如果出现Bug,要从新进行此次迭代测试，否则就可向用户发布此次可用的系统产品，然后进行下一次迭代，实现其它User Story。
在XP的计划阶段，User Story是关键所在，可以把User Story手写或打印在卡片上，通过手工处理这些卡片，简单高效地确定项目的内容和计划。
在XP系统体系结构设计阶段，通常用Architectural Spike 或原型来建立一个简单设计，此阶段，CRC卡片是一个简便的工具，它有助于所有技术人员理解整体设计，并提出自己的想法。XP的独特之处在于采用了一种叫重组（refactor）的技术，可以创建更好的体系结构。
编码阶段中，代码质量非常重要，提高代码质量的方法包括成对设计、重组和在编码前建立测试。
测试是非常重要的阶段，好的单元测试及验收测试是XP项目的检证印记。XP认为应该是让开发人员向用户证明代码可正确运行，而不是用户来证明代码崩溃了。
  
四．XP的规则
XP有自己的开发标准，同时支持其他标准，两者融合在一起形成一套良好的开发方法。
计划
1 ．填写用户故事卡片
2 ．通过发布计划会议确定开发日程
3 ．频繁的发布小的版本
4 ．计算项目开发“速度”
5 ．一个项目划分成多个开发周期
6 ．通过周期计划开始一个周期
7 ．在开发组间交换成员
8 ．每天开始的时候进行一次“简便会议”
9 ．当xp 出问题的时候“修复”它。
设计
1 ．简单性
2 ．选择一个系统隐喻
3 ．在设计会议时使用CRC 卡
4 ．通过“侦察”来降低风险
5 ．在开始不要设计太多的附加功能
6 ．任何时候只要有可能就要refactoring
编码
1 ．客户应该是小组的一员
2 ．编码必须写到规定的水平
3 ．编码之前先写单元测试
4 ．所有的代码都由两个人完成
5 ．同一时间只有一组（2 个）人集成代码
6 ．代码经常整合
7 ．所有人拥有所有代码
8 ．把优化工作放在最后
T 9 ．不超时工作
测试
1 ．所有的代码都必须有单元测试
2 ．所有的代码在分布之前必须通过所有单元测试
3 ．当一个BUG 发现时，就增加新的测试
4 ．我们经常运行验收测试，并公布分数。

下面我们分别详细介绍上面的规则和经验

4．1 计划阶段
4.1.1建立用户需求
XP中，用户需要建立Use Story。Use Story与用户的目标相一致，但不是完全相同。Use Story是开发人员分配任务的基础，评估项目进度的依据，和完成测试的起点。
USER STORIES 和USE CASES 有着一样的目的，但其实却是不一样的。在实施计划的会议上，USER STORIES 都是用来帮助估计时间的，它们替代了大量的需求文档，USERSTORIES 通常是由客户撰写并用来描述他们需要的系统的功能，它们类似于情节描述，但是它不仅仅描述用户界面，它们是有一定格式，一般大概三句话，完全由用户用自己的语言写成，用来描述任务，不包含任何的技术用语。
USER STORIES 也产生可验收测试，一个或者多个验收测试必须增加以检查USERSTORIES 是否已经被正确的采用。
USER STORIES 最难以理解的一点就是，它怎样来区别于传统的需求分析的。它们之间最大的区别是在于分析需求的详细水平上，USER STORIES 仅仅提供足够于风险分析的情况，它提供的情况用于估计USER STORY 所需要的开发时间，当开发者对USER STORIES的大概情况做出判断后，他就去见客户，面对面的接受一个更详细的需求描述。
开发者估计多长的时间可以完成这个USER STORY ，在XP 的经验中，1- 3 周是理想的USER STORY 开发时间，理想的开发时间是指在没有打断的情况下将USER STORY 代码实现所需要的时间，不是由别人来指派，而是由你自己才确切的知道任何去做。长于三个星期，就意味着你应该将该USER STORY 细分，如果小于一周，你就需要将USER STORY 合并。根据XP 的经验，在发布计划的时候，一个项目中USR STORYS 的数量最大不应该超过80 个，最小应该不小于20 个。
USER STORY 和需求文档的另一个区别是集中在使用者的需求上。在USER STORYS 上，你必须尽量的避免接触太多的特定技术（如：数据的流程，算法等）细节，你应该尽量的保持STORIES 集中在描述用户的需要和价值上，要尽量反对去描述特定的界面输入输出。
流程
流程：在XP 中，UserStory 是一个关于系统如何去解决一个问题的情节。每一个User story 用一张卡来书写，代表着一块以某种方式跟客户相关联的功能模块。从整个项目的计划到开发的过程（游戏计划，提交日程安排，反复计划）中所有的卡片都被保留，他们被客户优先提出，被开发者评估，然后被分给软件工程师以便他们安排开发的日程，当有一些功能测试被用户拥有时，这就意味着UserStory 真正的完成了。
最后附图常用的User story 卡的DEMO ：
客户故事与任务卡
日期: _______________ 类型: 新__ 更改__ 加强__功能   测试:_______

故事号 #: ____________优先级 用户:____ 开发人员:______

优先级参考:_____风险:________开发人员预计时间:_______________

任务描述:


备注



任务跟踪:





4.1.2 发布计划
发布会议用来创建一个版本发布计划以产生所有的工作计划，然后该发布计划会议为每个流程创建流程计划。技术人员做技术决定，商业人员做商业决定，这一点十分重要。发布计划有一系列的规则，允许该项目的每一个参与者都做出自己的决定。这些规则定义了一种方法以讨论出一个人人都可以接受的时间安排表。
发布计划会议的实质是为开发团队预计每个USER STORY 所需要的理想的程序工作周。理想工作周是指在没有任何阻碍（没有依赖，没有额外的工作，只包括测试）的情况下，实施一个USER STORY计划所需要的时间。而客户则将决定什么USER STORY 最重要或者最优先完成。
USER STORY 打印或者书写在卡片上。开发者和客户一道讨论这些卡片，以创建一组USER STORY 。我们建议尽早交付一套有良好商业意义的可使用、可测试的系统。你可以按照时间或作用域安排USER STORY 。程序评估用于决定在给定时间之内可完成多少个STORY（按时间）或一组STORY 要多长时间才能被完成（按作用域）。当按时间安排时，程序进度增加迭代的数量以决定能够完成多少USER STORY；按作用域安排时，项目进度将预计的完成USER STORY 的全部工作周拆分以决定多少次迭代，直到版本发布准备就绪。详细安排个体迭代只能仅在每一次迭代开始之前，而不要提前。发布计划会议曾被称为计划竞赛，其规则见PORTLAND PATTERN REPOSITORY 。
当最终版本发布计划创建完成但不能令人满意时，很多人试图仅仅变更对USER STORY的预计。切不可这样做。预计是有效的，而且将被应用于迭代计划会议。现在低估USERSTORY 会在将来引发种种问题。取而代之的是应讨论出一个可接受的发布计划，直到开发者、用户和管理人员都能够同意。
在发布计划中，项目分为4个方面：开发范围、资源、时间和质量。必须明确制定出这些方面的具体要求。
开发范围是需要完成的任务；
资源是可用的人员；
时间是各阶段版本发布的日期；
质量是最后提交的系统应该具有的性能。
管理人员只决定其中的三个参数，其余由开发人员决定。注意，降低质量将与其它三个变量产生不可预见的冲突。实际上，真正需要改变的只是三个变量。同时，要让开发人员降低用户对靠一下子雇佣过多人手以求立即完成计划的期望。

4.1.3 小型版本发布
开发小组需要经常向用户提供系统的部分完整版本。每个版本都能作为一个小的版本执行，完善一部分用户需求，并通过了一些测试。通过经常发布小型版本，及时反馈各种意见，使系统的开发不偏离轨道，保证开发进度，早日完善和简化用户的需求。减少各种修改的成本。
4.1.4 项目开发进度
用于衡量项目开发的快慢程度。其方法是统计每次开发实现时完成了多少用户需求或规定的设计任务。
在每次的版本发布计划会中，当前完成的任务是继续分配任务的基础，通过对剩余任务的估计可以检验项目开发的最终进度。但用开发人员数目或开发实现中需要的人数决定项目的开发速度不合理。实际上保证项目开发速度和时间的关键在整个用户需求的定义情况。需求定义的准确、明确，能明显减少修改次数，少产生疑问，直接减少开发中的迭代次数，从而减少时间和经费支出。
当项目的开发时间超过计划的时间时，应该举行版本发布，或重新评估以前制定的发布计划。由于经常有维护变化，所以修改发布计划是必须的。
4.1.5 迭代开发
迭代开发增加了系统开发的灵活性。一般把整个开发划分为大约 12个迭代过程，每个过程持续1-3周。


4.1.6 建立迭代开发计划
在迭代开发开始前，应该确定一个明确的开发计划和开发进度。用户要在开发计划中确定每个开发迭代阶段中必须完成的用户需求、测试和版本发布时间。还有修改验收测试失败的需求。然后将这些计划转换成各阶段的设计实现任务，成为开发人员分配的详细设计计划。
每个任务的理想开发时间是1-3天，开发时间的长短由接收任务的开发人员决定。
项目的开发速度可以衡量迭代任务的轻重。所有开发任务的理想开发时间加在一起不能超过以前的开发速度。如果迭代任务太重，用户应该推迟某些需求的实现。如果过轻，可以增加一些任务，尽量完善需求。迭代开发阶段以天衡量开发速度。而非以周，这样可以更精确的控制开发进度。
在开发延期的情况下，就能显示出单元测试和系统重构的重要性。不应该在完成计划规定任务前完成其他额外的任务，否则有可能拖延项目进度。但也不能随意修改任务和用户需求的时间评估。系统的进展依赖于固定的评估。
在开发过程中，应注意开发的速度和是否有用户需求的开发被拖延了。出现问题后，应该及时重新评估和磋商。一般可能每经过3-5次迭代开发后，就需要重新评估用户需求和制定新的版本发布计划。
总体而言，迭代开发增加了系统的灵活性，可控性。
4.1.7 人员流动
为避免产生知识缺陷和编码时有瓶颈，需要对小组成员做及时调整。如果一个小组的工作由某人独立负责，在其离开后将有大量的工作需要重新开始，那末这部分的工作将成为当前整个开发任务组的瓶颈。
许多公司都重视交叉培训，一般也不让单人负责单独部分的开发。这样一来可以减少许多问题。XP中采用让开发人员在代码库设计中流动和双人开发的策略。使大家相互交叉了解整个系统的需求和设计，提高团队的开发效率，使开发小组的组建灵活，开发人员负担均衡。
XP的双人开发策略是一个核心技术，提高工作效率，保证设计实现任务的连续性，但又不断有创新。（program in pairs）
4.1.8现场办公
XP认为传统的项目会议中，参会人员不愿意发言，而偏向聆听，效果和效率都不好，也浪费资源和时间。因此他鼓励每天召开例会，讨论问题和解决办法。这样一来避免了传统方法论的缺陷，还能集中参加会议的人员，在电脑前直接浏览代码，直接验证解决办法是否可行。
4.1.9 修改不合适的规则
在实际的开发过程中，有些规则是不适用的，应该及时修改。整个团队讨论哪些部分需要修改，确定后整个团队都要遵循。
4．2 设计阶段
4.2.1简单性
XP的一个重要原则是保持设计的简单性。其优点在于设计和实现时间短。如某部分太复杂，应该逐步将其简单化。在设计时，不要把没有确定的功能实现加进去。
4.2.2定义系统框架（system metaphor）
如何命名对象对理解系统的设计和代码复用很重要。用system metaphor可以让所有成员都理解系统的定义规则，从而协调工作。
4.2.3 CRC卡
XP使用CRC实现系统设计。CRC卡的最大好处在于能充分体会到面向对象技术的优点。他允许组内所有成员都可以参与设计，参与人员越多，越可能产生好想法。
CRC卡的编写有一定的规则，但无须完全遵从这些规则，可以适当简化。
4.2.4确定关键问题的解决方法（SPIKE）
为技术难题和设计难题找到解决答案。一般是用一个简单的设计来寻求负责问题的解决方案。用户可以只关心目前出现的问题，而不管其他问题。从而降低技术风险，增加用户需求评估的可信性。
如果一个问题妨碍整个系统的开发时，应该为解决此问题安排专门人员解决。
4.2.5 勿太早增加新功能
XP强调按部就班的完成任务。增加新功能时，有可能使系统更完善，但系统有可能当前并不需要这一功能，功能的增加只能加重开发人员的负担，拖延进度。一般只需要关心当前的工作内容就可以了。
4.2.6 坚决重组
一般大家都尽量少修改已经可运行的代码，但XP认为这样做是低效率的，通过重组，可以提高代码的效率，和减少系统的开发时间。同时使每个新代码简单，易理解、修改和扩展，增加了系统的效率。
开发人员一定要勇于修改自己的设计错误。
4、3编码阶段  
4.3.1  自始至终强调用户的作用
     XP 的要求并不多，其中之一是尽可能发挥用户的作用，用户不仅可以帮助开发小组，而且本身就是开发小组的组成部分，XP项目开发所有阶段都应该有用户的参与，最好是直接面对面的参与，最好在每个开发小组中有一名或更多的用户参加。
     在确定User Story 时，用户在开发人员的帮助下完成User Story的确定，并作出开发时间的评估及确定User Story的实现优先级。用户的参与能使User Story包含绝大部分系统设计应有的功能。
     在发布计划讨论时，开发人员和用户一起协商确定一个将发布的版本应包含哪些User Story以及发布的时间。发布计划中应定义增量发布信息，允许尽早向用户实现一些功能，这样用户可尽早试用此系统，然后给开发人员提供反馈信息。
由于User Story不涉及细节，开发人员必须与用户交流以获得足够的细节来完成设计任务。
功能测试中仍然需要用户帮助，用户可帮助创建测试数据，计算或证实测试结果。可能在产品发布前夕会发现系统不能通过所有的功能测试，此时应由用户来检查整个测试过程，决定产品是否可以发布。
    表面上是乎很浪费用户的时间，但事实上，由于不需要详细的需求规格说明书，不会交付一个不合格的系统，用户的时间从一开始就被大大节约。
4.3.2  编码
    编码必须格式化，符合一定的编码标准，这样使得整个开发小组读和修改编码比较简单。
4.3.3  编码前建立测试单元
从一开始就建立测试单元是XP的特性之一，XP认为编码前先建立测试User Story会使编码更快更容易。
建立单元测试有助于开发者真正去考虑什么应该做，通过测试而使需求明确，这样在用可执行代码实现规格说明要求时不会产生歧义。同时，建立单元测试有助于系统设计，有一些系统的单元测试非常难做，因为这些系统往往先编码、然后考虑测试，而且这些功能往往由完全不同的小组完成。如果先建立测试，往往会被这样一种愿望影响，向用户证实一切有价值的东西，这样的设计往往易于测试。
    先建立单元测试可以这样完成：先建立一个测试来定义手头工作的某些方面，然后以最简单的编码通过这次测试，接着建立第二次测试，增加一些代码来通过这次测试，但不能有第三次，所有的功能必须在两次测试中完成。
    编码应该简单明了。其他人员只要浏览测试即可明白如何使用新代码。
4.3.4    成对编码
成对编码指所有产品的代码由两位开发人员在同一台机器上共同完成。成对编码提高了软件质量而不影响交付时间，两个人在同一台计算机上工作与分别在两台机器上工作能为系统增加同样的功能，而且可能质量更高，同时节约了资源。
成对编码的最佳途径是两人并肩坐在计算机旁，一个人在战术上考虑方法的实现，另一个人从战略上考虑方法是否恰当。习惯这种编码方法需要一定时间。
    成对编码另一个好处如前文所述，它有利于人员的流动。
4.3.5 串行集成
如果不控制源代码的集成，开发人员测试代码时会认为一切都很好，但由于源代码模块的并行集成，源代码的结合体还从未经过测试，不经检测会产生很多的集成问题。
如果不存在一个明确的最新版本，问题更严重。这不仅指源代码，单元测试也是如此。如果没有一组完整、正确、一致的单元测试，可能会费力找一些并不存在的BUG，而真的BUG没有找到。
一种方法是开发人员负责自己开发的类，每个类的开发者保证每个类的代码已正确集成，这会降低错误，但类之间的关联可能任然会有错误。这不能解决整个问题。
另一种方法是设置集成员或集成小组，但一个人不能完成由许多位开发者开发的代码集成。而如果采用集成小组，假如几个星期才集成一次，这又浪费了人力资源，这种情况下，开发人员往往会使用代码库中的错误集成的旧版本。
这些方法都不能根治整个问题，开发人员一面要并行开发，能对所要求的任意部分作修改，另一方面又希望集成不出错，不应限定严格的串行开发，也不应去考虑复杂的集成问题。应该重新考虑这个问题，解决方案很简单，让开发者自己来作严格的串行测试（或称单线程集成），所有源代码有次序地发布到源代码库，一个时刻只有一组开发者在进行集成、测试及修改。单线集成可以保证最新版本的一致性。上述方法并不意味着不可以在自己的工作站上随时对修改进行集成，只是在未轮到前不能向全组发布你的修改。
    这种方法需要一定的锁机制，可用令牌方法实现，经常性的集中和发布代码可以缩短持有令牌的时间，也就减少了等待令牌的时间。
4.3.6频繁集成
只要需要，开发人员应当随时向代码库进行代码的集成和发布，而不应当使变化超过一天，持续集成有利于避免开发的分歧性及零碎性，这往往是开发者不相互交流哪些代码可重用或共享而造成的。开发人员应在最新版本上工作。使用旧版本会出现集成问题。
    经常的集成可以不必在交付最后期限到前花费几个星期来做系统集成。
4.3.7集体代码所有权（collective code ownership）
集体代码所有权鼓励每个人对系统所有部分作出贡献。每个开发者可以对代码的任何一行做修改，增加功能、修补Bug、重组。
这一点很令人难以理解。不能想象整个团队一起来设计体系结构而没有主要设计者。但是任何一个大的系统不可能在一个人头脑中产生，事实上系统体系结构已分散到整个小组中，只能依赖测试来对整个代码库把关，任何代码在分布前必须通过测试。
如果有需要，任何开发人员可对任何类进行修改然后发布到代码库。由于频繁的集成，开发人员并不会意识到一个类已被修改或扩展。
　　 小组中的任何人都应该有权对代码进行更改来改进它。每个人都拥有全部代码，这意味着每个人都对它负责。这种技术可以让人们对部分代码进行必要的更改而不用经过代码拥有者个人的瓶颈。每个人都负责这一事实消除了无代码所有权所带来的混乱。
　　“每人拥有所有代码”与“没人拥有代码”的说法并不一样。没人拥有代码时，人们可以随处进行破坏而不必负任何责任。而 XP 说，“如果是您破坏的，应该您来弥补。”我们有一些必须在每次集成之前和之后运行的单元测试。如果您破坏了某些事物，您要负责进行修补，无论它位于代码的哪一部分。这需要极端规则。可能这是名称中带有“极端”的另一个原因。
4.3.8 最后的优化
优化应该在最后进行，不能试图猜测系统的瓶颈在哪里，而应该去测试。
4.3.9不要加班
超时工作会使小组成员没有精力，如果项目需要加班来完成，这个项目一定会被延迟。应该在分布计划会议上修改时间计划或内容计划，同时，一个项目不能按时完成时，增加人手也不是一个好主意。
４．４ 测试阶段　（testing）
在 XP 中有两种测试： 单元测试、验收测试。
开发人员在他们编写代码的同时编写单元测试。客户在他们定义了素材后编写验收测试。单元测试及时告诉开发人员系统在某一点上是否“工作”。验收测试告诉团队系统是否执行用户希望它执行的操作。
4.4.1单元测试
XP的单元测试有一些不同之处，首先，应该建立或下载一个单元测试框架来创建自动的单元测试集；其次，应该测试系统中所有的类；最后，应该在编码前就建立测试。
单元测试的一般步骤：
1.        创建测试类。测试类的类名要与被测试类的类名保持关联。如果被测类的类名是Doctor，那么测试类的类名应为DoctorTestCase.
2.        创建测试对象，为对象定义方法，并测试这些代码。
3.        写测试用例。
4.        执行测试用例。如果测试通过，跳到6步；如果测试失败，继续下一步。
5.        调整和修改或增加代码，重复4、5步，知道通过测试。
6.        发布模块代码及其测试用例。

单元测试应该同所有测试的代码一起发布到代码库中。未经测试的代码不能发布，遗漏的单元测试应立即补上。
有人会认为单元测试花如此多的时间很不值得，事实上，自动的单元测试通过发现或防止Bug使建立单元测试的花费得到高得多的补偿。
另一个误解是单元测试可以在项目的最后几个月完成。但如果没有单元测试，整个开发会拖延，最后几个月可能会用于做别的事情，即使用于做单元测试，时间可能会不够，因为发现所有的问题需要时间。
单元测试使集体代码所有权成为可能，XP要求所有的代码在发布前必须通过所有的单元测试，这样可以确保实现所有功能。单元测试也使重组成为可能。每个小的修改后，单元测试可验证结构上的修改并未引起功能的变化。
为验收测试及回归测试建立一个单独的通用单元测试集使频繁测试成为可能。这样可以对最近的修改做快速集成，然后在测试集上运行这个最新版本。如果测试失败，这个个人最新版本就与小组最新版本不兼容。用自动单元测试，可以把一系列修改很快融入最新版本中，在很短的时间内发布。
经常加入新功能需要修改单元测试来反映功能变化。
单元测试为有效性测试和回归测试提供了安全网，这样可以有效地重构和集成。编码前建立单元测试非常有利，它可通过固定需求来集中开发者的注意焦点。

4.4.2 单元测试框架
人们有一个普遍的概念，单元测试是一种测试工具，事实上它与编辑器、编译器一样是开发工具，应该在开发的过程中用它，而不是等到项目的最后一个月。单元测试框架有助于需求形式化、结构化、明晰化，也有助于写代码、测试代码、集成代码，发布及优化。项目一开始就要建立测试框架。
KENT BECK曾经为Smalltalk写过一个测试框架，叫Sunit,帮助开发小组进行测试。后来又与别人合作，写了for jave 的测试框架junit。现在，已经有了多种测试框架。如：CppUnit, PerUnit,VbUnit,Pbunit等等。
除了语言不同外，所有测试框架的原理都是一致的。
建立“TestCase”类的子类用来包含所需测试的各种方法。每个测试用例均以“Test”打头起名。如 “TestCreation” 、“TestSelection”、 “TestRemove”等。通过收集命名为 “Test…”的方法，测试工具会自动形成一套相应的测试框架。许多测试框架都已被建立，可从xp.programming.com中下载。
如果没有，你也可以自己构造测试框架。
测试框架依次自动执行所有的用例。这些用例被一个叫做standard setup method 的方法初始化（这个方法可以替换），被一个叫做tear down的方法拆卸。这样可以确保所有用例都在一个干净的环境中执行，一个用例的错误不会影响到其他用例的执行。
大多数的测试框架都有一个简单的用户界面，可以通过用户界面来控制用例的执行、显示执行进度、查看执行结果。
测试框架简单易用。
4.4.3       发现Bug
产品中的Bug需要建立验收测试来防止。通过一个缺陷验收测试（failing acceptance test）开发者可建立单元测试来显示更多源代码的缺陷。修补Bug时，当单元测试１００％通过后，再重新运行缺陷验收测试以证实Bug已被修补。
4.4.4 验收测试
验收测试由User Story中产生。在一次迭代中，迭代计划会议选定的User Story被转换成验收测试。一个User Story可有一个或多个验收测试，以确保功能的实现。
验收测试是一个黑盒测试，用户负责验证验收测试是否正确，并决定哪个失败的验收测试具有最高优先级。
一个User Story直到通过验收测试或才被考虑完整，这意味着每次迭代后都要建立新的验收测试。
质量保证是XP的重要部分，一些项目中质量保证由一个特定小组完成，其它则由整个小组共同完成。XP要求开发紧密地与QA相联系。
验收测试应该是自动的，这样能经常运行。验收测试的评价向整个小组公布，在每次迭代时间期限内完成失败测试的修改是整个小组的责任。
验收测试的名字从功能测试而来，它更好地反映了这样一个目标，这是达到了用户要求，系统可被接受的保证书。

五、小结：XP的特点
它是一种轻量级的软件开发过程，正适用于小软件开发队伍。
强调为了写出代码，你必须先写一个小的测试程序，这样你就对系统有了一个把握，然后再扩充系统，再进行修改。它提倡相对概念，也就是让一对儿程序员写代码，相互取长补短（在这一点上我们很支持他，两个人干活总比一个人强）。两个人在沟通的时候就有一些新的发现。它的说法和传统的软件工程想法完全不一样，传统的软件工程认为一次设计成功，然后再集中精力编程这样最好。 XP的基本思想是以简单的模型开始，然后再向上加一些东西，然后再让这个东西向设计目标靠拢，直到成功。这样一来，组内所有成员的工作就不分了，所有的人就都得分析，编程，测试，共同开发。上面已经说过了，因为有成对的程序员进行开发，因此交流很多，因此不需要什么纸头上的东西。
XP 规定了一组核心价值和方法，可以让软件开发人员发挥他们的专长：编写代码。XP 消除了大多数重量型过程的不必要产物。

carechen

有点意思