Scrum的风险管理

作者 Vikas Hazrati 译者 麦天志 发布于 2008年8月11日

领域

过程 & 实践

主题

企业级敏捷 ,

敏捷

标签

管理 ,

Scrum ,

风险

Michele Sliger指出在敏捷开发中每日站立会议、迭代计划会议、发行计划会议、项目回顾（retrospective）以及检讨会议都能应付风险。但是，她也提出结构性风险管理方法。步骤包括，

风险确定——每次迭代中整个团队都进行一次，在结果纪录在白板或者活页样板上。

风险分析——凭主观判断、直觉、及经验作定性分析去判断风险和潜在损失。敏捷开发中的短开发周期及定期检讨使这分析可行而有效。这有别於传统项目管理中进行定量分析，按破坏程度配以分数。

风险反应计划——整个团队参与探讨相关措施及行动以减低威胁。

风险监察及控制——于迭代后期监察风险及商讨控制策略。以信息辐射体（Information Radiator）方式每日监察风险。

Ron Jefferies指出风险不是问题， 而是在Scrum Master的观察清单上的项目，记录下哪些事情会出问题。他说，风险有不同的形式，例如内容未组装好、新或不熟悉的技术、团队分散於不同地域、与其他项 目的依赖等。Scrum团队可以按价值和风险程度来决定故事的优先次序，花足够的时间在有风险的故事上，正确地确定及减轻风险，风险应该以故事形式加上 Backlog并被处理。

Michael James提到像Scrum的软件开发过程在项目周期中早期小心处理风险，提供各种途径让风险得以解决，像每日站立会议、迭代检讨等。根据Micheal，Scrum不需要创建风险纪录，但是，团队能定期管理风险。

有其他人指出，Scrum不能应付项目外部的风险，她能处理有关於需求转变、缺乏沟通、和团队表现不济的风险，但是项目外部的风险就需要Scrum以外的技巧来处理。

Paul Hudson在Scrum Development群組亦同意类似想法， 他提出Scrum能处理项目中大部份的风险，但是Scrum不能处理团队层面所不能处理的风险。他指出一些例子来支持他的观点，例如顾客缺乏对Scrum 的认识、第三方产品未能如期运作、项目所依赖的外部因素没有及时出现、团队系统有数据丢失及遭到破坏、顾客有不同的意见声音、顾客代表有私心并与项目目的 相违等。

另一个社区内激烈辩论的题目是“谁负责风险管理？”

Michele Sliger认为，整个Scrum团队负责风险管理以及减低风险。

在Scrum Development群組的讨论上，Ron Jeffries指出，以Scrum的术语来说，是产品负责人有责任去管理风险。有些成员同意Ron的说法，因为产品负责人最了解业务情况，他/她是决定 那些风险需要处理的最佳人选。产品负责人可以从团队各成员收集讯息但最终责任始终归於产品负责人。Peter Stevens说，

作为主要项目投资者，减轻风险直接关乎产品负责人的利益。Scrum Master 和团队应该帮助产品负责人在Backlog作出最佳排列，但是因为产品负责人需直接负责投资回报（ROI），而风险的后果就是成本，所以风险管理就是产品负责人的责任。

群组上其他会众提到风险管理是团队的责任，Scrum团队所有成员需要同心合力管理风险。

由 此可见Scrum能否管理风险以及应否明确指定管理风险都存在分歧。大多数敏捷社区的人仕都同意Scrum能处理项目有关的风险，但是当风险处於项目外部 就显露出真空。同样道理，到底谁负责风险管理亦没有共识，有意见倾向产品负责人，但有部份则认为整个团队有责任管理风险。

查看英文原文：Managing Risk with Scrum

译者附注：

风险管理是一个很大的研究题目，与软件工程有关的风险管理的文献亦有很多，很值得参考，首先要明白的概念是“风险”和“问题”之间的分别，风险是将来可能发生的事情，而不是现在发生又或者笃定会发生的事情，最明显例子是“顾客缺乏对Scrum的认识”，在决定是否开始进行项目时这还是需处理的风险，但到项目进行中的事后，这已经是一个需要解决的“问题”。

另外值得留意一点，由SEI到南加州大学有关软件系统工程风险研究都提出一整套风险管理方案，而没有分“项目外部风险”或“项目内部风险”的处理方案。

2007年南加州大学Barry Bohem发表的Incremental Commitment Model，虽配以传统定量分险管理计划之外，也有以里程（Risk driven anchor point milestones）型式去决定下一步的工作。

• 如果项目参与者认为风险程度可以接受而风险管理计划亦都合适，项目可以进行下一步。
• 如果风险程度可以接受而风险管理计划未能达到需要，那需要延长这阶段工作然后再检讨一次。
• 如果风险程度很低，亦直接可以进行开发。
• 如果风险程度太高，可以终止项目。

这方式提供了一个简易的框架让产品负责人作出相关决定。（文中对“时期”（stage）、“阶段”（phase）、“里程”（milestone）有不同意思，阅读时请留意）

敏捷开发的历史中不断提及去除浪费的活动，大型系统开发对风险管理的需求实在很明显，然而对於较小型的开发项目（试想像一个四个人月完成的网站），像文中提 到“明确规定的风险管理过程”就会变得累赘，开发人员可能为“合乎标准”而循例完成一些他们或者产品负责人都觉得没多价值的官僚活动，这样就降低了“敏捷度”。另一方面，由於迭代和回顾机制低下，所以也不用担心没有及时引入风险管理措施。

---

译者简介： 麦天志（Steven Mak），现职系统工程经理，工馀时间除了游水、观赏足球赛事、看电影以外则喜欢钻研有关软件开发过程、另类编程语言、美学、道德、创意、和预测市场等问 题。从小对编程产生兴趣，毕业于香港大学，主修计算机科学，并于伦敦帝国学院获取工商管理学硕士学位。志愿参与InfoQ中文站内容建设，请邮件至editors【AT】cn.infoq.com。

译者 麦天志 现就职于Odd-e从事团队教练工作，从小对编程产生兴趣，毕业於香港大学，主修计算机科学。

• 更早的 >