Scrum及XP组合应用策略研究

高玄凌

摘 要：本文介绍了软件开发过程中传统的开发模式，由于传统方式存在某些不足之处，敏捷开发的概念孕育而生，通过对比，具体分析了极限编程和Scrum两种敏捷开发方法，提出了组合应用两种方法的一些策略，描述了使用的方法和适用场景，尽可能地发挥两者的长处，通过科学的项目管理，使整个软件开发过程取得更好地实践效果。

关键词：Scrum 敏捷开发 极限编程

中图分类号：TP311.5 文献标识码：A 文章编号：1672-3791（2017）11（b）-0013-02

软件过程作为软件工程的基本要素，是决定软件质量好坏以及整个软件项目成败的关键因素。软件开发使用的主要传统模型是瀑布模型，瀑布模型流传至今，影响深远。瀑布模型根据软件生命周期，将软件过程主要分为问题定义、可行性研究、需求分析、设计、编码、测试、运行和维护等阶段，各阶段要求有明确的结果、规范的文档以及严格的评审，阶段间有明确的界限，只有上一阶段结束才可进入下一阶段，是标准的顺序模型。在需求明确的情况下，瀑布模型的特点能够保证软件的质量。随着软件行业的飞速发展，软件应用的差异化、需求的不确定性以及系统的复杂性等因素导致瀑布模型无法满足软件发展的需要，开始出现原型法、迭代开发、增量开发的思想，快速原型法、增量模型、喷泉模型、螺旋模型等不同的软件过程模型也随之诞生。发展到今天，RUP、微软过程以及敏捷开发已经成为了主流，而快捷易用的敏捷开发方法更是成为了多数中小型项目的首选。

敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发[1]。2001年2月，17名知名的软件工程专家聚集在美国的犹他州雪鸟滑雪胜地，这些不同敏捷方法的支持者经过两天的讨论，共同起草了一份《敏捷软件开发宣言》，强调了敏捷软件开发的四个核心价值观：“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”[2]。这份宣言正式明确了“敏捷”这一术语，同时强调宣言中左项要高于右项。敏捷开发方法的代表包含了极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发等，其中极限编程与Scrum是主流的敏捷开发方法。

1 Scrum和XP的比较

极限编程（ExtremeProgramming，简称XP）由Kent Beck在1996年提出的，是一个轻量级的、灵巧的软件开发方法。极限编程遵循五个重要的价值观：“沟通、简单、反馈、勇气、尊重”，同时提出了十二项原则：“计划游戏、小型发布、简单设计、测试驱动开发、持续集成、重构、结对编程、代码集体所有、现场客户、系统隐喻、编码标准”[2]。Kent Beck认为XP不但可以适应中小规模的团队开发需求模糊或者快速变化的项目的需要，而且对任何规模的团队都起作用[3]。

Scrum源于橄榄球术语，由Jeff Sutherland和Ken Schwaber提出，是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum定义了一系列实践和预定义角色的过程框架，如角色有产品负责人、Scrum主管、开发团队等，工件包括产品订单（Sprint Backlog）、冲刺订单、燃尽图等，活动包括计划会、每日立会、评审会、反思会等。

因为XP和Scrum的广泛应用，敏捷开发者们经常會将两者进行比较，XP和Scrum主要有四个差别[4]。

（1）Scrum的迭代长度通常要比XP长。前者的一个Sprint的周期一般为2～6周，后者的一个迭代长度则大致为1～2周。

（2）Scrum在一个Sprint的周期内不允许修改需求（产品订单），而XP在一个迭代中允许使用其它的用户故事（User Story）替换尚未实现的，前提是实现的时间是相等的。

（3）在迭代中，需求是否严格按照优先级别来实现是不同的。XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做。

（4）Scrum关注项目的管理和组织实践，而XP关注的是实际的编程实践。Scrum和RUP一样定义了一套角色、活动和工件，是一套过程框架；XP则规定了测试驱动的开发、结对编程、简单设计、重构等约束团队的十二项原则。

2 Scrum和XP的组合应用策略

根据对一些软件企业的敏捷实践分析，在实际项目中，以Scrum应用为基础，并选择性的结合XP的某些原则，能够取得更好的实践效果。

2.1 保持迭代周期在2～3周

Scrum的一个Sprint的周期一般为2～6周，XP的一个迭代长度则大致为1～2周。敏捷开发的基本思想就是迭代和循序渐进，为保证能尽快提供小型发布版本，显然迭代周期越短越好。但是周期越短，一个周期能够完成的迭代任务就会过小，不仅导致分割订单的成本增加，而且持续集成的压力也更高，因此综合两者，将Sprint的迭代周期限制在2～3周比较好，根据项目特性确定具体的周期。

2.2 根据优先级，集体确定每个周期迭代任务

在每个Sprint开始时，需要召开计划会议来确定冲刺订单（Sprint Backlog）。在一个稳定而又熟练的团队中，产品负责人能够清楚地分析每个Backlog和每一个成员的能力，能够轻易确定一个冲刺订单。实践中，团队成员可能经常会流动，业务的领域复杂性也会产生干扰，导致产品负责人无法准确进行判断。可以采取的一个有效方法，是由产品负责人根据产品订单的优先级团队中的每个成员独立地对产品负责人提出的冲刺订单进行成产率评估，然后综合大家的评估，从而确定冲刺任务。当然，成员间估算差异较大时，应该分别阐述理由，以做出更加合理的决策。

2.3 制定统一的编码规范

统一的规范有助于各成员理解其他成员的代码，促进代码共享，降低集成的复杂度，提高代码质量。

2.4 坚持测试驱动的开发，并持续集成

测试驱动的开发方式本身具有很多好处，即时的白盒或黑盒测试能够及时发现代码中的bug，从而及时进行修改或者重构以改善代码质量，并保证不影响冲刺周期。当然，测试驱动需要手工测试和自动测试并行，代码首先在本机进行单元测试或集成测试后才能提交到服务器上，通过对测试服务器进行脚本配置以自动进行集成测试。相当多的企业会坚持每日持续集成，使程序中的缺陷当天得到解决。

2.5 坚持现场客户的方式

团队对项目领域不熟悉或者存在业务重构时，现场客户的作用尤其重要。现场客户能够及时参与团队的每日立会以及其它相关会议，能第一时间明确冲刺订单中的业务相关问题，及时给予解答。

3 结语

作为主流的敏捷开发方法，极限编程与Scrum都有着广泛的应用实践。通过对两者进行组合应用，能够有效避免各自缺点，取得更好的实践效果。

参考文献

[1] 王桐.数据分析方法论的革命—再不掌握敏捷思维你就out了[J].中国计算机报，2015（15）：39.

[2] 王素芬.软件工程与项目管理[M].西安电子科技大学出版社，2010.

[3] （美）Kent Beck， Cynthia Andres，著.解析极限编程—拥抱变化[M].雷剑文，译机械工业出版社，2011.

[4] （瑞）Henrik Kniberg，著.硝烟中的Scrum和XP—我们如何实施Scrum[M].李剑，译.清华大学出版社，2011.endprint