浅谈极限编程
摘要：介绍了敏捷方法的特点以及与传统软件工程方法的不同，还详细介绍了极限编程的特点、核心价值和核心实践、项目流程图以及自动化支持工具，最后针对现在软件开发过程中如在确定需求、制定项目计划、沟通和反馈以及分工等方面而经常出现的一些问题，提出了用敏捷开发方法中最重要的极限编程(Extreme Programming,简称XP)的一些核心实践解决这些问题的思想。
关键词：敏捷方法；极限编程；迭代周期；测试；
1.引言
传统软件工程方法强调系统开发的早期计划和需求调查，开发过程中要严格遵守各种细节和标准文档。在软件开发过程中，由于外界环境变化或需求的不断改变，要求开发人员必须对当前的开发工作有一个实时的改变，这种方法称为敏捷软件开发方法。而极限编程技术(Extreme programming XP)是其中最具代表性的开发方法。
2.敏捷方法概述
2.1敏捷方法的主要特点
从大体上看，软件开发模式主要分为工程方法( engineering methodologies )和敏捷型方法(agile methocdologies)两种。近年来，敏捷型方法越来越流行，主要特点【1】是：
（1)敏捷型方法是“适应性”而非“预见性”。工程方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在一般情况下工作良好，但需求环境等有变化时敏捷型方法更加灵活。
（2)敏捷型方法是“面向人”的，而非“面向过程”的。工程方法中最显著的特点是把工程的开发作为一个大的生命周期，各个阶段的人完成不同使命而敏捷型方法则是指出了一种思想一些规则，指导并贯穿整个开发过程。
敏捷型方法包括极限编程(EXtreme Programming，XP)、CockBurn的水晶系列方法和Highsmith的适应性软件开发方法等.其中XP是较为流行的一种轻量型开发方法，其主要特征是适应环境变化的需求，充分发挥开发人员的主动精神。
2.2敏捷方法与传统的软件工程方法的不同【2】
（1）敏捷方法重视个人的创造力和相互沟通甚于软件过程(process)和软件工具;
（2）敏捷方法重视当前软件甚于理解文档;
（3）敏捷方法重视用户合作甚于仅仅依赖合同;
（4）敏捷方法重视对变动的响应甚于一味遵循计划。
此外，传统的软件开发方法常常提供一整套的繁琐的规则，希望能应付各种不同的情况;而敏捷方法只是提供很少一部分需要在所有的情况中都遵循的原则，希望依靠开发人员的创造力，根据原则，针对不同情况导出合理的实践准则。敏捷方法认为开发团队个体的创造力是对付当今越来越复杂的软件开发和频繁变动的唯一办法。
3.极限编程简介【3】【4】【5】
极限编程是由Kent Beck于1999年提出的一种“轻量型”的以编码为核心任务的灵话软件开发方法。与传统的软件开发方法不同，XP摒弃了大多数重量型过程中的中间产物来提高软件开发速度，它是基于对影响软件开发速度的因素进行考查而发展起来的。这种开发方式适用于经常面临需求不明确或者需求快速变化的小到中型的软件开发团队。由于XP的迭代特性使得其能够在开发过程中对需求的变化有很好的适应性，从而XP的目标便是:在最短的时间内将较为模糊、变化较大的用户需求转化为符合用户要求的软件产品。
3.1极限编程的特点
（1）XP有一个最重要的特点，就是对测试极端重视，并将其作为开发的基础。
（2）XP采用渐进的迭代开发过程，比如在开发日程表中安排12个左右的迭代，每个迭代过程1--3周，每一次迭代结束都会发布给用户一个更好的过渡版本。
（3）XP是让人耳目一新的新方法。它的成功之处，在于强调客户的参与，促进团队工作。
（4）对于需求不断变更的风险项目，XP得心应手。这些项目会取得更大的成功。开发人员效率更高。
（5）XP制定了简单的规则和实践，初看似乎很笨抽，甚至幼稚，但很快就备受欢迎。客户喜欢软件开发过程中的参与，开发人员无论经验水平，都变得积极主动。
（6）规则和惯例相互支持。共同构建了一种新的开发方态效率得以提高，成本得以降低、阻碍得以减少。
3.2极限编程的四个核心价值和十二个核心实践
XP的思想浓缩在它的四条价值观上:沟通(与客户以及开发团队内部持续的交流)、反馈(通过单元测试和功能测试获得快速反馈)、简单(将焦点放在最小限度的解决方案上，积极寻求更简单的解决方法)和勇气（勇于改进代码的设计和质量）。这四点是XP的目标，也是要求，更是成功的必要前提。
极限编程的12条实践:
XP项目应遵循的实践准则有12种:现场客户、小版本、系统隐喻、代码共享、每周40小时工作制、规划策略、编码标准、测试、简单设计、重构、配对编程、持续集成。XP的革新在于把所有的实践放在一起，以便它们互相支持，让一些实践的优势弥补其它实践的缺点。比如，在代码共享、成对编程、测试、持续集成、系统隐喻等的支持下，重构系统就易于执行;测试能保证重构不造成破坏;持续集成可以很快发现重构引进的冲突和破坏。
3.4极限编程项目流程图
图中“用户故事”同时产生“需求”和“测试场景”。从需求定义开始，XP省略了常规的系统和架构的设计步骤，在进行初步“架构探索”后，就从简短的“计划发布”直接进入编码的迭代循环。“测试场景”则用来进行功能测试。编码和设计是同时进行的，而且特别强调测试的重要性，提倡测试驱动。测试驱动的编码方式实际是一个循环：写对应新功能的测试一运行测试发现错误一编写代码一运行测试成功一写对应新功能的测试。最后测试完成得到“用户认可”后进行“小型发布”。
3.5 XP使用的自动化支持工具
XP强调持续发布与集成，以及测试驱动的开发理念，如果没有自动化工具的支持，发布与集成测试的工作量将无法忍受。例如JUnit可以应用于单元测试，也即对某个类模块的测试；Ant是强大的集成工具，适用于快速和频繁的集成交付。XP还有其它众多可以使用的自动化支持工具，它代表着过程管理的新趋势:从越来越多的文档转向使用简单、清晰的工具，表中列出了常使用的一些自动化工具。
4.用极限编程解决软件开发项目中的常见问题
软件开发项目中常见的问题【6】有：需求把握不充分；难以确定项目计划；缺乏沟通和反馈；分工和地位的不合理。极限编程在很多方面都和我们传统意义上的软件工程不同。它在理念、符理和项日计划方法等方面也和传统的软件开发过程不同。XP的这些特点和方法在软件工程和其他管理活动中都有借鉴意义，能解决软件开发中的一些问题。
（1）需求把握不充分
这是软件开发中经常会遇到的问题。这种问题出现的原因也是多方面的:首先是客户方面；其次是由于软件开发方缺乏需求方的专业知识。XP编程方法从整体团体和开发小型的系统等方面解决了这些问题。
在极限编程中，强调“整体团队”的理念。一个XP项目的所有参与者都作为一个团队的一部分。这个队伍是围绕着一个和其他成员一起工作的业务代表(客户方面的代表)建立起来的。XP提出在开发团队中既要有全职的客户人员的参与，同时也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。
XP采用的是迭代开发，将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每一个周期都要经历提出需求、架构设计、编码、测试和发布的过程。这样每一个开发周期之后，就能开发出质量很高的、涵盖部分功能点的、让人放心的“小版本”。在以后的开发周期中，则陆续在以前的小版本上添加新的功能，提炼出新的版本。每一次交给客户一个包含部分功能的小版本，这样可以不断地从客户方面得到反馈，获得更加确切的软件需求。在不断的迭代中，避免因架构设计的重大失误而造成的软件不能如期交工，避免了软件设计的风险。
（2）难以确定项目计划
目前，软件开发过程中的两个主要问题是:确定在每个时间段内应完成哪些任务，以及确定下一步应该做些什么，重点是把握项目开发路线。但是，这些问题实现起来是相当困难的。
针对这种情况，XP使用了发布计划的方法。并在以后的开发过程中，XP团队会经常地修改计划，并且细化（相对于前一阶段的发布计划来说）这一时期要完成的任务，并在每一个迭代结束时提供可以运行的有实际用途的软件系统。然后由客户演示下一个时期要完成的任务，如此迭代可实现软件开发。这种开发方法，使得开发人员和客户都能对前一阶段的开发成果进行评估和反馈，更好地把握后面工期的任务安排。同时，多个迭代周期也使工期的估计越来越精确。
（3）缺乏沟通和反馈
在软件项目开发中，经常会出现项目中的一些重要信息没有进行充分和有效沟通的现象。在制定计划、意见反馈、情况通报、技术问题或成果等方面由于与相关人员的沟通不足，而造成各做各事、重复劳动，甚至造成不必要的损失。
为了更好地完成项目、明确需求和完善版本，项目开发团体应该尽早从客户、开发团队内部和实际最终用户获得尽量多的具体反馈意见来调整需求和开发计划。反馈可以让项目开发团队获得新的思路和修改的建议，从而把握正确的方向，少走弯路。XP强调有效的沟通和及时地反馈，可以防止重复劳动，帮助程序员之间的相互学习和获得新的思路。XP方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。沟通和反馈是项目开发成功的重要因素。
（4）分工和地位的不合理
在传统的重型软件开发方法中，我们的基本假设是对人的不信任。从管理学的角度看来，项目经理在控制项目时，对其他开发人员的不信任会产生很多问题，创新能力低下比如士气不高、计划难以按时完成、跳槽率升高等等。
XP方法的出发点是相互信任，给开发人员提供他们所需的环境和支持，并且信任他们能够很好地完成工作。一旦做到了这一点，就能够充分地调动程序员的积极性，提高他们的创新能力，将使这个团队具有很强的竞争力。
另外，在分工上XP强调角色轮换，项目的集体负责和分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特点。角色轮换就是在项目中，一个人在不同的周期担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，而要对整个项目的完成负责，任何人都可以对工作的任何部分。
可以看出，极限编程是一种以简单性、交流、反馈和以人为本为基本宗旨的开发纪律。它的做法是以有效的实践规则将整个团队紧密联系起来，通过允分的反馈使团队能随时知道自己目前的状况和恰当地调节实践规则以适应自己的特殊情况。这对于现在软件开发过程中的一些问题有一定的借鉴作用。
5.结束语
在软件工程出现以前，软件开发活动是混乱的，其中充斥这短期、即时的决定，而无完整的规划，当系统变得越来越庞大时，这种方法指导下的软件开发陷入危机;传统的软件工程方法借鉴了其它工程领域的实践，对开发过程进行严格而详尽的规定，以期使软件开发活动更有预见性并提高开发的质量和效率。然而对这种方法最多的批评是它们的官僚繁琐，如果按照它们的要求，就有太多的事情需要做，而延缓整个开发进程，同时它们又缺乏对开发过程中各种变化的有效的及时的反应，显得难以适应当前快速发展变化的社会对软件开发的要求，它们通常被认为是“繁琐滞重型”方法;作为对这些方法的反叛，在过去几年中出现了一类新方法—敏捷型软件开发方法，它们在无过程和过于繁琐的过程之间力求达成一种平衡，体现了软件工程方法从无到繁重再到敏捷的螺旋式的发展。其中，XP是近几年来敏捷型方法中发展的最好的一种方法，在国外已经引起软件开发团体的广泛关注，并在实践中获得软件开发人员和客户的欢迎。
6.参考文献：
【1】Robert C Martin著，邓辉译.敏捷软件开发一原则、模式与实现.北京:清华大学出版社，2003
【2】Highsmith J, Cockburn A .Agile software development：the business of innovation[J]. Computer, 2001，34(9):120-121.
【3】 Williams L, Upchurch R. Extreme programming for software engineering education [EB/OL]. https://fie.engmg.pitt.edu/fie2001/papers/1106.pdf.
【4】James Newkirk,Robert C Martin著.王钧译.极限编程实践[M].北京:人民邮电出版社，2002
【5】朱斌.极限编程概述【M】.北京:机械工业出版社.2002.48- 67
【6】张海藩著.软件工程导论(第三版)【M】.北京:清华人学出版社，1998
