【IT168 技术文章】

    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能处理项目有关的风险，但是当风险处於项目外部 就显露出真空。同样道理，到底谁负责风险管理亦没有共识，有意见倾向产品负责人，但有部份则认为整个团队有责任管理风险。