基于风险驱动的Scrum方法改进研究

严振亚

（天津开发区先特网络系统有限公司 天津 300192）

基于风险驱动的Scrum方法改进研究

严振亚

（天津开发区先特网络系统有限公司 天津 300192）

针对提高Scrum软件开发方法应对风险的目的，采用改进软件过程的方式，分别对需求风险、技术风险、进度风险和质量风险增加监控节点。通过在软件过程中加入了需求风险分析环节、系统设计环节、每日报告记录和持续集成机制、功能测试环节等节点，确保在软件开发过程中的风险点得有效的监控和预测。得出基于风险驱动的Scrum敏捷开发方法可以有效的应对开发风险，增加软件产品开发成功机率的结论。

软件工程；过程改进；敏捷；Scrum

随着社会信息化水平的不断提高，人们对软件的依赖程度也随之增长，市场需求对软件的更新换代提出了新的要求。传统的软件工程方法体系由于过于笨重，已经不能满足软件开发现状，人们迫切的需要一种轻量级的软件过程方法来适应快速的市场变化。因此敏捷方法在过去的几年里得到了迅猛的发展，其特征是用适应变化、频繁迭代、用户参与等方式代替原有的以文档驱动的重量级软件开发过程，这其中又以Scrum方法最为流行。

但是传统的Scrum敏捷开发方法中并没有针对风险进行有效的监控和处理机制，这很容易导致开发失败。文中针对Scrum开发过程提出一种基于风险驱动的改进方法，在整个开发周期的各阶段分别建立风险监控检查点，主要针对需求风险、技术风险、进度风险和质量风险4个方面对开发过程进行监控。在风险发生之前，尽早的识别并进行处理，将风险对开发过程的影响降到最低程度。

1　Scrum简介

Scrum是一种敏捷开发过程，它将软件开发过程划分为若干个迭代（称为Sprint），每个Sprint迭代通常在2～4周内完成，每次迭代都会从Prodcut Backlog（产品列表）中选取本次需要完成的功能，然后细化为1～2人/天的工作量单元，组成Sprint Backlog（迭代列表）。

每天由团队成员领取Sprint Backlog中的任务，同时通过Stand Meeting（站立会议）确定前一天完成的工作、后续要完成的计划和遇到的问题。当一个Sprint迭代周期完成后，团队应该交付本次迭代的成果，并通过 Srpint Review Meeting （Sprint评审会）向相关干系人演示。如果接受本次迭代成果，则产生Release Product（发布产品）并最终完成本次迭代。

图1　Scrum开发方法

2　使用Scrum开发软件存在的风险

2.1需求风险

在Scrum开发方法中，需求是由Porduct Owner（产品所有人）提供的Product Backlog清单，这个需求清单并没有经过传统软件工程的“需求分析”过程，因此其中难免会存一些业务层面的风险。比如：Product Backlog中不同功能点之间互相矛盾、隐含的非功能性需求、需求描述不清等问题。这些问题在没有风险监控的情况下，会直接进入Sprint Backlog，最终导致某次迭代失败。

2.2技术风险

技术风险来源于Sprint迭代周期过程中。由于对某个功能使用到的技术预期估计不足，在开发过程中可能会遇到技术难点无法实现的情况，尤其在缺乏开发经验的团队中此类风险更为明显。它会导致Sprint迭代失败，最终无法交付预期的软件产品。

2.3进度风险

虽然在Stand Meeting中每天都要说明自己完成工作的进展和计划，但对于长达数周的 Sprint迭代周期，Scrum Master（Scrum教练）对进度把握也很容易出现问题，造成进度失控。同时对于已经完成的程序代码，如果在编译或集成时遇到问题，同样也会对本次Srpint的进度产生不利的影响。

2.4质量风险

现有的Scrum开发方法，在每次Srpint迭代结束后会将本次成果直接提交给干系人。而这个过程中缺少了传统软件的功能测试环节，功能测试的目的是为了验证软件完成的功能与用户原始需求的符合程度，如果检查出软件存在缺陷，则需要开发人员进行相应的调整并进行回归测试，最终将合格的产品交付给用户。而缺少功能测试环节，会将软件的Bug直接暴露给最终用户，这势必会给软件带来质量风险。

3　基于风险驱动的Scrum过程改进

3.1增加需求风险分析环节

在每次迭代周期开始阶段，团队成员需要从 Product Backlog中的选择本次迭代需要完成的功能，并加入到Sprint Backlog中。此时增加“风险分析（Risk Analysis）”环节（图2），由团队成员对本次需要实现的功能进行风险分析，尽量减少需求层面对于后续开发迭代的影响。

需求风险分析主要从以下几个方面进行：

检查不同功能点之间是否互相矛盾。用户的原始需求中经常存在不同功能之间相互矛盾的情况，比如在一个报销审核流程中，某个需求点规定只有大于等于500元的报销请求由经理审核后再送交财务部门，而小于500元的报销申请直接送交财务审核。但在另一个需求中却要求财务部门在处理报销审核的前提是，必须经理审核通过，否则做退回处理。这2个需求明显存在矛盾，因此在需求风险分析过程中就需要甄别这类风险，避免将风险推迟到迭代过程中才被发现。

图2　基于风险驱动的Scrum开发方法

检查原始需求中包含的非功能性需求。在 Product Backlog中的需求主要都是功能性需求，由于用户通常是非专业计算机人员，对非功能需求几乎很少关注。但非功能性需求往往对项目的成败起着关键性作用，因此在一个迭代周期开始之前发现非功能性隐藏需求非常重要。此时将主要检查系统的处理性能、可靠性、响应时间、安全性、易用性等几个方面。

检查是否存在需求描述不清等情况。在Product Backlog列表中的需求是由用户直接提出的，此时的需求并没有经过结构化处理，其中难免会有一些描述模糊或叙述不清的情况。对于此类需求要在迭代前及时发现，并排除在 Sprint Backlog之外，等待用户细化需求并更新Product Backlog后再考虑是否加入下一次迭代，否则极有可能造成开发出的软件和用户希望得到的功能相差较大的情况。如在一个需求中，用户只要求报销时必须要有流程，但并没有说清具体流程情况，类似这样的情况都可以归为需求描述不清的范围。

3.2增加系统设计环节

软件设计工作对于后期的开发环节至关重要，它可以在开发过程中对所使用的技术、标准、规范给出有效的指导，同时软件设计又是从全局出发，在宏观的层面上考虑软件各功能模块间的关系，因此也可以使软件保持良好的结构特性。

但Scrum过程中并没有针对系统设计的专门环节，当在一次迭代中生成Sprint Backlog后，团队成员就开始按照自己的能力领取任务，开发人员关心更多的问题是在规定的时间内完成自己负责的模块开发，而很少考虑从全局的角度审视软件，也容易忽视各模块之间调用关系是否合理、是否为高内聚低耦合等架构层次的问题。这种开发模式如果一直持续下去，经过几次迭代后，软件的内部结构会变得越来越差、可能会导致可维护性变差、处理性能降低、模块间的耦合程度增高等一系列问题。

因此在一次迭代开始之前，建议增加＂系统设计（System Design）＂环节（图2），尽量降低由于缺少全局设计对于后期开发的影响。系统设计阶段需要团队成员集体参与，不再专门设置软件设计岗位。因为在Scrum模式中开发团队非常了解用户需求，并且全员参与讨论系统设计也可以使每个成员接受最终的设计方案。系统设计主要包括接口、领域类和类之间的交互关系3个方面，在不违背Scrum的轻量级开发方式的核心思想上，建议只进行必要的设计内容，减少非必要的设计文档，主要以UML图的方式描述设计思路和实现原理，并配合少量的文字描述即可。如接口设计时仅描述本次迭代需要完成的功能所涉及到的Interface和它内部的方法；对于涉及到的核心领域类以及对象之间的调用关系，可以采用UML中的类图和时序图来描述，并在不易理解的地方使用简单的文字说明。目的是在系统层面有一个整体的设计框架用来约束开发阶段的随意性，同时又要尽量保持Scrum开发方法的敏捷特性。

3.3每日报告记录和持续集成机制

虽然Scrum开发方法中包括每日站会的环节，通过这个10分钟左右的会议使团队各成员互相了解工作进度、计划工作内容和遇到的问题。但这个会议并没有留下任何记录数据，只能使团队关注最近几天内的工作进展情况，缺少项目整体观察视角。同时由于在Sprint过程中团队里的每个成员很少关注各自开发的模块在集成后会出现的问题，这类问题最终会推迟到Sprint结果之前的几天才被发现。以上这些问题都有可能对项止进度造成潜在的影响，因此必须尽量减少此类风险发生的机率。

增加＂每日报告记录（Daily Report）＂环节。（图2）为项目团队选择一个工作日志系统，在当天结束工作之前，要求团队成员根据当天完成的工作情况填写日志信息。其中包括实际工作内容、完成的百分率、是否遇到问题等关键信息，Scrum Master可以根据这些日志信息发现Sprint过程中遇到的进度问题，并在风险发现前进行干预。日志提供长期监控项目的历史信息用于数据分析，每日站会提供最近短时间内工作情况用于成员间的相互沟通，两者相结合可以对Scrum开发周期进行全面的监控和风险预防。

增加＂持续集成（Continuous Integration）＂机制。（图2）为了能够将模块集成阶段发生的问题提前发现，团队成员每天结束工作前需要将已完成的工作提交到版本控制服务器，并在设置的时间段编一编译。如果出现问题则会使用邮件的方式自动发出通知，以便及时发现问题并进行修复。

3.4增加功能测试环节

按照传统软件工程的思想，测试和开发要由不同的人完成，这样可以尽量减少由于心理、实现思路等原因对最终测试的影响，以便发现更多的软件缺陷。在Scrum开发模式中并没有强制约束对每个Sprint的测试环节，在实际操作中即使测试也是由团队成员自己完成。但这样做会存在很大的问题，通常开发人员对测试专业技术并不精通，再加上不愿意否认自己的工作成果，导致很多软件缺陷都没有被及时发现，为软件质量带来很大的风险。为了解决这样的问题，可以增加QA团队和功能测试环节。

增加QA团队，由这些质量保证人员对软件进行功能测试。为减少测试对Scrum轻量级过程的影响，在测试过程中不建议写测试用例，而是以Sprint Backlog中的需求点做为测试依据，结合测试人员的经验对软件进行功能测试。测试过程中可以将发现的缺陷分级管理，根据项目的实际情况规定具体级别以上的缺陷完全修正后才能够发布最终的Sprint Product。通过增加测试环节可以有效的减少软件产品风险对项目的影响。

4　结束语

本文以风险的预防和控制为中心，对Scrum开发过程进行改进。增加了需求风险分析、系统设计、每日报告记录、持续集成机制、功能测试等环节，从需求风险、技术风险、进度风险和质量风险各个层面对Scrum开发过程进行监控，尽可能减少风险对于开发过程的影响。

［1］刘慧玲,王申申,陈晓军.Scrum敏捷方法在快速开发中的实践与改进［J］.电脑知识与技术,2012,8（21）:5168-5169.

［2］孙开翠,杨立扬.基于SCRUM的大型软件开发模型的研究［J］.电脑知识与技术,2013,9（13）:3043-3046.

［3］徐伟,王浩宇,谢梦，等.结合CMMI的Scrum敏捷软件开发研究［J］.计算机技术与发展,2014,24（9）:89-92.

［4］施瓦伯.Scrum敏捷项目管理［M］.李国彪,译.北京:清华大学出版社,2007.

［5］Chris Sims Hillary Louise Johnson.Scrum要素［M］.徐毅,译.北京:人民邮电出版社,2013.

［6］皮希勒,李忠利.Scrum敏捷产品管理［M］.北京:清华大学出版社,2013.

Improvement of Scrum method based on risk drive

YAN Zhen-ya
（ESINT System Co.，Ltd.，Tianjin 300192，China）

Aiming at the risk prevention through improving Scrum development method,this paper adopted the software process improvement to increase monitoring nodes for demand risk,technical risk,schedule risk and quality risk.Addition of demand risk analysis,system design,daily report record and continuous integrating system,function test and so on to the software process to make sure the risks are monitored and forecasted effectively during the software development.It is concluded that the quick risk-driven development method of Scrum can respond to development risks effectively and increase the success probability of software development.

software engineering；process improvement；agile；Scrum

TP311.5

A

1674－6236（2016）13-0152-03

2015-07-07稿件编号：201507059

严振亚（1982—），男，天津人，硕士，副高级工程师。研究方向：软件工程过程和系统架构设计。