敏捷软件项目风险管理探析

邢晨光 钱嘉怡

（浙江大学，浙江 杭州 310000）

1 软件项目风险管理的意义及方法

1.1 软件项目风险管理的意义

软件项目管理是一个技术密集型的复杂管理过程。软件产品开发过程涉及范围广，需要不同专业的人员参与，因此软件项目管理过程中需要综合考虑，项目各干系人、资源直接的关系，才能把软件项目顺利成功落地交付。在采用敏捷项目管理方法之后，大多数企业只看到敏捷的快速交付，提高效率，往往忽略了敏捷项目管理过程的风险，造成项目的失败。本文着眼于敏捷项目管理过程中的风险管理问题，基于Scrum敏捷框架提出一套风险管理方法来解决敏捷项目管理过程风险管理的问题。

在软件开发项目过程中，会面临着不完整的需求、不可追踪的需求、时间限制、不现实的时间表、通信和技术变化等风险。这些项目管理过程中的风险，可以通过应用有效的风险管理方法来解决。瀑布式项目中，风险管理具有完整的流程和理论，总体分为风险识别、风险评估、风险分析、风险应对、风险监控五个活动。但是在敏捷项目中，并没有特别强调风险管理的内容，生搬硬套瀑布项目的风险管理方法应用到敏捷项目中，并不合适，复杂且强调流出的风险管理方法与敏捷所倡导的价值观也不相符。所以本文以Scrum敏捷项目管理过程中的风险管理为研究切入点，研究适合敏捷项目的风险管理方法意义重大，可以补充完善敏捷项目风险管理领域相关方法与理论。

在互联网用户逐年增加的背后是无数个软件产品在为其提供服务，其中包含面向用户的APP，也包含面向企业的软件业务系统。这些软件产品通过软件开发项目交付上线运行，在研究软件开发管理过程，如何让软件产品提高质量和用户满意度具有重要现实价值。

在面对瞬息万变的市场竞争环境下，越来越多的公司在进行敏捷转型。2001年，软件行业思想领袖共同发表《敏捷宣言》，正式宣告敏捷开发运动的开始，并提出敏捷价值观和敏捷原则。如今流行的敏捷项目管理方法都源于敏捷思维模式、价值观和原则。因此研究企业在使用敏捷项目管理方法过程中遇到的问题，具有重要的实践意义。

1.2 软件项目风险管理的方法

1.2.1 Boehm风险管理模型

20世纪80年代，Boehm比较详细地对软件开发中的风险管理进行了论述，并提出了软件风险管理的方法。Boehm定义软件风险管理为“试图以一种可行的原则和实践，规范化地控制影响项目成功的风险，其目的是辨识、描述和消除风险因素，以免它们威胁软件的成功运作”[1]，并在《Software Risk Management》比较详细地阐述了软件项目开发中的风险，提出了著名的软件项目风险管理Boehm模型。Boehm总结出软件项目中常见的十大风险，并给出应对策略，如表1所示。

表1 Boehm十大风险

1.2.2 CRM风险管理模型

1999年前后美国软件工程研究所(Software Engineering Institute)提出持续风险管理模型——CRM(Continuous Risk Management)，该模型要求在项目生命期的所有阶段都关注风险识别和管理，并将风险管理划分为5个部分：风险识别、风险分析、风险计划、风险跟踪和风险控制[2]。该模型强调风险管理的各个部分之间的沟通，并将沟通视为风险管理的核心。通过持续的分析评估可能对项目造成负面影响的风险事件，筛选出需要最优先处理的风险事件实施风险控制的策略，并持续评估风险控制策略的实施效果。

1.2.3 MSF风险管理模型

2006年微软公司提出MSF4.0（Microsoft Solutions Framework）风险管理模型，该模型把项目风险定义为：任何可能对项目结果产生积极或消极影响的事件和因素[3]。MSF模型强调风险管理一定是主动的、规范的，且不能缺少的管理过程。项目团队应持续对风险进行识别、分析评估、应对和监控，直至项目风险消除对项目的负面影响。在MSF风险管理模型中，持续地记录风险并形成风险知识库是十分重要的。

在MSF风险管理模型中，风险管理是尽早识别风险并进行风险管理。风险管理的目标是消除风险事件给项目带来的负面影响，或尽可能降低风险事件的负面影响程度。有效的风险管理可以让项目团队在项目交付过程中，尽可能保证风险和机会间的有效平衡。

MSF风险管理原则是风险必须被预先解决，它是系统过程的一部分，其将风险管理视为自主且积极的工作[4]。该风险管理模型具有如下4个特性：

（1）灵活性

项目管理过程中环境变化是项目风险的主要来源之一，不同项目阶段的变化都可能带来不同的风险，MSF风险管理要求团队成员在应对项目环境变化时，要具有高度灵活性，只有这样才能持续应对项目环境变化带来的风险。

（2）公开性

MSF模型针对风险提出了一个可以在团队内部与外部都适用的公开方法。每个项目成员都应该参与项目风险的识别和分析评估过程，项目成员之间通过公开且透明的讨论来确定项目风险，制定风险应对策略，并对项目风险管理达成一致共识。

（3）知识性

在持续风险管理过程中，项目团队会不断积累风险管理相关经验，MSF模型认为这些经验可以给其他项目进行指导，项目团队成员在参与项目过程中吸收学习这些知识，在交流过程中传播这些知识，给其他项目的风险管理工作提供指导。

（4）责任

MSF模型强调项目风险管理是全部项目成员的责任，并不仅仅是项目经理的工作。在风险识别分析后每个项目成员都应承担风险管理的责任。项目成员在项目开发过程中应该更加积极主动地参与风险管理工作，确保项目风险管理活动贯穿项目全程。

2 敏捷项目管理方法

2.1 敏捷项目管理的概念

维基百科对于敏捷的定义为：综合使用平衡、协调、速度、反应、力量、耐力和毅力等运动技能，并有效地做出改变身体位置的能力。在软件项目管理过程中敏捷意味着项目组团队根据组织内外部的开发环境变化，快速响应变化，做出应对措施，保证团队的持续交付能力，满足客户价值。

被采用较多的敏捷方法主要有Scrum方法、极限编程、水晶族等敏捷方法。虽然敏捷方法各自不同，但其都遵守敏捷所提出的价值观和原则：“个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划”[5]。本文主要以Scrum敏捷方法为基础，构建一套基于Scrum敏捷框架的风险管理方法。

2.2 Scrum敏捷方法

Scrum方法由Ken Schwaber和Jeff Sutherland在1996年正式提出，其目的在于充分发挥面向对象和构件技术的开发方法的优势，着重于对迭代方法的改进。Scrum将工业过程控制中的概念应用到软件开发过程中，其认为软件开发过程更多的是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。

Scrum敏捷项目主要包含以下几个主要过程：收集产品需求backlog、敏捷迭代规划会议、每日站会、上线评审会议、敏捷回顾会议。五个过程在每个sprint中重复进行，如图1所示。

图1 Scrum敏捷模型

产品需求被定义为产品需求积压（product backlogs）。产品需求通过用户故事的模式进行描述，每个用户故事都需要拆分到可以评估的程度。所有的产品需求都是从用户故事开始，并逐步被拆分成颗粒度更小的用户故事，直到可以用于被开发人员直接评估开发工时投入的程度。

Scrum方法将项目分解为多个Sprint迭代周期，每个Sprint迭代代表一个用时2～4周的完整开发过程。首先，项目需求会被分成不同的用户故事，然后在Sprint敏捷规划会议上，根据客户或核心业务人员给出的优先级对用户故事进行排序，确定下一个Sprint周期要开发的需求内容。并且在Sprint敏捷规划会议上，需要项目团队成员一起参与，共同对本次Sprint迭代周期的用户故事进行工作量评估，一般采用计划扑克的方式进行工作量评估，并进行任务拆分和分配。在评估过程中，需要特别注意成员要站在完成一个完整的用户故事的角度进行评估，不能仅仅考虑自己负责的任务。

在Sprint迭代开发过程中，项目团队每天早上在固定时间、固定地点都会进行一场十分钟以内的站立会议。在会议上每个团队成员都需要沟通3个内容：昨天做了哪些任务，今天计划做哪些任务，在开发过程中是否遇到问题。站会要求团队成员轮流进行主持，项目经理（敏捷教练）参与，并在会后协调资源解决成员提出的问题。

在每个Sprint周期结束后，项目经理需要组织团队成员和业务客户进行敏捷评审会议，在会议上给业务客户演示本次迭代的系统功能，收集客户提出的建议，以用户故事的形式加入到产品需求积压中，并在后续的Sprint中进行实现。

在Scrum中，项目团队需要在Sprint结束后定期组织回顾会议。在回顾会议上，团队成员总结上次迭代过程中遇到的问题，如在工作中有哪些不足之处和可取之处。对于不足，项目经理需要引导成员进行反思制定后续的策略；对于可取之处，也要进行团队经验固化和分享，并在后续的Sprint中持续改进。

3 敏捷项目风险管理

3.1 软件项目风险管理方法

软件项目风险管理主要分为风险识别、风险分析、风险评估、风险应对四个过程。在传统的瀑布型项目中，风险管理为前置过程，在项目早期就需要对项目风险进行完整的风险管理。

对于敏捷软件项目，基于CRM风险管理方法，结合Scrum敏捷模型在每个Sprint中进行完整的风险管理过程，并持续积累项目风险管理经验。敏捷项目风险管理模型如图2所示。

图2 敏捷项目风险管理模型

3.2 敏捷项目风险识别

风险识别是通过系统化结构化的方法找出可能影响项目的风险事件。软件项目风险识别可以在把握软件开发整体脉络的基础之上，及时挖掘可能诱发风险的因素并加以处理，有效防止风险的发生和进一步扩大，为软件项目开发节省一定的成本和时间投入，对软件开发具有一定的促进作用[6]。

在敏捷项目中，风险识别过程结合到敏捷规划会议上进行，项目经理在完成用户故事评估后，引导项目成员进行风险识别。风险识别方法可以采用头脑风暴法、经验法等，针对本次Sprint周期中的用户故事来进行发散性的识别风险，在识别过程中可以结合Boehm十大风险作为风险识别的参考，便于成员快速识别风险。在敏捷项目中，项目被拆分为多个敏捷迭代，在不同的迭代中结合MSF风险管理理论，可以对风险进行持续的识别，动态识别迭代中的最新风险。

3.3 敏捷项目风险分析

项目经理组织团队成员完成风险识别之后，需要组织团队成员对风险进行定量分析。一般采用专家法对每条风险发生的可能性和影响程度进行定量评估，通过Boehm风险公式（1），分别计算出每条风险的影响程度，进行优先级排序。

项目团队需要制定风险准入标准，在风险影响程度评估和风险排序之后，经过多次Sprint团队需要定义出适合团队自身的风险准入标准，并针对敏捷规划会议上评估出的风险清单，确定出本次Sprint风险中符合准入标准的风险清单。

3.4 敏捷项目风险应对

在敏捷项目风险管理中，通过风险识别和风险定性定量分析得出不同迭代中需要重点关注的风险类型。在敏捷实践中项目团队需要根据不同迭代中的重点风险事件制定风险应对计划并持续对风险进行监控，把握风险的最新情况。通过风险应对措施和持续监控，降低风险事件对项目的负面影响程度，提高项目的交付成功率。

根据风险准入清单，需要组织团队成员针对清单内的风险，进行风险应对策略制定。风险应对策略主要分为风险规避、风险转移、风险减轻、风险接受，团队成员需要共同制订风险应对策略。

当确定风险应对策略后，项目经理需要把风险应对策略作为backlog清单内容，加入到本次Sprint中，明确应对策略具体的负责人，当Sprint过程中触发某个风险时，需要风险负责人执行风险应对策略，来进行风险应对，保证当期Sprint正常进行。

3.5 敏捷项目风险监控

在识别出风险清单，并根据风险影响程度进行风险排序，制定好风险应对策略之后，敏捷团队成员还需要对风险进行监控。由于敏捷团队在每天早上会有固定的会议，沟通当期Sprint的情况，结合风险监控的特性，在站会机制上引入风险监控环节。

根据常规敏捷站会上成员对特定问题（昨天做了哪些事情，今天计划做哪些事情，有没有遇到阻碍）的回答，项目经理进行Sprint管理，引入风险管理机制后，在站会上新增加一个问题，有没有触发风险，风险应对清单上每个成员都有自己负责的风险项，通过每日站会让成员关注自己负责的风险情况，从而达到主动管理风险的目的。

4 结语

对于软件开发项目来说，项目的风险管理是必不可少的环节，只有完善的风险管理，软件开发项目成功交付的可能性才会更高。对于近些年迅猛发展的敏捷项目管理方法，我们不能仅仅看到敏捷方法给项目交付效率的提升，也要充分认识到敏捷方法给软件项目带来的风险，并在敏捷项目中主动管理这些风险，才能更好地应用敏捷方法给企业带来更多价值。