极限编程范文（精选8篇）
极限编程 第1篇
在传统的开发过程中,往往是一个人从一个模块的需求调研开始,然后作分析、设计、编码、单元测试,接着才会交给第二个人(专职测试人员)进行其他测试项目。这样的开发过程会因为开发人员的变动而对项目的进展产生较大的影响,所以在软件工程的一些实践中就有项目中编码人员的重要性远比项目经理大的认识,为了改变这种状态,软件工程的研究人员进行了大量的工作,其中有人提出了极限编程的12个核心实践。在极限编程中关于团队组织模型的一个核心实践就是结对编程方式,但是对于开发人员人手严重不足的项目中,很多软件企业是不认可这种组织方式的,他们认为这会浪费很多的人力,一加一不能大于二。
结对编程是极限编程12个核心实践之一[1,2,3]。在结对编程中,要求两个程序员使用一台显示器,一套键盘鼠标来完成所有分配给他们的任务。结对编程的支持者声明结对编程的开发方式与传统的编程方式相比有很强的优势,这包括更高的团队开发效率和更高的软件开发质量。在XP的宣传中提到,两个人结对在一段时间以后可以使得开发效率超过单人编程,同时质量也会得到提高[6,7]。同样,在2006年敏捷中国开发者大会上,著名软件工程大师Martin Fowler作为首席科学家的公司ThoughtWorks的总经理Sid Pinney先生也提到了这个问题,他作出如下解释:当两个人结对时间超过三个月以后,效率会超过两个人单独编程的效率!这里,三个月这个时间不是真实确凿的时间分界线,它只是一个模糊的大概的时间范畴,如果两个技术人员配合得好,也许只需要两个多月,如果配合不好,也许需要四五个月,或者更长的时间……。
但是,在本文的实践过程中发现,几乎没有软件企业因为XP这样的宣传而采用结对编程的方式进行软件开发。除了ThoughtWorks,Google等少数公司外,几乎所有的公司都仍然采用传统的单人编程的方式进行软件开发。
在所能查阅到的所有关于结对编程优劣势分析和数据采集的文献资料共计173篇,其中以结对编程为主要研究目标的有71篇论文,在这些论文中提到的试验研究的对象大部分是在校学生[8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28]。只有不到十分之一的论文是关于专业程序员进行结对编程的实验[6,30,31],而这部分关于专业程序员实践结对编程的论文也并没有讨论结对编程开发效率是否真的能够达到两个同等水平的专业程序员单人编程的开发效率。几乎所有的论文的对比数据基础都是基于结对编程的两人组和单人编程的一人组之间进行的,这样的数据无疑并不能让软件企业信服这种开发方法所具有的优势。
同时还查阅到一些论文在实践的基础上提出了相反的观点,如Hanna Hulkko&Pekka Abrahamsson的研究就认为结对编程在与单人编程对比的时候并不能始终保持高效率和高质量。他们在文中写道:”They indicate that pair Programming may not necessarily provide as extensive quality benefits as suggested in literature,and on the other hand,does not result in consistently superior productivity when compared to Solo Programming”[31].
基于这样的实践和研究,本文认为,在与结对编程和单人编程的对比上,交换编程具有其特殊的优势。
1 相关工作
由于交换编程属于全新的概念,交换编程也属于结对编程与单人编程结合的产物,所以这里主要用它与结对编程进行对比,所能够查阅到的所有文献都是关于结对编程的。
北卡罗琳娜州立大学的几个研究人员从2002到2005年间[26]进行了一系列的试验并发表了多篇结对编程论文[11,13,16,18,19,20,21,24,26,28]。在他们的试验中全部采用的都是在校大学生,有1350名从大一到大四的学生参与了这一系列试验。他们分别从课堂教学和学校软件实践方面进行了关于性别差异、团队构建、布鲁克斯法则、个性特点,学习类型,技能水平,对个体编程的认同度,工作道德规范,或者时间管理偏爱等基于教学考虑的方面进行了结对编程试验,并得到了一些结对编程的支持性数据和观点。
University of Sannio的Gerardo Canfora,Aniello Cimitile,Corrado Aaron Visaggio等人对学习了一些编程课程的学生进行了结对试验,验证了个体经验和技能对结对编程过程中知识构建的益处[14]。
Matthias M.M¨uller和Frank Padberg进行了一系列的结对编程试验,他们在一篇论文[7]中认为,通过使用了一系列的度量方法来理解、模型化分析、评估结对编程在软件开发中的效果。在增加了人工成本的基础上,结对编程相对于传统开发过程更侧重于提高团队产量和代码质量。
Frank Padberg和Matthias M.M¨uller的另一篇论文[15]中得到了这样的试验结论:结对编程的效率提高比例与结对编程的个人的程序开发经验无关,而是和结对编程过程中的个人感觉有关。他们认为结对编程过程中结对程序员感觉越愉快他们的开发效率提高得就越多,这篇文章也从同样的角度验证了北卡罗琳娜州立大学2006年发表的关于Examining the Compatibility of Student Pair Programmers[26]文中提到的“个性特点,学习类型,技能水平,对个体编程的认同度,工作道德规范,或者时间管理偏爱”的结对观点,认为如果不考虑这些因素,结对的效果就无法体现出来。
但是,Hanna Hulkko和Pekka Abrahamsson的一篇论文[31]的试验中引入了企业中有经验的软件开发人员。在这个试验中,他们认为:“回顾这些可以看到绝大多数这方面的实验研究都是在大学环境中进行的。几乎没有在真实软件开发项目中详细审查下的结对编程被已存在的系统化实验研究过。因此,假设目前仍然没有纯粹的经验验证这种优势的存在。”据此和他们的试验结果,文中提出了针对结对编程的反面观点:“我们的经验发现表明:提供了与结对编程所声明的优势对比的结果。他们显示出:结对编程也许不像相关文献中建议的扩展的质量好处一样的必要,并且另一方面,当与单独编程进行比较的时候,这些结果并不能证明结对编程可以一直保持较高的生产率。”
2 方法定义
与结对编程类似,交换编程也是一个非常简单和直观的概念:两位或者多位程序员轮流开发同一个软件系统的同一个模块的不同阶段的任务。
交换编程的方式更合适的说法应该是交换开发,这种方式不仅仅可以应用于软件项目,也适合其他研究开发型项目。相对而言,这更是一种更容易被人们接受的方法,在前文大家已经看到了它在实际项目中的事实,这里先分析一下它与结对编程的不同之处:
它仍然采用传统的一人一机的开发方式,如图2;结对编程是两人一机,如图3。
它在每个迭代间进行多人交换或者两两交换,结对编程没有交换的概念。
它与传统的编程方式之间的差别是在每个迭代间进行多人交换或者两两交换,而传统编程没有交换的概念。
这里说明一下两个概念:
轮流交换:三个以上的程序员之间相互交换所开发的工件,不仅限于三个。例如:A1的开发内容交给A2做下一阶段开发,A2的交给A3做下一阶段开发,……,An的交给A1做下一阶段开发。这种方式称为轮流。如图4、图5、图6。
两两交换:两个程序员之间相互交换所开发的工件。仅限于两人之间,如图7和图8。
交换编程中的操作与其他过程有较大的差异,根据经验,建议在软件工程实施的各个阶段按照如下的方式进行:
(1)需求工程中,需求调研和需求分析进行轮流交换;
(2)概要设计(分析模型)开发中,需求分析到概要设计进行轮流交换;
(3)详细设计(设计模型)开发中,概要设计到详细设计进行轮流交换;
(4)编码实施启动后,详细设计到编码的交换采用两两交换。
在全程建模的开发方法下的交换编程应用方式如下图:
在编码以前全部采用轮流交换的目的就是为了让更多的人了解项目进展的全部内容,有利于增加团队内的交流,使更多的人对项目所开发的内容熟悉,并能让他们提出自己的观点,也有利于使更多的人从更多的角度来研究某个系统模块所需要实现的功能和用户需要解决的实际问题,不会因为某个人的定式思维而出现理解偏差,从而造成对需求的理解不到位。
详细设计到编码的交换采用两两交换,这是因为前期需求已经基本上都稳定下来了,这时候不需要对用户需求进行更多方面的理解,只需要进行实施并进行纯粹的编码工作即可。此时做轮流交换已经不存在任何意义,相反只能影响开发进度。
3 优劣分析
关于结对编程,很多公司对其也有一些常见顾虑,如图10,图11,图12所示:
表1中表述了传统的单人编程,交换编程,结对编程以及交换编程和结对编程配合使用四种人员组织形式下在常见的软件开发相关问题上应用适用性以及表现出来的特点。
表1的十四项内容分别从团队稳定性,技术水平,开发周期,团队人员等四个方面对这四种团队内人员组成方式进行了分析。从上面可以看到交换编程对几乎所有的这些项目都有其明显的优势,总体上看,交换编程无论在管理层面还是在团队组织层面或者是在项目变化上都优于单人编程和结对编程。
4 试验结果
2002年4月在上海进行的一个ERP项目中实际采用了结对编程的方式来进行部分模块的开发。两个各自独立完成了一个模块开发的程序员携手进行第三个模块开发时采用了结对编程的方式。两个人只用了四天时间,就完成了这个新的模块(其模块难度与前面完成的模块开发难度相同)的全部功能,并且这个模块开发完成后几乎是一次性通过了全部测试。相对于此前做的功能模块来说,时间仅有其他模块开发时间的十分之一。
但由于结对编程会让人感觉到资源被浪费了一半,在2002年10月开始的一个中国电信MSS项目中,项目组提出进行结对编程的时候被管理层拒绝。那如何才能借鉴结对编程的优势,并能降低这种表面的浪费,而又能让大家交流起来,同时能提高团队的稳定性呢?
4.1 项目基本情况
这是电信MSS项目的核心业务系统部分,包括了规划、可研、设计、施工、试运行、验收、财务、合同等多个重要环节和多个部门的业务。这个项目在最初评估的开发周期就是第一个版本在五个月内完成,整个项目至少要做上一年以上,而最后的实际情况是,这个项目随着不断的升级和调整一直开发了三年多。
可以对比的数据是:2003初到2004年10月间SAP基于自有的ERP系统给中国电信提供了完成同样功能的一套产品来替代这个团队所开发的这个产品,SAP也向中国电信承诺了要针对中国电信的行业企业特点进行定制开发,但是在2004年底推广应用前被宣布试验失败,延期推广。这个对比数据主要是为了证明这个业务系统的复杂度和规模都是相当巨大的,但是,在国外企业实施失败的情况下,国内一个小团队的开发却完成了南方电信11个省公司版本和电信集团公司版本的全部开发,2年内没有发生开发人员辞职的事情,由此可见,交换编程的开发方式带来的团队开发效率和稳定性都是比较好的。
4.2 团队组成情况
当时团队开发人员数量为11个,人员技能较为均衡,没有经验和开发水平远远超出其他人的技术人员。最初的开发团队是十一个人,后来扩展到二十三个人,其中三个有五年以上开发经验,两个三年开发经验,另外的六个人技术水平相对较低只有一年多的实际项目开发经验。对于团队人数少于20人的开发团队,企业一般不会允许采用结对编程的方式进行开发,因为这类项目大部分都存在时间紧,任务量大,承接项目的公司规模较小等特点。当然,对于类似微软,Google,ThoughtWorks,AutoDesk等对资源占用不敏感的产品开发公司中超过4人的团队就可以考虑进行结对编程。。
4.3 项目实施过程
由于开发团队中没有经验和开发水平远远超出其他人的技术人员存在,因此技术方案的论证过程都是在全体组员的共同讨论中制定下来的。因此在权衡了整个项目的实际情况后,团队经过讨论后决定在完成需求工作后,第二阶段设计模型的开发所有开发人员轮流交换来做。
在设计模型开发完成后,开发人员再次进行了轮流交换。两次交换完成后,保证了每一个模块都有至少两个人对其十分熟悉,一方面不会因为人员的变动造成团队的不稳定,另一方面保证每一个模块的开发人员都能找到人进行讨论,从而增加了团队内的沟通,方便了协调工作的进行。
因此在那个团队的开发过程中,经常是大呼小叫,无论走到哪里,都是十分热闹的场景。在Larry L.Constantine’s The Peopleware Papers[4]一书中的第十二章的“工作和游戏”一节中也有着类似的描述。Larry L.Constantine认为这是创造性团队应该具有的表现形式,这也符合Brooks[5]的胶冻团队的一个特征。
由于当时没有进行实际数据的度量对比,本文也无法从量化的数据上来说明问题,只能通过一些具体的事实来进行说明和验证:当时这个团队在七个月内满足了南方11家省级电信公司和中国电信集团公司的基本业务需求。从2003年4月到2003年12月期间,基本完成了该系统在这些省公司和集团公司等12个相对独立版本的二次定制开发任务。
5 总结
综上所述,交换编程的应用方式是有其适用环境的,并且具有较为明显的优势。交换编程的适应性较强,这里分为团队状况和项目情况两个部分进行说明:
团队状况:交换编程适用于人数超过两个人的开发团队,因为交换一次至少也需要两个开发人员。人数较多的团队也可以应用交换编程的方式,来进行项目开发。要求团队内有一两个具有两三年以上开发经验的成员,这是对于软件项目的最基本要求。
项目情况:项目规模不限,开发周期的适应性也较强,对于任何类型的项目都可以适用。
摘要：结对编程是一种编程组队方法,在这种方法中要求两个程序员使用一台电脑在一起工作完成同一个任务。在软件开发中关于结对编程的价值正在进行着争论。目前在这个领域大量的知识都是离散的和无条理的。回顾这些可以看到绝大多数这方面的实验研究都是在大学环境中进行的。几乎没有在真实软件开发项目中详细审查下的结对编程被已存在的系统化实验研究过。因此,假设目前仍然没有纯粹的经验验证这种优势的存在。由于结对编程在表象上给人以浪费一个开发人员的感觉,所以,在很多软件企业中,很难得到推广实施。在本文的报告中,我们给出了一种有别于结对编程和传统的单人编程的团队组织形式,这种形式融合了结对编程促进团队内相互交流的好处,保持了团队的稳定性,同时采用了传统单人编程的形式,不给人以浪费人力的感觉。
极限编程 第2篇
每周只工作40小时：充分利用你的时间，一个星期工作40小时已经足够了，
终于说到很多人最热衷的话题上了，加班的话题是永恒的，其实我觉得是否加班并不是主要问题，重要的是这个加班是不是自愿的。
曾经，为了能够保证项目投标的成功，连续三天两夜的安装、调试系统、完善、装订投标书，反复的对投标时的演讲进行模拟练习，整个团队的人虽然整夜的不眠，靠着咖啡、香烟和快餐来争分夺秒，那个时候身体虽然疲惫，甚至因为长时间在机房受到噪音辐射而呕吐，可是心里却是激动地，为了期望中的成功。也曾经，为了不影响客户白天正常的使用系统，彻夜加班修改白天收集的问题，团队中的成员互相讲笑话来驱逐睡意……。所有的这些辛苦，每每回忆起来总是感到很沸腾。那时候，加班是为了一个明确的目标。
然而，当加班成为一种常态、一种惯例、甚至一种文化时，所有的一切都变了，有事没事都加班，不加班就意味着工作量不饱满，加班时间甚至成为考核的参考指标。同样一件事情，追求高效的人提前完成了反倒被看作是工作量不饱满，再给加上新的工作，于是，人们的心态发生了变化，使得大家不再追求效率，只是想办法让自己看上去忙忙碌碌，
最终的结果就是加班不但没有保证工作的按时完成，反正成了降低效率的诱因。
或许，正是看到了这个原因，敏捷开发中提出了每周只工作40小时的原则，这一原则的提出自然引起了大家的关注，吸引大家进一步的去了解敏捷开发的理论体系。可以肯定地说，敏捷开发的创始人并不是说每周工作40小时之后就呼呼大睡了，关键的话在这里：“充分利用你的时间”。
回头来看看配对编程大家就会感受到，其实敏捷开发体系中对时间的要求更加严格，在那种机制下，每个人的8个小时是没有时间干私事的，每周40个小时是真正忙碌和充实的。反观一下我们目前的工作，扪心自问，谁能做到这一点?
随着对十二大原则的不断解读，越是感觉到敏捷开发、极限编程理念中对时间管理的要求，对人员素质的要求，甚至其他各个方面并不是像很多刚刚接触到的人说的那样“宽松”，相反，是要严格的多!所有的原则仿佛都是在为了一个目的：高效。
极限编程及其应用 第3篇
传统软件工程中的软件开发过程要求在开发初期确定用户的完整需求, 但在具体开发实践中, 人们发现早期定义的需求往往不能完全符合客户的实际需要, 这种开发方法在当代这种需求不确定性大, 且开发时间短的开发实践中显得越来越无力, 开发者根据用户提出的需求不断修改程序, 不但延长了软件开发周期, 还大大提升了软件的开发成本和风险, 很多企业的软件开发团队陷入了开发过程不断增长的泥潭。为了解决这个问题, 业内专家们一起总结出一些能让软件开发过程具有高效且能迅速响应需求变化等特点的价值观和原则, 这就是敏捷开发思想。极限编程 (Extreme Programming, XP) 是敏捷开发方法的代表, 它是一种混乱而又有序的开发实践方法, 利用较短的迭代周期来响应需求的变化。
1 极限编程
1.1 XP简介
极限编程方法是由Kent Beck提出的, 他从90年代开始一直寻找一种能使软件开发更加简洁有效的开发方法, 他在认真分析比较了各种简单、快捷的软件开发方法的前提、有效性及局限性后, 终于在1996年3月提出了极限编程开发方法并应用于项目中[1]。极限编程是一种极为严格的、经过实践考核的轻量级软件开发方法, 是敏捷软件开发方法中的典型代表。在极限编程开发过程的每个阶段都以代码为中心, 侧重于客户参与、精炼设计、频繁测试, 快速反馈、持续性的整合、重构等, 以便在开发过程中尽量早地发现错误并及时纠正。
1.2 XP价值观
1.2.1 强调个人与交互, 弱化过程与工具
软件开发团队是由人组成的, 软件是开发者的脑力劳动的结晶, 因此要进行高效地开发, 各开发人员及客户必须进行有效地沟通并工作在一起。
1.2.2 强调软件开发工作, 弱化详尽的文档
软件开发的终极目的是得到可运行的软件, 而不是文档;因此有些文档不必要花费大量的精力去制作, 规规矩矩的软件工程思想反而逼迫开发人员不得不加班加点。
1.2.3 强调与客户协作, 弱化合同谈判
软件的服务对象是客户, 只有客户满意的软件才是开发成功的软件, 因此开发人员应与客户紧密联系, 不断的引导客户表达并理解需求。
1.2.4 强调及时响应变化, 弱化遵循规则
随着软件开发工作的进行, 各相关人员对正在开发系统的理解都可能发生变化, 因为环境、时间都在变, 所以变化是软件开发中不可避免的事实, 软件过程必须反映这个事实。
1.3 XP标准过程
极限编程的标准过程分为两个阶段:设计和开发[2]。在第一个设计阶段中, 开发人员根据现场客户提供的用户事例明确软件的需求。以系统需求为基础, 使用系统隐喻规则说明系统如何实现、新的功能如何添加。在第二个开发阶段中, 采用周期迭代、测试驱动的开发模式, 首先编写测试脚本, 再使用结对编程方式完成编码, 最后进行测试。XP方法要求在开发过程中, 对系统持续集成, 反复的进行回归测试。XP标准过程如图1所示。
1.4 XP优势
XP思想是一种新兴的编程理念, 相对于传统的软件工程方法, 它具有以下的优势:
1.4.1 XP技术提出的小型发布能够及时的发现错误, 最大程度地缩小错误范围。
1.4.2 XP技术提倡迅速响应需求的变动问题, 尽可能减少因需求变动而带来的损失, 并且开发出的软件最大限度地满足用户需求。
1.4.3 XP技术倡导一周40小时的正常上班制度[3], 因为高强度的加班遏抑了软件开发者的创新能力和工作积极性, 从而给软件项目的开发进度或软件质量带来不利的影响。
1.4.4 XP技术提倡简单设计的开发理念, 可以减少开发者的工作量, 提升开发效率。传统软件工程学认为编码必须在设计完全结束后才能开始, 而实际上设计一般都存在着一些缺陷, 面面俱到的设计反而会造成开发进度的迟缓。因此XP技术为IT行业的软件开发创造了一种新的先进开发思想。
2 XP在考试管理系统中的应用
XP方法通过这几年的发展, 已经有很多小型的软件企业自觉或不自觉地采用这种编程技术, 但它一般适用于项目的分析和设计人员总数不超过10的中小型项目, 当软件项目较大, 参与人数较多时, 就不适宜采用XP开发方法[4]。因此, 本文以考试管理系统为例讨论XP模型在中小型系统中的应用。
2.1 项目概述
为了提高教师的工作效率及学生的学习兴趣, 开发一个考试管理系统, 通过对考试管理系统的功能分析, 要求系统具有以下功能:根据用户权限登录不同模块、管理员可以添加、修改和删除试题、管理员可以添加、修改和删除用户和考生、可以随机显示考题、能够自动阅卷、显示倒计时、可以查看成绩等。
2.2 项目开发过程中XP准则的实践情况
2.2.1 与用户充分沟通, 拟定开发计划
在开发中, 开发者首先同客户代表进行充分的沟通, 并站在用户的立场上思考明确系统的需求, 确定系统的功能模块划分。考试管理系统预计分为三个短周期, 每两周进行一次小型发布。第一个周期完成公共模块、系统登录模块、后台管理模块等三个模块;第二个周期完成系统管理、题库管理这两个模块;第三个周期完成考试模块、查看模块。每进行一次小型发布都要产生一个版本, 并同时提交给用户进行测试, 不断收集用户的反馈信息, 如操作方式、界面、格式支持等方面的修改意见, 以便在下个版本中及时纠正, 这样就可以避免开发出与用户需求不相符的系统。
2.2.2 结对编程
结对编程是XP方法中的一个重要规则, 它提倡两个人共用一台电脑, 共同完成同一功能模块的编码。在该项目中, 为促进知识在开发团队中的传播, 团队员工以一老一新原则进行搭配成对, 老员工负责控制计算机并研究编程细节, 编写输入代码, 新员工观察输入的代码并寻找代码中出现的错误和可以改进的地方, 以提高代码的质量和可读性。
2.2.3 团队共同拥有代码
在开发过程中, 开发者始终坚持XP中的“代码集体所有”原则, 它不仅是一种代码的共享, 更是一种知识的共享。所有成员的代码阅读权限一致, 不但拥有自己编写的代码, 也可以了解其他队员编写的代码。任何问题的解决都由团队全体成员共同讨论、修改。因此, 即使有团队成员离开也不会影响整个软件项目的开发进度。
2.2.4 持续集成、测试
软件开发过程中, 所有团队成员每天都把代码导入共享库, 每生成一个新版本都进行一次系统集成, 并由用户共同参与测试, 继续收集用户的反馈信息, 及时响应需求变更, 不断地进行回归测试, 以保证软件的可靠性。该项目经过6周的迭代研发后, 到最终版本发布时, 系统已经能在校园网上稳定地运行了。
本系统在开发过程中, 结合具体情况, 灵活应用XP提供的方法、原则, 找出适合本项目的软件开发模式, 充分注意了系统的安全性、实用性、灵活性。最终, 开发的系统中客户的需求均得以实现。
摘要：在传统的软件工程学中, 系统的分析、设计与实现在时间上先后分离, 这种分离常常导致开发的软件与预期不符甚至完全失败。因此, 敏捷软件开发方法应运而生, 极限编程就是敏捷方法中最著名的一种轻量级的、灵活的软件工程方法。
关键词：极限编程,XP,软件工程,软件开发
参考文献
[1]刘玲惠, 梁晓强.敏捷软件开发中的极限编程[J].产业与科技论坛, 2011, 10 (22) :77-78.
[2]易金刚.极限编程理论的研究[J].计算机时代, 2010, 06:01-03.
[3]傅恒切.传统软件开发与极限编程[J].中国外资, 2011, 05:286.
极限编程(XP)方法及其应用 第4篇
1 极限编程(XP)方法简介
极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。作为敏捷方法中最著名的一种方法,XP由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。它是一种轻量级的、灵活的方法。XP规定的核心价值和方法准则强调沟通和反馈,鼓励软件开发人员充分发挥他们的个人创造力。
XP方法的核心价值观为“交流”、“勇气”、“简单”和“反馈”[2]。XP方法要求的14项规则为:客户全程参与(On-Site Customer)、用户事例(User Stories)、短周期发布(Short Cycles)、结对编程(Pair Programming)、测试驱动开发(Test-Driven Development)、集体拥有代码(Collective Ownership)、持续集成(Continuous Integration)、平稳的工作效率(Sustainable Pace)、项目计划(The Planning Game)、简单设计(Simple Design)、重构(Refactoring)、隐喻(Metaphor)、编程规范(Code Standards)和开放的工作环境(Open Workspace)。
2 XP软件方法在某军用传感器综合信息处理软件项目开发中的应用
图1为军用传感器综合信息处理软件系统示意图。
2.1 项目概述
军用多传感器综合信息处理软件的系统示意图如图1所示,此系统要完成的主要任务包括:
1)对各传感器的原始数据信息进行处理,提炼出各传感器原始数据中包含的信息,并以适当的方式进行显示(各传感器到相应处理模块的传输方式相同)。
2)保存各传感器的原始数据(各传感器的存储介质相同)。
3)将必要的数据信息发送到传感器数据信息融合模块(各处理模块到传感器融合模块数据传输方式相同),由传感器信息融合模块对各传感器数据进行信息融合。
4)四级显示控制模块控制融合后传感器信息显示方式及传感器信息的融合方式。
5)二级显示控制模块提供对响应传感器的控制功能。
2.2 项目开发过程中XP准则的实践情况
在整个软件项目的开发过程中,我们力图严格按照XP的实践原则完成整个软件产品的开发。但是,由于客观情况的限制,在某些规则的执行上,我们还是根据实际情况作了一些修改。我们从2的14项规则中选取了12项规则,各项规则实践情况如下。
1)客户全程参与(On-Site Customer)
此软件项目的完成主体是由一个研究单位的若干协作部门来完成的,因而对于有些模块,研究单位本身既是开发者,同时又是用户;对于整个系统来说,客户就是最终使用此传感器综合信息处理系统的单位。按照文献[Ken Beck]的定义:XP团队的用户是决定系统各模块开发优先级(既重要程度)的人或者团体。在软件开发中我们将各软件模块的使用者定义为内部客户;将整个系统的使用者定义为系统客户。如图1所示,我们按照数据流的流向,将整个软件系统划分为四个级别。每一级别实际上都可以看作是其前一级软件模块的内部用户,因而2、3、4级的软件模块开发人员需要和1、2、3级软件模块开发人员编写User Story。
2)用户事例(User Stories)
准备好开发环境以后,由用户和开发者共同把需求分解为User Story,在分解User Story的过程中,重点分析每个User Story的商业优先级(对于内部用户来说,用开发优先级代替商业优先级),估计每个User Story的理想开发时间和开发风险。
3)短周期发布(Short Cycles)
由于我们将整个比较复杂的软件系统分为四个软件层次,因而我们也将软件的短周期发布分为内部软件模块发布和软件系统整体两种形式。对于内部软件模块,我们要求其发布周期为2天,对于整体软件系统,我们要求其发布周期为2周,这样做不至于因为准备整个软件系统发布的时间较长而耽误紧张的开发时间。
4)结对编程(Pair Programming)
采用结对编程的编程模式可以达到两个程序开发人员优势互补、互相激励以及提高代码质量的目的。在开发过程中,我们将结对编程的原则修改为,软件系统架构及全局功能由结对编程来完成,而大部分数据处理算法的关键代码仍然由个人来完成。
5)测试驱动开发(Test-Driven Development)
在本项目的开发过程中,采用的测试驱动的软件开发方式如图2所示。
6)集体拥有代码(Collective Ownership)
对于本项目来说,关键代码的测试代码公开。
7)持续集成(Continuous Integration)
在本项目的开发过程中,整个系统的持续集成是建立在各软件模块持续集成的基础上的,每个软件模块的开发小组在完成一个软件功能单元以后,马上将其集成到其已经完成的软件模块。然后,由客户(内部客户或者外部客户)对其进行验收,并及时向开发小组反馈。以一级软件模块和二级软件模块之间进行持续集成为例,其示意图如图3所示。
8)平稳的工作效率(Sustainable Pace)
虽然整个项目开发时间比较紧张,但是我们始终坚持工作效率第一的原则,除了最后一段时间的冲刺阶段,在整个开发过程中基本上没有晚上加班的现象。
9)简单设计(Simple Design)
在进行设计的时候,我们将传感器综合信息处理系统的所有软件模块分为软件框架部分(数据传输/显示等)和核心算法部分两类,采用简单设计的原则来进行。
10)重构(Refactoring)
在开发过程中简单设计中的不足之处需要通过重构来解决。我们有的开发小组甚至专门拿出一个迭代周期进行代码重构。
11)隐喻(Metaphor)
在本项目的开发过程中,程序开发人员大都是相近专业,因此他们在软件开发过程中,所使用的话语都是“行话”,因此我们选择“原始的行话”作为“系统隐喻”。
12)编程规范(Code Standards)
本项目全部采用C/C++来实现,图形显示部分都是在Windows平台采用Visual C++6.0 MFC类库实现(C++),数据处理软件模块在VxWorks平台(C语言)和Windows平台(C++)都有,数据通信和控制命令的通信主要是以太网和串口。
3 总结
软件开发的“敏捷”思想及XP方法为解决软件开发过程中存在的诸多问题提供了一种非常实用的方法。但是,在软件开发中采用“敏捷”思想以及XP方法对于项目管理者和项目开发人员却是一种挑战。XP的四项基本理念即交流、反馈、勇气、简单看似简单,但在实际实行的过程中就会发现,无论是程序开发人员、项目管理人员、客户和设计人员要达到这四项基本理念的要求都需要经过较长时间的锻炼。这从我们开发的迭代速度就能看出来,第一个迭代周期中我们的程序员完成的工作量只有第三次迭代周期中他们完成工作量的一半。在本软件项目的开发过程中,项目开发人员受益最大的就是采用测试驱动开发的策略、撰写User Story和遵循简单设计的原则。“敏捷”只提供了软件开发的方法论,XP也只提供了软件开发过程中可能会带来收益的一些原则,更重要的是要结合实际情况在实践中不断的实践这些方法和原则,并找出适合自己项目的软件开发模式。
参考文献
[1]Highsmith J,Cockburn A.Agile software development:the business of innovation[J].Computer,2001,34(9):120-121.
[2]Beck K.Extreme Programming Explained:Embrace Change[M].Addison-Wesley,2000.
[3]Cockbum,Alistair.Agile Software Development[M].Boston:Addison-Wesley,2002.
[4]Wood W A,Kleb W L.Exploring XP for Scientific Research[J].IEEE Software,2003(5):31-36.
极限编程 第5篇
当今时代,国内有很多中小型软件项目开发时间紧迫,需求也经常发生变化,如果使用传统的软件开发方法,会导致开发资源浪费,甚至质量低下。敏捷开发方法为有效解决这种状况提供了良好的解决方案。其中,以极限编程XP(eX-treme Programming)最为典型代表。XP是一个基于实践的、混乱而有序的方法,它通过非常短的迭代周期来应对需求的变化。
笔者正在做一个Android手机情景模式自动切换的软件开发创新训练计划项目,虽然不敢与国内的那些中小型软件项目相比,但是,自己也主动尝试使用敏捷开发方法。虽有不到与不周之处,但也小有收获。
2 极限编程
在所有敏捷开发方法中,XP(eXtreme Programming)是最引人注目的,它适用于需求快速变动背景下的中小规模的开发团队。
XP所呈现的生命周期如图1所示。
2.1 极限编程的4个核心准则
(1)沟通:注意开发人员、设计人员、测试人员及客户之间的沟通。
(2)简单:尽量保持代码的简单,只要它能工作就可以。
(3)反馈:尽快获得用户的反馈意见,且越详细越好,使开发人员能够保证自己的成果符合用户的需要。
(4)勇气:最重要的核心价值。因为XP强调要“拥抱变化”,因此对于用户的反馈,要勇于对自己的代码进行修改,丢掉坏的代码。
2.2 极限编程的5个基本原则
(1)快速反馈:XP提倡尽可能早的迅速的反馈。
(2)假设简单性:XP倡导为完成今天的工作而工作,并不计划未来对软件的扩展。
(3)提倡更改:XP强调要“拥抱变化”,有快速的反馈,就应有对反馈结果的执行措施。
(4)递增更改:XP提倡小改动,用期望的功能逐步增强系统。递增更改应用在XP的诸多方面:设计、计划、团队等每次只改动一小点。
(5)优质工作:质量是最重要的。XP强调团队中的成员要对工作充满兴趣和信心,保持编程人员的最高热情和水平。
2.3 XP主要特点
最为一种轻量级方法论,XP明确放弃了系统建档和分析以外的任何外在活动。文档明确不予鼓励,编码才是最主要的活动。
基于测试驱动开发(Test-Driven Development,TDD)的思想,在编码开始之前将测试用例或者脚本设计好。
3 极限编程开发应用
3.1 发布计划
3.1.1 项目简介
开发一个软件,可以通过手机自带话筒收集手机周围的声音信息,通过软件对采集信息的分析和标示,选择默认设置或者用户预先设置里面对应的情景模式,进行模式的自动匹配选择和切换。本项目首先面向的对象是学生Android手机用户。
3.1.2 项目模块划分
XP是明确不支持文档的,只要设计出系统架构,各模块不必详细设计,在测试驱动的开发中进行完善。本项目模块划分如表1所示。
3.2 开发
开发过程中主要分为以下过程:
3.2.1 模块基本功能实现
在该阶段,团队队员进行分工,独立编写模块。由队长搭建模块架构,确定模块之间相互传递数据时的数据结构定义以及各模块函数命名等。规定各模块输入值和预期输出值。
3.2.2 模块整合
按照主函数的结构安排,插入各模块的功能函数调用部分。对变量、结构体等进行初步检查,防止同名变量的影响。
3.2.3 测试驱动
可以全部团队的人员(团队人数在3-4人时)加入测试设计和代码修改的过程中,避免忽略细节,同时也可以避免沟通不畅带来的不必要的麻烦。
对于不同的环境输入,进行运行过程和结果测试。
测试的典型环境选取、环境特点和测试内容表示如表2所示。
使用语句覆盖测试、分支覆盖测试、条件覆盖测试、谓词覆盖测试、路径覆盖测试、边界值测试、特殊值测试等单元测试方法,对代码进行测试和修改。消除代码错误,完善代码实现功能。
3.3 应用经验
(1)个人创新:为实现新技术的突破,解决遭遇到的许多新挑战、新困难,团队中的每一个人都需要创新意识。
(2)统一与一致:只有和所在团队规定的格式一致时,才能方便地对其他人的代码的理解。
(3)减少文档:对于小规模团队而言,直接的交流和沟通才是最有效的。
(4)民主和荣辱与共。
参考文献
[1]朱少民,左智.软件过程管理[M].清华大学出版社,2007.4.
[2]易金刚.极限编程理论的研究[J].计算机时代,2010,6.
[3]B.Kent.Test-Driven Development:By Example[M].Pearson Education,Inc,2003.
[4]F.Michael.Working Effectively with Legancy Code[M].Prentice Hall,Inc.,2004,10.
极限编程优势与局限性探讨 第6篇
关键词：极限编程,敏捷开发
由Kent Beck提出的Extreme Programming (XP) 规定了一组核心的价值观和方法, 它消除了重量型软件过程的不必要产物, 从而减轻了开发人员的负担。极限编程是一种轻量、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式。极限编程承诺降低项目风险, 改善对业务变化的反应能力, 在系统的整个生命周期内提高生产力。在很大程度上解决了传统软件开发面临的问题。
1 传统软件开发面临的问题
自从在软件行业引入工程的概念后, 软件工程的研究成为软件行业的重要内容。传统的软件工程方法强调详细的规划和设计, 使用大量的文档资料来保证软件产品的质量, 在很大程度上解决了“软件危机”中出现的问题。但随着软件行业的不断发展, 越来越多采用传统软件开发方法的项目依然存在各种不同问题, 集中表现在以下三个方面:
1.1 无法应对需求的不断变化
在软件工程中, 需求分析是软件开发的首要环节, 也是软件开发的一个重要阶段, 它直接决定着下一阶段的项目设计和规划的质量, 可以说是决定整个项目成败的关键。但在实践中, 由于需求分析人员经验、技能和水平的差异, 以及客户自身知识和水平的限制, 常常无法准确把握客户所有的需求。随着开发过程的进行, 客户软件知识逐步增加, 软件部署环境也会不断发生变化, 客户会不断提出新的需求, 满足客户新的需求会导致项目整体规划和设计的变化, 造成已有人员、资金、时间等资源的浪费, 影响项目正常进度的实施。另外传统开发方法多数采用一次性详细规划和设计, 在开发中后期修改较为困难, 严重时会导致整个项目从头再来。因此, 传统开发方法难以应对客户不断变化的需求。
1.2 软件产品质量低下
虽然在传统软件开发过程中有严格的单元测试、集成测试、系统测试等多个测试环节, 但随着系统规模的不断扩大, 系统的复杂性不断增加, 各个测试环节并不能发现全部的问题。加上软件部署环境下的硬件、软件、网络等多方面因素的影响, 软件产品在交付后总会出现这样那样的问题, 造成客户对项目的满意度降低。出现这种现象的根本原因在于项目开发机制和开发方法的影响。
1.3 项目风险较大
传统软件开发多采用结构化模块式设计, 由项目经理将各功能模块分发给不同人员实现, 然后再进行集成。这就造成系统某个功能模块由某个项目组成员实际控制, 其他人都不熟悉。这样如果负责系统关键模块的人员流失, 就会给项目开发带来很大的风险, 影响项目的进度和产品质量。另一方面, 项目组为了满足客户不断提出的部分新需求, 被迫修改项目规划和设计, 造成项目资源的浪费, 常常会造成项目经费不足、项目进度无法实现等问题, 无法如约履行与客户的合同。即使为如期交付软件系统而赶进度完成了项目, 也会降低产品的质量, 从而给项目带来极大的风险。
2 极限编程的优势
极限编程作为一种新型的敏捷开发方法, 以产品质量为核心, 综合采用了软件开发中的各种实践手段和方法, 可以很好地解决上述传统软件开发方法所遇到的问题。
2.1 适应快速变化的项目需求
极限编程采用逐步规划, 进化式设计的方式进行项目规划设计。项目组首先根据已知因素制定整体计划, 然后根据项目环境和客户需求变化不断修改规划。进化式设计只考虑当前有用的功能和设计, 不考虑将来可能的需求, 而将可能需求放在必要时予以实现, 从而使设计较好的适应最新项目进展, 最大限度满足客户需求。这样可以提高软件产品质量和客户满意度, 并能避免可能的开发资源浪费。
极限编程采取现场客户的工作方式, 即客户在项目开发全过程和项目组一起现场工作, 随时和项目组成员交流, 对项目进行即时有效的反馈。这种现场客户的工作方式, 可以让项目组及时发现项目目标与客户需求之间的差距, 及时征求客户意见, 得到客户反馈, 尽早发现问题解决问题, 从而避免项目返工和修改造成的资金、时间等资源的浪费。
2.2 保证较高的产品质量
质量是极限编程的核心, 为了保证软件产品的质量, 极限编程采用测试先行、持续集成等措施, 并在设计中采用简单性原则。测试先行是在编写程序代码之前编写测试代码。传统开发方法中测试代码通常在程序代码后编写, 这样测试代码会受程序员个人先入为主的影响。测试先行的方法避免了程序员先入为主的主观影响, 使测试更客观更全面。持续集成是项目开发过程中系统各模块在开发过程经常性进行集成, 通常每天进行一次或多次集成。持续集成可以及早发现集成中出现的问题, 将问题解决在萌芽阶段, 这样就避免了常见的大规模集成中出现大量问题的现象, 防止在后期项目集成时风险过高。简单性原则即在项目规划、设计和实现时尽可能保持简单。在满足客户需求的前提下的简单可以保证系统的可靠性。从系统工程的角度而言越简单的系统可靠性越高, 越复杂的系统则越脆弱。极限编程中的简单性原则, 不但可以保证系统的可靠性, 而且还可以避免不必要的功能的开发, 节约项目资源, 保证项目实施进度。测试先行、持续集成、简单性原则等措施和极限编程的其他措施一起保证了软件产品的较高质量。
2.3 降低项目风险
传统项目开发中常常存在人员流失和预定进度无法实现等风险。极限编程采用代码集体拥有和频繁发布的开发机制。代码集体拥有即项目组所有成员都可以对系统代码的任何部分进行修改。这样系统代码由项目组集体拥有, 避免了部分代码由某个人单独控制的现象, 即使部分项目组成员流失, 也不会对项目开发造成重大影响。频繁发布是项目组经常进行功能性的发布, 向客户展示项目组的阶段性成果, 一方面有利于确认客户需求, 避免开发中走弯路;另一方面有利于进一步的规划和设计, 可以不断精确控制项目时间进度, 按指定日期完成项目。频繁发布还有利于提高项目组成员的成就感和开发信心。
3 极限编程的局限
极限编程作为一种优秀的敏捷开发方法, 有其不可替代的优势, 但同时因其独特的开发机制和措施, 极限编程也有其自身局限性, 主要有以下几个方面。
3.1 团队规模有限
极限编程不特别依赖正式文档, 重视口头交流。因为口头交流相对文档交流更直接、效率更高。但如果团体规模过大, 团队成员之间全面的相互口头交流将会变得比较困难。同时极限编程实现代码集体拥有, 项目组成员可以任意修改所有代码, 如果项目组成员过多, 这种修改将会变得难以预料、无法控制, 因此团队规模必须得到控制。在实践中采用极限编程进行开发的团队规模通常在10人以下。
3.2 文化认同有一定难度
极限编程采用结对编程的工作方法。结对编程即两个人在一台电脑前协同工作, 一起进行项目设计、测试和开发。这对部分个性鲜明的程序人员来说可能是无法接受的, 同时项目领导也可能会对两个人共同工作的效率和效果不信任。极限编程为了保持项目组成员的工作热情和工作效率, 提倡每周工作40小时, 这一点对于一些急欲完成项目的项目领导来说是无法接受的。因此要实施极限开发的项目必须要求项目团队领导和团队成员认同和接受极限编程的文化。
3.3 对项目组成员要求较高
实施传统开发方法的项目组通常分工较细, 项目组成员分别负责设计、开发、测试等不同工作。但实施极限编程的项目组成员要完成设计、测试和开发等多种工作。因此要求项目组成员具有较强的综合素质和多方面的工作能力。这一点对于项目团队的组建具有较高的难度。
4 极限编程的适用范围
极限编程以其优秀的特性受到了众多程序人员和项目组的青睐。根据极限编程的特性及其应用情况, 极限编程在以下情况下应用较为合适。
4.1 需求变化大的项目
极限编程可以适应快速变化的项目需求, 因此在需求变化较大或需求不够明确的项目中适宜采用极限编程开发方法。
4.2 开发风险高的项目
极限编程采用代码集体拥有、频繁发布等措施, 在降低项目开发风险方面具有较好的效果。如果项目开发风险较高, 采用极限编程开发方法可以极大限度地降低项目的开发风险, 保障项目的顺利完成。
4.3 人员精干的团队
极限编程 第7篇
随着网络技术的发展,计算机和互联网广泛地进入学校和普通家庭。远程教育、教育信息化、信息技术与课程整合越来越受到人们的重视,社会对教育软件的需求也因此日益迫切。为了满足现阶段社会对教育软件的需求,我国开发了大量的教育软件产品。但是由于教育软件需求的多变性,使得很多教育软件产品延期交付和投入成本加大。同时许多使用者反映,这些软件不符合实际教学的需要,要么不能反映一定的教学理念,要么只是简单传统课堂内容的照搬照抄,没有发挥出信息化教育的优势,在实际运用过程中没有很好的教学效果。由于教育软件的多变性、个体性、群体性、教育性和科学性的特点,其开发过程的特殊性与传统的软件开发过程相比尤为突出,教育软件的开发过程要遵循教育基本理论和学科教学的基本理论和观点,传统的软件开发方法已经不能很好地适应教育软件的开发。
教育软件开发中存在的问题主要是由于以下几个原因造成的:教育软件的特殊性和复杂性;开发方法的简单叠加;教学设计与软件开发脱节;教育软件缺乏标准;教育软件评测的主观性。为了解决以上存在的问题,提高教育软件的产品质量,人们一方面研究教育软件的系统化开发模型,用教学系统设计理论指导教学软件的开发过程;另一方面研究教育软件的内容组织和表现形式,用教学论和学习论指导软件细节的具体设计。
教育软件项目规模大多以中小项目为主,开发团队也是中小团队,客户需求变化快。因此,目前特别需要一种适合中小团队的软件开发方法,来降低开发风险,提高开发效率。极限编程(ExtremeProgramming,简称XP)是一种轻量、高效、低风险、柔性、可预测、科学而充满乐趣的软件开发方式。由于教育软件与一般的商业软件最为明显的一个区别在于教学软件具有教育属性,其设计、开发和评价均需要借鉴教学设计的理论与方法,因此以产品为中心的教学设计理论结合XP方法,可以为解决目前教育软件中存在的问题提供理论指导。
笔者针对教育软件开发中的问题,结合极限编程的基本原则、核心实践和教学系统化设计的基本理论,给出了基于XP的教育软件项目开发模型,并对其进行分析,可为教育软件项目的开发提供参考和指导。
1 常用软件开发方法
常用的软件开发模型有瀑布模型、原型法模型和极限编程。
1.1 瀑布模型
瀑布模型是软件工程中经典的生命周期模型,瀑布模型一般将软件生命周期划分为7个阶段,分别为:系统需求分析、软件需求分析、概要设计、详细设计、编码、测试和运行维护。瀑布模型是以文档为驱动,每一阶段工作的完成都需要确认。
瀑布模型将软件开发的各个阶段严格划分,各阶段之间存在着严格的顺序性和依赖性,在进行开发之前,必须通过需求分析预定义并明确软件需求。
瀑布模型存在以下不足:一是瀑布模型很难适应需求模糊、多变的软件系统的开发;二是确认工作的滞后性导致解决问题的代价呈指数增长;三是瀑布模型的软件开发周期较长。
1.2 原型法模型
原型是指模拟某种产品的原始模型。软件工程中的原型法指的是在软件开发过程中,在获取用户需求后立即进行快速的分析并建立原型,用户与开发者通过试用原型加强沟通与反馈,对需求进行补充和精确化,通过改进原型和反复评价,从而实现对系统精确的理解。
原型法首先建立能够迅速反映用户主要需求的原型,为用户展现实现后系统的样子,用户可以比较直观地从用户使用角度出发对原型提出修改意见。开发过程中引进了用户评价,使系统设计人员能很好地把系统开发和用户需求结合起来,避免了过去因为不断变化的用户需求而带来的大量人力物力的重复消耗,从而加速了系统的开发进程。
原型法存在以下不足:一是为了把系统尽快展示给客户,项目开发初期往往考虑的不全面,导致原型不能成为最终软件产品的一部分,只是一个例子而已;二是软件代码质量往往很低,而软件维护成本比较高,需要许多功能完备且实用软件工具的支持,对工具与环境的依赖性较高。
1.3 极限编程
极限编程是KentBeck在1996年提出的。XP是一个轻量级的、灵巧且严谨和周密的软件开发方法。它是一种近乎螺旋式的开发方法,它将复杂的开发过程分解多个相对比较简单的小周期;提倡积极的交流、反馈以及其他一系列的实践,客户和开发人员可以非常清楚开发进度、变化、潜在的困难和待解决的问题等,并根据实际情况及时地调整开发过程。
极限编程有以下核心实践:
(1) 系统隐喻(Metaphor)。系统隐喻就是对系统的形象描述,使全体开发人员对开发的系统有个非常清晰的轮廓,帮助项项目成员理解系统的基本元素及其关系。
(2) 计划策略(Planning game)。该实践的主要思想是迅速粗略地制定计划,并不断完善。XP包括主要两类计划策略:交付计划和迭代计划。
(3) 简单设计(Simple design)。XP项目团队在整个测试和设计过程中,保持简单的设计,满足系统当前的功能要求即可。
(4) 现场客户(On-site customer)。为了事项目按时交付且符合客户需求,XP重点强调了现场客户,这能及时有效消除团队成员等待决策时出现的瓶颈,减少产生需求误解的机会。
(5) 测试。开发人员编写单元测试,客户编写功能测试(验收测试),以保证代码正确并实现用户描述的功能。
(6) 重构。在保证能运行系统可测试的前提下,对现有设计进行优化,及时消除冗余,提高代码的可读性和软件质量。
(7) 结对编程。所有的代码都由两人共同完成,以保证所有的设计决策都至少由两人完成,并至少有两人熟悉系统的每一部分,一人负责代码的全局复查,以提高代码的质量。
(8) 持续集成。代码完成后尽快集成到现有系统中并进行测试。为了保证迅速找出错误,要求任何时候由一对程序员将代码集成到系统中,或由专人集成。
(9) 集体所有。系统的所有代码为小组共有,在保证XP通过所有测试的前提下,任何开发人员在任何时候都可以改进系统中的任何代码。
(10) 每周40小时工作。反对超时工作,长时间地持续工作会降低工作效率,疲劳会使开发人员会犯更多错误,频繁加班甚至可能产生深层次问题。
(11) 编码标准。开发小组必须遵循相同的编码标准,使编程风格趋于统一,便于代码的清晰交流和优化。
XP提出了以上核心价值和实践,为软件开发人员提供了指导。开发小组可以根据具体情况灵活修改规则,关键在于遵循XP的思想。
2 基于XP方法的教育软件项目开发过程
XP和教学系统化设计都是具有方法论性质的指导软件开发和教学的技术和理论,笔者结合极限编程和教学系统化设计,给出了基于XP方法的教育软件项目开发模型,克服了当前教育软件开发的弊端。该模型抛弃了传统的常用软件开发方式,首先在团队组成成员方面增加了学科专家、教学设计人员和教学评估人员,且始终强调他们在开发过程中的重要作用,其次增加了教学需求分析、教学设计、教育测评等重要环节。基于XP方法的教育软件项目开发过程见图1。
基于XP方法的教育软件项目开发模型把软件开发过程大致分为以下4个阶段:
(1) 计划和探索阶段。基于XP方法的教育软件项目开发过程首先应该建立用户角色模型,并组建团队。团队成员必须包含对教育软件项目成功至关重要的学科专家、教学设计人员和教学评估人员这3个角色,尽量保证所有用户对系统都满意,体现出教育软件的教育性和科学性。然后在开发人员和教学设计人员辅助下,由用户制定形成可测试、可评估,并且反应系统需求和体现当前学习理论、学习研究成果以及符合传递教学媒体特点的描述性需求。技术人员最终确定系统的体系结构,形成系统隐喻。
教育软件开发首先需要解决的问题就是明确教学目标,它是在对学习内容和学习者进行分析的基础上形成的,所以教学需求分析和教学设计是本阶段的核心部分,其关系到教育软件开发质量。教学需求分析和教学设计是一个系统化的调查研究过程。首先最为关键的工作是确定教学目的。如果教学目的不合适,再好的教学也不能实现设计师的真正意图。确定教学目的可以采取两种方法:领域专家方法和绩效技术方法,然后进行教学分析,确定在学习之前学习者应该具备的技能、知识和态度即入门技能。该环节主要由学科专家和教学系统设计人员共同完成。同时还要分析学习者学习技能的环境和应用技能的环境,制定教学策略。教学策略必须体现出教学行为的指向性、结构功能的合理性、策略制订的可操作性、应用实施的灵活性、教学策略的调控性等特点,这样才能保证教育软件开发出来后的实用性、教育性和科学性。
进行教学设计和教学分析之后,开发者辅助客户编写用户故事,客户所编写的故事是进一步讨论的引子,而不是详细的需求文档。在任何项目中,需要客户根据故事的重要性来安排开发者的工作,回答所有开发者的问题,编写所有的故事。
用户故事是在发行版本规划时估计进度的依据,也是验收测试的基础。它与传统的用户需求说明相似,但又有明显的区别。首先,它们提供的用户需求的详细程度不同:用户故事只需提供用于估计完成时间的足够信息,而在编码过程中,开发人员会与客户进行面对面的交流,获得细节;其次,用户故事应该尽量避开技术细节,如实现算法,其中心是用户的需要和利益;最后,用户故事不必像用户需求说明那样提供庞大的文档,其形式可以是用户习惯性术语表达,不包含技术性符号。
用户故事制定完成后,由团队所有成员尤其是教学评估人员对其进行评价,首先需要评价学生根据用户故事在完成教学任务之后,他们能够做什么,评价结果可以以教学目的清单的形式显示。开发和管理人员讨论和评价用户故事的技术可行性和经济可行性。
开发人员和客户划分用户故事,从中选择一定的素材集,迭代开发,经过测试验收后发布发行版本。
在划分用户故事后马上进行版本规划,即用户在开发人员的指导下,从需要实现的素材中选择最有价值并完成一定功能的最小素材集,经测试验收后发布。然后转入下一个版本,逐步形成最终发行版本。
在每一个发行版本的开发过程中,开发人员通过迭代规划将素材分成若干任务并迭代编码、测试和验收,不断加入到当前版本中。与版本规划类似,迭代规划必须选择每一次迭代需要完成的任务,并严格控制每次迭代的时间,当迭代有可能不能按时完成时,重新做迭代规划。
(2) 设计阶段。设计阶段包括概要设计和详细设计。概要设计就是设计软件的整体结构,包括组成模块、模块的层次结构、模块的调用关系、每个模块的功能等等。同时,还要设计该系统的整体数据结构和数据库结构,即系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系。详细设计阶段则是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。该阶段与传统软件开发过程的设计阶段最大的不同就是,教育软件项目的XP的开发过程提倡使用简单的设计方法,满足适用系统需求即可。
(3) 编码阶段。为程序员分配好编码任务,将软件的设计具体化为软件代码。教育软件项目的XP的开发过程推荐开发小组使用统一的编码标准、工具、环境。统一标准的编码规范可保证代码的一致性、可读性和可维护性。在编码过程中采用结队编程的方法,同时保证代码集体所有,在保证可运行、可测试的前提下,采用重构方法对代码进行优化,提高代码的可读性和质量。
(4) 测评阶段。在编码实现开发任务的时候,开发人员必须同时编写单元测试。一般情况下,建议先编写单元测试,每完成一个任务就集成代码,并立即对集成后的系统作测试。只有通过了所有的单元测试,无误的代码才能最终集成到系统中。在迭代结束时,所有的单元都被测试过,并进行过功能测试。
在软件进行单元测试和功能性测试之后,要进行教育总结性评价,通常这部分工作不是由教学设计人员来进行,而是由教学评估人员进行,保证评价的客观性和准确性。教育总结性评价包括两个阶段:专业评价阶段和实地试验阶段。专业评价阶段的目的是要判断当前教育软件所实现的教学方法或教学方案是否能够满足所定义的教学需求。实地测验阶段的目的是要记录采用该教学方案后在预期的环境中对目标人群的有效性。最后形成评价报告,该报告既要包括专家评价分析,又要包括评价的实地试验分析。评价报告在教育软件下一阶段的完善和优化工作中具有重要的指导意义。
4 结束语
在开发的一些小型教育项目中,笔者采用了基于XP方法的教育软件开发模型的方法,特别是在团队中增加了学科专家、教学设计人员和教学评估人员,开发出的教育软件的教育性和科学性很突出。实践证明,这种方法具有很好的借鉴和参考价值。但是在开发过程中,由于XP自身的开发特点,XP的某些实践得不到中国程序员和客户的接受,比如结对编程和现场客户,所以还需要对XP进行更多的研究和实践,使XP的实践和观念更加具有影响力。
摘要：探讨了教育软件项目开发过程中存在的问题,分析了目前常用软件开发模式的优缺点。结合教育软件项目的特点,给出了基于极限编程方法的教育软件项目开发模型。此模型将极限编程与教学系统化设计结合起来,是教育软件项目开发中行之有效的工程模型,可为教育软件开发者提供有益的参考。
关键词：极限编程,教育软件,教学设计,软件工程
参考文献
[1]BECK K.Embracing change with extreme programming[J].Com-puter,1999(10).
[2]CHROMATIC.An introduction to extreme programming[J].O'Reilly Open Source Convention in San Diego,CA,2001.
[3]GIANCARLO SUCCI,MICHELE MARCHESI.Extreme program-ming exanuned[M].Addison-Wesley,2001.
[4]郑人杰,殷人昆,陶永雷.实用软件工程(第三版)[M].北京:清华大学出版,1997.
[5]汪琼,朱万森,杨芙清.教学软件生产的层次模型[J].北京大学学报,1998(5).
[6]李航.敏捷型软件开发方法与极限编程概述[J].计算机工程与设计,2003(10).
[7]邓靖颖,黄穗.敏捷开发:极限编程在管理信息系统开发中的实践探讨[J].计算机工程,2004(24).
[8]钟名扬,刘美凤,杜媛,等.国内教学软件开发中的问题及分析[J].中国远程教育,2007(4).
[9]吕英红,朱晓晓.工程化的教育软件开发初探[J].电脑与电信,2007(11).
[10]李为民,张军征.教学设计与软件工程结合的教学软件开发模式[J].现代教育技术,2009(7).
极限编程 第8篇
一、极限编程的提出及其特点
伴随着全球信息化和经济化的潮流的影响,在世界范围内的软件开发发生了巨大的变化,传统上的软件开发由于软件需求的变化大、人员变动性等原因造成了软件开发效率低、周期长,无法满足需求快速变化的要求,不再适应于现在商业信息经济时代中的急剧的变化。因此,改变传统软件开发模式,提高软件开发的效率成为了软件开发人员研究的重点。20世纪90年代初,Kent Beck,Cunningham,Jeffries等人构建称之为极限编程(extreme Programming,简称XP)的基本元素。极限编程就是针对快速改变的软件需求而产生的。简单而言,极限编程就是一个高速迭代的过程。
XP是敏捷编程方法的代表,是一种典型的“轻量级”软件开发方法,它强调了3条基本价值观,即沟通、简单、反馈。不同于以往的软件开发理论的是,它没有对软件开发的整个过程进行强制而繁琐的规定,而是给出了一套在实际软件开发过程中需要遵守的活动实践原则。极限编程通常采用小组软件开发的过程和组内结对编程的方式。其中结对编程是两个软件开发者在一台电脑前一起工作的一种编程实践,是极限编程方法的基础。而小组软件开发的过程则提供了在开发过程、产品和小组协同工作之间平衡的重点,并且在规划和管理软件工程中利用了广泛的工业经验基础。小组软件开发基于以下几个基本原则:遵循订制好的过程,并且得到快速反馈时,学习是最重要的;高产的小组协同工作需要有具体的目标、良好支持的工作环境和强有力的指示及领导等因素的结合;从彻底有效的开发练习中获得与工程中的实际问题作斗争的有效解决方案;提倡正确的指导源于先前实践的重要性。
二、极限编程在计算机实践课程中的应用
在计算机实践教学中,进行软件开发训练的时间往往定时,受限于教学时间。极限编程是一种限时性的软件开发方法,它可以有效地解决实践中软件开发设计中的时间不足的问题。在另一方面,它强调简单化设计的理念、循环渐进的周期性过程有利于简化目标的难度和复杂性,有利于设计的不断优化,大大地提高了实践教学的效率。
1、建立起具有挑战性的可量度的目标
它提供了一个在个人软件开发过程(PSP)基础上建立的简单框架,提供了许多规范和程序,但绝大多数都类似于PSP中使用过的东西。以周期划分产品的开发,提供了一定的时间内完成若干个开发周期的方法。每个周期都由七个步骤:决定策略、进行计划、考虑需求、设计、执行、测试和最终检查组成,包括了一个完整的需求、设计、实现和测试开发过程。这有效地控制项目的难易程度,解决了课程的严格时间表和因实际需求不稳定经常变化引起时间耽误之间的矛盾,提供了一个科学的软件开发过程。
2、建立共同工作框架,通过沟通,反馈进行有效的组内和对外交流。
小组间的比较可以体现出不同计划步骤各自的优越性,为小组评估提供了参考。
通过小组划分的方式,以4-8人为一个小组,共同完成和管理一个软件项目。以明确完成的任务为目标,参照共同的工作框架,包括:计划、时间、顺序、责任人对项目进行至始至终的有效控制。采用组内学生之间以结对编程的方式相互探讨,培养和强调学生之间的沟通,反馈意识,共同学习,协同工作。这可以一方面引发学生自主地意识到提高程序可读性可理解性的重要性,使得其对程序设计规范化的深刻理解。另一方面小组各成员共同参与对软件需求、可行性的分析,整体功能结构的划分,进度安排、计划的设计执行,模块化结构的设计,亲身体验整个工程的管理和责任划分的过程。
3、采用了多周期的循环开发战略、计划跟踪和反馈有利于对目标进展过程的控制。
它从一个最小规模的产品版本开始,建立起一个最终产品的最简化的子集,首先使核心产品运行起来,然后通过循环开发战略,在每次得到了最终产品的可运行前期版本同时,也得到了获得下一周期目标的精确计划和为后续的每个周期服务的平台。在课程中,可根据具体的教学时间,通过控制开发周期,来确定软件的设计规模和开发深度。这有效地控制了软件开发的大小和时间,并以可运行的成果消除软件开发过程中失去目标的盲目性,增强了学生的信心,从而为小组工作提供有力的支持。
4、在多周期的过程中采用了大量的角色分配和角色责任,提供了各种角色体验。
以角色体验的方式解决了在实践教学过程中一味地以编程为主的教学模式,而忽视软件开发过程中的工程管理及控制等方面的问题,给学生提供了学习运行一个小组工程方方面面及小组处理工程管理任务的机会。与此同时,角色责任细化了个人在软件开发中的分工,有助于每个人专注于个人需要学习的要素。在实践过程中以周期为单位,在每个周期中小组各个成员各自承担角色的任务,而在下一个周期中各成员可通过互换角色,使得各成员获得开发过程中不同角色的体验,有效地解决了在有限时间内多角色体验的问题。
5、它提供了一整套完整的标准化的质量和效率评估机制、开发纪律。
它采用“强调整个工作过程而不是个人表现得如何”的评价标准,提供了一个可实施的平等的角色和小组评估体系。通过纪律约束来协调成员之间的工作,并为小组协同工作的问题提供指导,促进小组成员间的学习经验交流,为进行一致的高质量的工作提供重要的支持。通过对目标和评测的强调来进行项目的规划和跟踪,方便管理日常工作,提高软件开发效率。在实践中可参照标准化的质量和效率体系制定出与所开发软件相适应的角色责任和小组评估表,通过组间相同角色对质量表的完成程度进行比对,获得实践总结,同时强调了小组的协同性和整体效率最优化的团队机制。这大大地改变了实践教学中以个人为主的开发模式。(下转第64页)
(上接第66页)
三、小结
极限编程思想的提出是软件设计开发与商业化结合发展过程中的一个重要的里程牌,它为软件开发提供了科学的计划和管理,极大的提高了软件产业的效率和质量。在信息急速发展的时代,课程教学也在不断地与时俱进,如何解决信息课程中实践教学环节中的问题也显得日益突出,极限编程无疑为信息教学尤其是在实践应用上提供了一个有效的改进方法。
摘要：极限编程(XP)是流行的敏捷开发方法之一。它是一种适应于中小规模团队的轻量级、灵巧的软件开发方法。它所具有的良好的适应性、目标的可量度、周期性的划分等诸多方面优点使得将其方法引入计算机实践中应用成为可能。极限编程方法的运用为计算机实践教学提供了一个有效的改进途径。
关键词：极限编程(XP),结对编程,小组软件开发
参考文献
[1]Kent Beck.解析极限编程——拥抱变化(第二版)[M].雷剑文,陈振冲,李明树译.北京:电子工业出版社,2006.
[2]RobertMartin.敏捷软件开发:原则,模式和实践[M].邓辉译.北京:清华大学出版社,2003.